From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (static.214.254.202.116.clients.your-server.de [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 6848D386101C for ; Fri, 25 Sep 2020 17:13:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6848D386101C Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kLrHl-0000QR-TT for cygwin-apps@cygwin.com; Fri, 25 Sep 2020 19:13:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: cygwin-apps@cygwin.com From: Andrew Schulman Subject: Re: [RFC] cygport pm for managing package releases Date: Fri, 25 Sep 2020 13:13:23 -0400 Message-ID: References: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> <928nlflgp1urt25075aq66j1r6f46spjsu-e09XROE/p8c@public.gmane.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Newsreader: Forte Agent 4.2/32.1118 X-Archive: encrypt X-Spam-Status: No, score=-3032.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, 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: Fri, 25 Sep 2020 17:13:33 -0000 > 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