On Fri, Sep 27, 2019 at 10:57:21AM -0400, Neal Gompa wrote:
On Fri, Sep 27, 2019 at 9:54 AM Panu Matilainen
<pmatilai(a)redhat.com> wrote:
>
> On 9/26/19 10:05 PM, Jeremy Cline wrote:
> > 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.
>
> We've tossed around using tags for builds before in another context, but
> the idea of tag annotations for populating the user-visible changelog is
> an interesting and a totally novel idea AFAIK.
>
> On top of using tags to, well, tag content for building (it seems so
> natural nothing could be more natural), we talked about calculating the
> release number automatically from number of commits on that branch since
> the last tag. The details seem to largely evade me, but changelog
> population was planned around picking messages out of git commit
> messages. Which has its issues. The tag annotations probably has its
> own, but it's indeed an intriguing idea.
>
This was the discussion Igor and I had at the openSUSE Summit in May.
The unanswered question I had was if we can manipulate the data
attached to a tag in Pagure UI and edit it after it was initially
pushed. If annotations are also frozen like all other things in
Dist-Git, then it fails as a usable mechanism.
Or just make another tag with a newer release number. Of course, that
doesn't work with the auto-generated release number based on
commits-since-last-tag, but to me that's a "nice to have". You could
have it do that if a release isn't specified in the tag, though, so you
could have it all.