On 9/27/19 5:57 PM, 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.
That's not the discussion I was referring to as I wasn't there :)
I had this with ffesti sometime last year. Anyway...
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.
Oh, sure. In the name of reproducability, the SRPM needs to have a
physical copy of it one way or the other.
To clarify, I specifically mean %changelog in git maintained specs must
die. It's just not as catchy ;)
- Panu -
_______________________________________________
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
