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.
> In fact it was that discussion which prompted the development of
> automatic patch numbering and %patchlist support in spec files in rpm
> 4.15, since in the planned scheme merge conflicts on release number and
> changelog would be gone, and conflicts on patch numbers was identified
> as yet another redundant piece of data that's also often prone to
> unnecessary merge conflicts.
>
> The %changelog in specs really, really needs to die.
>
I would actually say that the spec in the SRPM should contain the
changelog, so that repeating the build from the exploded contents is
possible. But yes, it'd be nice if it wasn't there in the specs in
Git.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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
