Dne 26. 02. 20 v 12:16 clime napsal(a):
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)
If you care, you'll be able to manually modify the changelog. But I
agree that some automatic grouping would be nice. May be there could
also be grouping hint, similarly to `RPM-Changelog: exclude`.
Vít
- 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(a)cyberpear.com> 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(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
_______________________________________________
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