On Tue, Jan 28, 2020 at 12:36:23PM +0100, Pierre-Yves Chibon wrote: > > 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 :) How about: * maintainer commits whatever in N commits. Commit messages can be just whatever maintainer/pr submittor likes. * Any PR's or commits that are 'notable', the commit should include a 'changenotes-hash' file. * When ready to do a build/update, all the changenotes-hash files are assembled into the changelog if they are part of a commit since the last build. Or I guess they could be consumed/removed after this and just any that exist are considered. > > > > * 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. I was for it before that last thread, then against it now. :) I think maintainers need to be able to do commits that they do not want to build against. We could look at tags for this info... ie, 'NOBUILD: true' or whatever. kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
