I always think that Fedora works fine if you maintain 1-5 packages. It's possible to maintain 20 with a lot of work. And if you want to maintain 100+ (things like the ocaml-* set that I help to maintain) then you have to write your own automation. Could we do things better? No one asked for them, but here are my ideas ... --- * kill the %changelog Please, let's kill it, and generate it from the git changelog. I'm glad to see there's a proposal to do this. A general principle I'm following here is a packager should never be asked to enter the same information twice. * committing to git should build the package Is there a reason why this wouldn't be the case? * commit groups of packages together One reason why automatic commit -> build might not be desirable is if you're trying to build a group of packages in a side tag. In my opinion this means we should allow groups of packages to be committed together. (Unfortunately because we chose to put every package in its own git repo, the obvious way to do this can't work, but we could still have a "ChangeId:" header in the commit message that ties packages together). The packages should be built in build dependency order into a side tag, and the side tag turned into an update, with no further involvement from the packager unless something fails to build. This change on its own would solve the main problem that affects people maintaining large sets of packages. * “Fixes:” etc headers in git RHEL already does this. It should be possible to add special headers to the commit message to automatically close bugs, ie: $ git commit -m "ocaml: Update to version 4.10.0 Fixes: RHBZ#12345" Note the build, update and bug closing would happen completely automatically, assuming there was no build or test failure. * CVE bugs should autoclose when a package is rebased Fabiano built the mingw-openssl package recently, but there are still a load of open CVE bugs against this package referring to the older version. These should be closed automatically. I think this will require collecting the version of the package that fixes a CVE and recording that in Bugzilla (or in the package itself in some standard way). * create streams of packages automatically depending on quality scores We know a lot about packages such as: - How many bugs are opened against them? - What's the average time between a bug being filed and fixed? - Do they get regularly updated? - Do they pass or fail CI tests? - How many rpmlint / fedora-packager problems do they have? Why don't we use that data to build streams of high quality and lesser quality packages? Allow the end users to choose whether they want the best curated packages only, or they're prepared to accept the risk of taking a package with lots of bugs or CVEs (this is assuming the previous point is fixed, so these are real CVEs, not irrelevant bugs). If you want to go even further with this idea, then it could even be possible we allow packages into Fedora without any review. They would start in the outermost stream in a "there be dragons" repository that only the foolhardy would enable, but as their quality improved they would *automatically* migrate into the mainstream. --- Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
