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 <pingou@xxxxxxxxxxxx> 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@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
