* committing to git should build the package Is there a reason why this wouldn't be the case?

* commit groups of packages together

On Tue, Jan 28, 2020 at 10:21:41AM +0100, Milan Crha wrote: > On Tue, 2020-01-28 at 10:03 +0100, Richard W.M. Jones wrote: > > * committing to git should build the package > > > > Is there a reason why this wouldn't be the case? > > Hi, > the answer for the above is just your following point: > > > * commit groups of packages together > > aka the dependencies. Sometimes you want a special side tag, sometimes > it's not needed. The way I do it right now (it's only about 4 packages > depending on each other, not hundreds), is that I commit to master, > then to stable, then the second package to master, to stable, then > third and finally to the fourth and then I ran a chain-build as this: > "a : b : c " in package 'd', (which builds 'c' and 'd' in parallel, > once 'a' and 'b' are built in serial). Then I just refresh the koji > build page from time to time and verify that the build still runs > and/.or it finished successfully. I can run chain-build in stable too, > it only needs a bit more intervention, to define overrides for 'a' and > 'b' in bodhi, to be able to build them. > > I'm afraid fully automating such things might be a challenge. In other > words, properly solving dependencies is problematic. Having yet another > syntax to describe it, or the groups you suggest, scares me a bit. And > we are not talking about inter-package dependencies, with packages you > are not maintaining. This is not a problem - it has been solved several times independently. I most recently proposed this, but it's certainly isn't the first time it has been done: https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-new-tool-whic... http://git.annexia.org/?p=fedora-ocaml-rebuild.git;a=summary What we need is Fedora to recognize that maintaining 100s of packages mostly automatically should be a goal. If you look at the ecosystems around language packaging (cpan, nodejs, crates, opam, etc) this ought to be self-evident.

Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones <rjones(a)redhat.com&gt; ha scritto: > > 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? Sometimes you only add comments to the spec file and a rebuild is not needed.

Il giorno mar 28 gen 2020 alle ore 10:04 Richard W.M. Jones <rjones(a)redhat.com&gt; ha scritto: > > 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? Sometimes you only add comments to the spec file and a rebuild is not needed.

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.

* Pierre-Yves Chibon: > Feel free to poke at it and see how it behaves. > > The script only considers: > - the last two years of commits > - commits touching either the spec file or patches (ending with .patch) > > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current > commit that should be ignored), as well as a way to say: [Replace XXX] to be > able to replace an existing commit message, but that's not there yet. Have you considered only auto-generating %changelog entries since the last commit that changed the %changelog section?

To fix entries, you would run a tool to materialize the current auto-generated %changelog (and Release:), and then make the necessary corrections and additions.

* Pierre-Yves Chibon: > On Tue, Jan 28, 2020 at 01:53:32PM +0100, Florian Weimer wrote: >> * Pierre-Yves Chibon: >> >> > Feel free to poke at it and see how it behaves. >> > >> > The script only considers: >> > - the last two years of commits >> > - commits touching either the spec file or patches (ending with .patch) >> > >> > We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current >> > commit that should be ignored), as well as a way to say: [Replace XXX] to be >> > able to replace an existing commit message, but that's not there yet. >> >> Have you considered only auto-generating %changelog entries since the >> last commit that changed the %changelog section? > > We thought about that, pull the last changelog from the last build, get the > commit hash of that last build and only generate the new changelog from > HEAD..<lastbuild>. > The issue was: how to fix existing entries (typo, wrong content...) and our > thought on this was that it would be easier to re-generate the entire changelog > for this reason. > >> To fix entries, you would run a tool to materialize the current >> auto-generated %changelog (and Release:), and then make the necessary >> corrections and additions. > > Where would this corrections/additions live though? > We were thinking to include the corrections in other/new commits but if we don't > reach the old commits, we can't correct them. > > What did you have in mind? Sorry for being unclear. The spec file in dist-git would still show some (older) version of the %changelog entries under this model. The corrections would update the %changelog with all the historic entries. Since auto-generation stops at this commit, the new generated %changelog will include the fixed entries. This would also avoid the need for a new knob to adjust how far back the %changelog generation goes.

* Pierre-Yves Chibon: >> Sorry for being unclear. The spec file in dist-git would still show >> some (older) version of the %changelog entries under this model. >> >> The corrections would update the %changelog with all the historic >> entries. Since auto-generation stops at this commit, the new generated >> %changelog will include the fixed entries. >> >> This would also avoid the need for a new knob to adjust how far back the >> %changelog generation goes. > > Let me rephrase to see if I understand correctly. > The changelog would be something like: > `` > %changelog > %generate_changelog > > <The changelog up to the point the packager opted to use the macro above> > `` > > This way we don't need to generate the old entries, we can just focus on the > commits once the packager has opted in and not look at the old commits in the > git history. > > Is that what you were thinking? Yes, but the generation would not stop when %generate_changelog was added, but when the last edit below %changelog was made. Does this make sense? Sorry if I'm not explaining this properly.

