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 00FA83987963 for ; Sat, 12 Sep 2020 15:18:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 00FA83987963 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1kH7I8-0004dj-US for cygwin-apps@cygwin.com; Sat, 12 Sep 2020 17:18:16 +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: Sat, 12 Sep 2020 11:18:11 -0400 Message-ID: <81pplfdns05p71dk7bnbqa0rrrsdnk6g8k@4ax.com> References: <928nlflgp1urt25075aq66j1r6f46spjsu@4ax.com> <928nlflgp1urt25075aq66j1r6f46spjsu-e09XROE/p8c@public.gmane.org> <496c460b-637b-47d5-9def-4ba9e21e25f3@SystematicSw.ab.ca> 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=-2.0 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: Sat, 12 Sep 2020 15:18:20 -0000 > Perhaps we should first outline the maintainer packaging workflow, including > required functions such as creating a package directory and contents, checking > for other repos with a package, sending ITPs/ITAs and SSH public keys, checking > licensing, checking for new upstream releases, and less common functions such as > those you mention, sending upstream emails and submitting patches or PRs, and > others, with a summary like the cygport --help output, description as in the > cygport HTML help, specification of what is needed and why, and example commands > to execute, if known, to implement the function. > Once we have a list of maintainer functions, we should consider what maintainers > consider pain points to add as cygport commands, plus quick and easy wins to > help maintainers contribute while understanding cygport development and docs. That sounds like a good approach, although I wouldn't want to get too bogged down in details at first. I like the idea of outlining the packaging workflow first, then automating the most common+important+painful pieces, and adding others later as the capability matures. Another consideration is how cygport will be affected as we move to an automated build system. We wouldn't want to build to a bunch of stuff that's just going to go away. But actually I think that once the builds are automated and we're all just uploading our cygport files, the package management functions will become more important, since we'll be more hands-off of the .hint files. > I like the single word commands in cygport and other tools e.g. your pm list is > like apt show, pm test and pm obsolete remind me of apt mark, and possibly also > pm del, depending on whether you expect those commands to work on .hint files or > upload directories or both, and distinctions and expectations like those need to > be explained. Agree. And clarified first. > Should we work with patches, PRs, a dev repo (on sourceware? or github) against > https://cygwin.com/git/?p=cygwin-apps/cygport.git, or other storage space(s), to > maintain lists of workflows, suggested functions, maintainer pain points, > possible commands, command summaries, outlines, help descriptions, spec details, > and commands to execute in an implementation. A Github repo sounds like an easy way to start. I'm open to suggestions if there are better ways. Andrew