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