Re: [RFC] cygport pm for managing package releases

[Andrew Schulman <schulman.andrew@epa.gov>]

> 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.

<snip>

> 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