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