On Tue, Jan 28, 2020 at 09:03:09AM +0000, Richard W.M. Jones 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. There are a few tricky things about this, but overall I think it's doable and some of the tricky things may just be things we just have to accept as being different from the current situation. We are playing a bit of a proof of concept of what a RPM changelog generated from git logs could look like. The outcome of this is at: https://pagure.io/Fedora-Infra/generate_changelog/tree/master Feel free to poke at it and see how it behaves. The script only considers: - the last two years of commits - commits touching either the spec file or patches (ending with .patch) We want a way to say: [Ignore XXX] (or simply [Ignore] if it's the current commit that should be ignored), as well as a way to say: [Replace XXX] to be able to replace an existing commit message, but that's not there yet. One of the thing that may change is that we may end up with changelog entry that do not have a corresponding nvr at the end. The python script above shows that, it'll only add the v-r in the changelog when either one of them changed, if they are the same, it doesn't specify them. Another aspect that is getting trickier is: - update to 1.1-1 <build failed> - fix missing BR <build succeeded> - spec clean up 3 commits, can all be either on 3 different days but could also be on the same day. Could be from 3 different people, but could also be from the same person. So we could have 3 commits, on 1 day from 1 person, two of which would make sense to group together (update to 1.1-1 and fix missing BR) and one that shouldn't since the build succeeded before that and thus the -1 that goes out to the mirror will not have this clean up entry. The current approach we took is: we have 3 entries in the changelog (and only one has the v-r specified). It's not ideal, but we don't quite see how to solve this question yet. If the "spec clean up" contains "[ignore]", that question is solved, but if we replace "spec clean up" with "Drop sub-package foo" then we do not have a good idea on how to consolidate the commit messages into a single changelog entry. Suggestions welcome :) > * committing to git should build the package > > Is there a reason why this wouldn't be the case? That was part of the proposal we debated last fall and there seemed to be much more people against this than I thought there would be. Maybe we could start with having an opt-in approach. > * 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. If we use a magic word to support opt-into automating commit -> build, we could get partly there. BuildIn: Fedora, EPEL BuildIn: <side-tag> BuildIn: rawhide ... > * “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. We clearly don't have a good mapping from commit messages to bugzilla. dist-git has the info, either in the rpm changelog or in the git commit messages koji has only the info of the git commit it was triggered from bodhi works at the nevr level. A lot of food for thoughts here :) Pierre _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org

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

On Tue, 28 Jan 2020 at 13:01, Robbie Harwood <rharwood(a)redhat.com&gt; wrote: > > "Richard W.M. Jones" <rjones(a)redhat.com&gt; writes: > > > 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 ... > > > > --- > > > > * 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). > > This is an interesting idea, and I appreciate you're considering ways to > resolve this problem. However, I'm concerned that this will lead to > maintainers not actually checking whether a version fixes an issue - > since we don't have automatic verification (or even usually manual > verification) of security fixes, that wouldn't get caught. > You are assuming that maintainers actually check to see if a version fixes an issue already. If a packager has 100's or 1000's of packages.. there is no way they will have done so except on a 1 in a million case set. I think if are going to aim that a packager can 'maintain' hundreds or thousands of packages that we also assume that this security is not going to be checked by the maintainer. If it needs to be checked it will need to be 'outsourced' to some group who can do so.

My main concern is that we have been coming up with 'standard' proposals for 20 years and we can't seem to get more than any 4 maintainers to agree to what that means... even if they do the same work in Debian/SuSE/Arch etc. Too many idiosyncratic techniques which they use to keep themselves sane or working in whatever environments they have. At this point, I will take whatever we can standardize on even if it is clay tablets mailed to Babylon (ok maybe something a little less archaic)

You are assuming that maintainers actually check to see if a version fixes an issue already. If a packager has 100's or 1000's of packages.. there is no way they will have done so except on a 1 in a million case set. I think if are going to aim that a packager can 'maintain' hundreds or thousands of packages that we also assume that this security is not going to be checked by the maintainer.

On Tue, 28 Jan 2020 at 13:01, Robbie Harwood <rharwood(a)redhat.com&gt; wrote: > > "Richard W.M. Jones" <rjones(a)redhat.com&gt; writes: > > > 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 ... > > > > --- > > > > * 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). > > This is an interesting idea, and I appreciate you're considering ways to > resolve this problem. However, I'm concerned that this will lead to > maintainers not actually checking whether a version fixes an issue - > since we don't have automatic verification (or even usually manual > verification) of security fixes, that wouldn't get caught. > You are assuming that maintainers actually check to see if a version fixes an issue already. If a packager has 100's or 1000's of packages.. there is no way they will have done so except on a 1 in a million case set. I think if are going to aim that a packager can 'maintain' hundreds or thousands of packages that we also assume that this security is not going to be checked by the maintainer. If it needs to be checked it will need to be 'outsourced' to some group who can do so.

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.

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

