On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon <pingou@xxxxxxxxxxxx> wrote:
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?
What about "number of commits since last version update" (possibly tagged in git)? That should encompass the possibilities you listed above, is well-defined, and should be most like the current behavior.
The number of successful builds doesn't sound like a well-defined / stable number to me, since it relies on information outside of git.
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:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_unsortable_versions
Would using the tilde to specify pre-releases in the version field be sufficient
(as described in
https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_versioning_prereleases_with_tilde)?
I.e., how can we cater for snapshot releases (e.g. based off a specific git
commit)?
The tilde notation is not enough for general snapshots, though it works well for tagged alpha / beta / rc releases (because they are real releases, not snapshots).
For snapshot builds, I think something like %releaseprefix of 0." (cf. %distprefix) could be used to indicate a prerelease in the .spec file, and incorporated in the automatically generated Release tag.
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
I think it would be good to merge git commit messages and the .spec changelog. This is also how many projects handle this on GitHub. Using [skip-changelog] in commit messages or something or something similar to indicate that it should not be mentioned in generated release notes is also common practice (just like [skip-ci]).
So I think this is very much doable, since there's actually a lot of precedent for doing this. Also, the two audiences for git commit messages and RPM changelogs are probably more similar than the audience for bodhi updates (where I usually put more user-facing information).
Fabio
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 need to
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[1] 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,
Pierre
[1] https://github.com/hawkowl/towncrier
_______________________________________________
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
