public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Andrew Schulman <schulman.andrew@epa.gov>
To: cygwin-apps@cygwin.com
Subject: Re: [RFC] cygport pm for managing package releases
Date: Fri, 25 Sep 2020 13:13:23 -0400	[thread overview]
Message-ID: <am8smf1oe0nhkav4aqmhpdv1p5u7feh5ma@4ax.com> (raw)
In-Reply-To: <edd30fc2-8dbe-cb1a-f5e6-5368c4be2397@dronecode.org.uk>

> I'm very keen on reducing the maintainer workload by increasing the 
> automation available to them.

Good.

> However, I'm not so sure about the approach proposed, which perpetuates 
> the 'create strange files which have a special meaning when uploaded 
> causing something non-obvious to happen' behaviour.
> 
> I think I'd perhaps rather just extend the work done with 'untest' [2] 
> to allow maintainers to do these things directly.
> 
> [2] 
> https://cygwin.com/git/?p=cygwin-apps/calm.git;a=commit;h=0a29ad572cbe1bcc64fd3624f5c38eee79c50445

I'm all in favor of using simpler methods. I just want to collect them all
in one place in cygport, so maintainers -

* don't have to remember, care, or find documentation for what the details
are for different package management functions;
* don't have to keep track as those methods change or improve;
* can rely on a stable and documented set of cygport commands to manage
their packages.

So as better automation becomes available, like the untest feature, we can
build that into cygport. But the maintainers won't necessarily have to
know; they can still just run cygport pm untest, for example.

Andrew



      parent reply	other threads:[~2020-09-25 17:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-11 16:07 Andrew Schulman
2020-09-11 23:07 ` Brian Inglis
2020-09-12 15:18   ` Andrew Schulman
2020-09-12 15:03 ` Ken Brown
2020-09-12 21:20   ` Brian Inglis
2020-09-12 22:14     ` Hamish McIntyre-Bhatty
2020-09-20 19:19 ` Jon Turney
2020-09-21 14:17   ` Ken Brown
2020-09-25 17:13   ` Andrew Schulman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=am8smf1oe0nhkav4aqmhpdv1p5u7feh5ma@4ax.com \
    --to=schulman.andrew@epa.gov \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).