On Fri, Jan 10, 2020, 17:37 Pierre-Yves Chibon <pin...@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/#_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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
