> On 28 Jan 2020, at 10:03, Richard W.M. Jones <rjones@xxxxxxxxxx> wrote: > > 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. Right now, you can do it the other way round, i.e. update the change log and fedpkg commit -c. But it is not very logical, and I agree it would be more logical to deduce the change log from the commit messages. > > * 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 _______________________________________________ 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
