Re: Ideas and proposal for removing changelog and release fields from spec file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 24, 2020 at 06:13:21PM +0100, Miro Hrončok wrote:
> On 24. 02. 20 17:48, Pierre-Yves Chibon wrote:
> > However, for the release field, we are struggling a little bit more, two options
> > are more appealing to us:
> 
> Can we please have a "git is the only source of truth" version of this? I.e.
> "Compute the release field from the number of commits since the last version
> change" in the document. It seem to only have one con (breaks if two builds
> are triggered from the same commit) which is the status quo.

It has another con which is indeed not mentioned in this section but in the next
one (n_commits+n_build) (I've fixed that).
Upgrade path may be problematic if you update Fn to a version in less commit
than the update for Fn-1 (ie: you update F32 to 1.0 in 1 commit and update F31
to 1.0 in 2 commits, suddenly you have F32 with 1.0-1 and F31 with 1.0-2).

> If you need to rebuild for a libpingouisawesome soname bump, you just do an
> empty commit with the explanation.
> 
> If you merge that empty commit to a branch that did not need it, it would
> have a bogus changelog entry (status quo). If you care, you would not merge
> but cherry-pick anything thta comes next (which is now much easier given the
> benefit of not having the %changelog and release).
> 
> With the proposed solution that includes "successful build count" you always
> bump and build even if it is not needed and also you make the release number
> depend on a specific build system, which I think is kinda wrong.

One of the benefit of the approach using number of commits + number of builds
(when it's > 1) is that mass-rebuild could be made even simpler and faster.
Instead of doing git commit + koji build, you would simply do koji build.


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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux