On Thu, Sep 26, 2019 at 02:57:56PM -0400, Randy Barlow wrote:
On Thu, 2019-09-26 at 14:49 +0000, Jeremy Cline wrote:
> The combination of these two makes no sense to me. I do plenty of
> work
> where I don't want to build it (specfile cleanup, patches,
> configuration
> changes, etc.). I want a build that goes to users be explicit.
>
> A better model, in my opinion, is to build every *tag*. To do a new
> kernel build I could make a tag like "kernel-5.4-rc1..." and the tag
> would be parsed into the specfile's NVR and built.
I agree, and I really like the alternative suggestion here. Some people
in the thread have talked about how there are often conflicts between
branches due to the changelog, but the other common reason for
conflicts is the release field in my experience. If we use tags as an
explicit "I want this to go to users", then it solves both problems (I
consider sending all commits to end users a problem, because I often
make refactor commits that I would not want to churn users on.)
The tag also provides a nice place to write release notes for the
update. I suppose you could also add support for some sort of text tag
inside commits (like when you mark a commit as fixing an issue in
Git{Lab,Hub} and look at the commits between the new tag and old one so
selective git commits could get sucked into the changelog as well.