On Tue, Jan 28, 2020 at 11:51:29PM +0100, Dan Čermák wrote: > "Richard W.M. Jones" <rjones(a)redhat.com&gt; writes: > > > 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? > > Not really no. I've been involved quite a bit in building packages on > openSUSE's Buildservice and every commit there results in a rebuild. So it > is doable, *but* OBS has the advantage that it discards all builds > except for the most recent successful one, or it would have run out of > storage ages ago. > > Although someone (Randy Barlow maybe?) had the idea to generate the > changelog and to trigger builds from git tags instead of commits, which > has a certain charm to it as well. If there was a choice whether to > trigger builds from commits or tags and how to generate the %changelog, > then I think that most use cases should be covered? The original idea of using git tag is Jeremy Cline's. If we support: automatically building from commit or not, then I don't think we need to support building from git tag, using the current approach would work just as well when you don't want to build from commit. > > * 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. > > How about something like `fedpkg add-to-side-tag` (yes the name needs > work) that would work like this: > > $ fedpkg request-side-tag > $ fedpkg add-to-side-tag $tag_name $pkgA $pkgB $pkgC $pkgGlob > > Now all git commits/tags pushed to $pkgA $pkgB $pkgC $pkgGlob result in > them being built in the side tag $tag_name by default. Once the side tag > is merged, you go back to building the "ordinary way". Isn't that just fedpkg chain-build --target=$tag_name ... ? This is already existing and working, however, it requires the different packages are up to date in git (ie: you've made and push the commit updating the spec file to the next release/version) which goes against the point above about automatically build on commit.

On Wed, 2020-01-29 at 09:43 +0000, Richard W.M. Jones wrote: > Also AIUI fedpkg chain-build doesn't work except in > Rawhide, although I'm not sure why that is? It doesn't work in stable because you need to create buildroot overrides for each dependency before you can proceed with building the next package, and fedpkg chain-build doesn't create the BROs. However, I think the multi-package gating can do this now that it exists, because AFAIK you should be able to chain-build in a side tag. I have not tried this yet.

"Richard W.M. Jones" <rjones(a)redhat.com&gt; writes: > * CVE bugs should autoclose when a package is rebased I don't think this is a good idea as you should actually check that this update fixes the CVE.

On 29 Jan 2020, at 00:26, Robert-André Mauchin <zebob.m(a)gmail.com&gt; wrote: On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote: > * committing to git should build the package > > Is there a reason why this wouldn't be the case? Please no. Sometimes you just fix a typo or add a comment and there's no need to rebuild until a next release.

_______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org

Maybe now that RH is part of IBM they have changed their short sighted view of not collaborating on a better build system like OBS. As I recall

Maybe now that RH is part of IBM they have changed their short sighted view of not collaborating on a better build system like OBS.

As I recall back than it was already able to bootstrap on centos and fedora and build packages and the only argument against it was legacy support with mock / koji which provide a fraction of functions that OBS does (mostly things that make it easy to get new contributers like a web interface to edit spec files and webhooks not to mention that these Mass rebuilt emails could be a thing of the past). On Wed, 29 Jan 2020, 12:17 Christophe de Dinechin, <dinechin(a)redhat.com&gt; wrote: > > > > > On 29 Jan 2020, at 00:26, Robert-André Mauchin <zebob.m(a)gmail.com&gt; wrote: > > > > On Tuesday, 28 January 2020 10:03:09 CET Richard W.M. Jones wrote: > >> * committing to git should build the package > >> > >> Is there a reason why this wouldn't be the case? > > > > Please no. Sometimes you just fix a typo or add a comment and there's no need > > to rebuild until a next release. > > This “sometimes" is the rare case. So having a “push —nobuild” would address that need. > > > > > _______________________________________________ > > devel mailing list -- devel(a)lists.fedoraproject.org > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > > 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@lists.fedoraproject.org > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > 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@lists.fedoraproject.org _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org

>That is looking for a boogeyman under the bed to blame something that >has a long long history of not happening. Ever since OBS has been out, >there has been a yearly 'why isn't Fedora moving to OBS' thread It has always been a bad management decision to not change. Ever since OBS has been out there has been a regular thread about this (usually not started by me), because it's the correct thing to do in a long term perspective for RH and the Linux community/ecosystem.

On 28 Jan 2020, at 10:03, Richard W.M. Jones <rjones(a)redhat.com&gt; 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.

* 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(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org 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@lists.fedoraproject.org

There are different: * Changelog is for end user * Git log is for package maintainer

> * committing to git should build the package > > Is there a reason why this wouldn't be the case? Yes, because I often commit various changse "before" the build (some being cherry-pick on other branch, some not)

IMHO, remember KISS, and don't try to add more magic to our tooling And I really prefer to see stabilization of our current tools and infrastructure before breaking it again.

And I really prefer to see stabilization of our current tools and infrastructure before breaking it again.