public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Jon Turney <jon.turney@dronecode.org.uk>
To: "cygwin-apps@cygwin.com" <cygwin-apps@cygwin.com>
Cc: "Schulman, Andrew" <schulman.andrew@epa.gov>
Subject: Re: [RFC] cygport pm for managing package releases
Date: Sun, 20 Sep 2020 20:19:33 +0100	[thread overview]
Message-ID: <edd30fc2-8dbe-cb1a-f5e6-5368c4be2397@dronecode.org.uk> (raw)
In-Reply-To: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com>

On 11/09/2020 17:07, Andrew Schulman via Cygwin-apps wrote:
> cygport has automated a lot of the work of building and maintaining
> packages for Cygwin. But one area where it doesn't help yet is in managing
> the available releases of a package. For me as the maintainer of a dozen or
> so packages, there are routine tasks that I still find to be painful:
> 
> * Finding out which versions of a package are currently available in the
> Cygwin repositories, and which if any are marked as "test".

While this isn't the ideal way to find it, the package summary page now 
provides this information e.g. [1]

https://cygwin.com/packages/summary/socat-src.html

> * Marking or unmarking a version as "test".
> * Removing versions from the repositories.
> * Marking a package as obsolete.

I'd add to this list 'generating and sending the package announce email'.

> All of these are still manual tasks. Most require digging through
> documentation (though that's also much improved in the last few years),
> manually editing .hint files or creating dummy package files, and manually
> uploading files to the right places in sftp://cygwin.com. It's not fun, and
> so I don't keep up with it as well as I should.
> 
[...]
> 
> I think these are surmountable, but I want to know if there's a general
> agreement that it's worth doing.
> 
> BTW a successful example like this one is the "cygport up" command, which
> we added a few years ago to automate uploading packages to cygwin.com. I
> think it's working well.

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

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

  parent reply	other threads:[~2020-09-20 19:19 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 [this message]
2020-09-21 14:17   ` Ken Brown
2020-09-25 17:13   ` Andrew Schulman

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=edd30fc2-8dbe-cb1a-f5e6-5368c4be2397@dronecode.org.uk \
    --to=jon.turney@dronecode.org.uk \
    --cc=cygwin-apps@cygwin.com \
    --cc=schulman.andrew@epa.gov \
    /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).