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
