It would be nice if you could look into existing code instead of writing new one: https://github.com/ignatenkobrain/git-rpm-changelog
On Tue, Jan 28, 2020, 12:43 Pierre-Yves Chibon <pin...@pingoured.fr> wrote: > 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
