On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon <pingou(a)pingoured.fr> 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/#_un...
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/#_ve...
)?
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(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproject.org