From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-046.btinternet.com (mailomta32-re.btinternet.com [213.120.69.125]) by sourceware.org (Postfix) with ESMTPS id 3D2A23857824 for ; Sun, 20 Sep 2020 19:19:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3D2A23857824 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=jon.turney@dronecode.org.uk Received: from re-prd-rgout-002.btmx-prd.synchronoss.net ([10.2.54.5]) by re-prd-fep-046.btinternet.com with ESMTP id <20200920191936.VXTS4657.re-prd-fep-046.btinternet.com@re-prd-rgout-002.btmx-prd.synchronoss.net>; Sun, 20 Sep 2020 20:19:36 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com X-Originating-IP: [86.176.137.240] X-OWM-Source-IP: 86.176.137.240 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedujedruddtgddufeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeetleffgeetieduueetheffveelvdfffeefkefghffhhedvhffghfetheetleetkeenucffohhmrghinheptgihghifihhnrdgtohhmnecukfhppeekiedrudejiedrudefjedrvdegtdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddrudduudgnpdhinhgvthepkeeirddujeeirddufeejrddvgedtpdhmrghilhhfrhhomhepoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqecuuefqffgjpeekuefkvffokffogfdprhgtphhtthhopeeotgihghifihhnqdgrphhpshestgihghifihhnrdgtohhmqedprhgtphhtthhopeeoshgthhhulhhmrghnrdgrnhgurhgvfiesvghprgdrghhovheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.111] (86.176.137.240) by re-prd-rgout-002.btmx-prd.synchronoss.net (5.8.340) (authenticated as jonturney@btinternet.com) id 5ED9C0CC11E7AD37; Sun, 20 Sep 2020 20:19:36 +0100 Subject: Re: [RFC] cygport pm for managing package releases To: "cygwin-apps@cygwin.com" References: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> Cc: "Schulman, Andrew" From: Jon Turney Message-ID: Date: Sun, 20 Sep 2020 20:19:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.2.2 MIME-Version: 1.0 In-Reply-To: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Sep 2020 19:19:38 -0000 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