Few more notes:
- having just: Release: <commit-count> means every commit bumps
release and hence every commit should likely generate a new record
into changelog => changelog basically becomes dumped `git log` (in
rpm-compatible format) - i.e. there is no capability to group multiple
changes into one changelog record (grouping them implicitly by version
changes will be tricky because changelogs will become mutable)
- it doesn't help in jumping from specific package name to a specific
commit in dist-git unless the macro also generates short git hash into
the release but it also doesn't make things worse compared to now
- for the solution with external changelog file with the commit
fallback - it might be slightly confusing for someone who wants to
look through the changes for a package in dist-git - at first, one
should look at commits but from a certain commit switch to the file =>
probably everyone will just stick to reading the commits
I very much like simplicity of the approach but i think it is good to
realize that the proposed solution is a direct translation of: "RPM
Changelog and Release, you are not needed. Stand aside and don't make
any problems!" If this is what packagers usually want, then it is a
good solution. I think it also depends on what rpm consumers generally
want.
Then from the document:
Get the release field from the annotation of the git tag
(-) requires manual work on behalf of the maintainer
That doesn't need to be the case with a client-side tooling
that generates release automatically into a tag name.
(-) Fragile: this means parsing using a regex the git annotation to
extract the release information
I would suggest putting release directly into a tag name, not into its
annotation (i.e. subject or body). Basically tag names = NVRs.
There is nothing fragile on parsing release from such name. In python,
it is just standard rsplit('-', 1) and taking the last component.
There are two issues here:
1) epochs: they will need to be put into the tag-name as <epoch>/NVR
because tag names cannot contain colons
2) tilde for prereleases: git tags cannot contain tilde character
('~'). But i personally believe we could find better ways to mark a
prerelease. It used to be forbidden in Fedora...
clime
On Tue, 25 Feb 2020 at 22:20, James Cassell <fedoraproject@xxxxxxxxxxxxx> wrote:
>
>
> On Tue, Feb 25, 2020, at 2:53 PM, Matthew Miller wrote:
> > On Mon, Feb 24, 2020 at 05:48:36PM +0100, Pierre-Yves Chibon wrote:
> > > So these are the results of our current investigations, we are very much eager
> > > to get your feedback on them and even more eager if you have ideas on how to
> > > approach/solve some of the challenges mentioned here.
> >
> > This all sounds great. I'd also love for there to be a standard way of
> > tagging specific git commit log messages as meant for user consumption, and
> > use that to prepopulate the bodhi release notes field (with an eventual eye
> > towards making this the single source of Fedora package change information).
> >
>
> Indeed, it is unfortunate that the Bodhi info for EOL releases is currently lost.
>
> V/r,
> James Cassell
> _______________________________________________
> 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
