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@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
_______________________________________________
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
