Good Morning Everyone,
This is not a new idea, it has been presented at flock last year and spoken
about on this very list this fall, so I'd like to push it a little further.
Do we want to drop release and changelog from our spec file?
If we do, how would this work?
The release field would need to be set by koji ignoring whatever is in the spec
file. How do we want to do this?
- Based on dates?
- Using an always increasing integer?
- Using the number of successful builds since the last time the version field changed?
- Another idea?
The third option looks like to be the one closest to our current behavior.
Another question regarding the release field is: how would we deal with
pre-releases and other unsortable versions?
The current doc relies on <extraver> etc. in the release field as per:
Would using the tilde to specify pre-releases in the version field be sufficient
(as described in
I.e., how can we cater for snapshot releases (e.g. based off a specific git
With the changelog it becomes a little bit more tricky.
We currently have 3 changelogs in Fedora with 3 different target audience (this
is how I understand them):
- One for the files in the git repository, meant to be "consumed" by our
fellow packagers, not meant to leave the Fedora infrastructure
- One in the spec file describing the changes applied to it. This one is meant
to be accessible to sysadmins who want to know/check what changed in a package
- One in bodhi, meant for end-user consumption and which should give some
explanation as to why the package was updated or where information about the
update can be found
So we need to, somehow, merge two changelogs into one while realizing that some
information in one may not be desirable in the other (for example the world
famous commit message: "oops I've forgot to upload the sources" does not
appear in the RPM's changelog).
Would it be easier to merge the git changelog with the spec changelog or the
spec changelog with the bodhi notes?
For the former one easy way to achieve this is to consider all the commits since
the last successful build and have a magic keyword to either include or exclude
a commit message in the changelog.
For the latter, we discussed the idea of using annotated git tags this fall.
Both have their pros and cons, do people have some experience with either and
could share their feedback?
Is there a different approach, e.g. by using towncrier or something
comparable, to track changes outside the spec file?
To give some context to this discussion, the CPE team is moving toward quarterly
planning and for the first months of 2020 a small team of people in the CPE team
is willing to do the work to make this happen, but there are two requirements:
- The work needs to be scoped and defined by January 20th 2020 (so we can
evaluate whether or not we have the knowledge, resources and time to do it)
- The work needs to be achievable before March 31st 2020 (cf the quarterly
objectives we're working towards)
Thus our call for input to accept or reject the idea and if the former
scope/define the system.
Thanks in advance for your help,