Zbigniew Jędrzejewski-Szmek venit, vidit, dixit 2024-04-07 17:15:16:
> Hi everyone,
>
> I'm revisting the topic of rpmautospec because I was doing some work
> on various packages, and it's annoying that some packages are using
> rpmautospec and others are not.
>
> All my packages have been converted, so in day-to-day work, I don't
> even think about %changelog. When working with other packages, I'll
> forget to update the Relase and/or %changelog. Today I was rebasing
> some pull requests in pagure, and the _only_ conflicts that I had were
> about Release and %changelog.
>
> I think it's time to switch to rpmautospec completely.
> Thus, the proposal:
> - new packages MUST use rpmautospec
> - packagers SHOULD convert their packages
> - provenpackagers MAY convert existing packages
> (e.g. when they want to push some fix or separately from other
> work)
> - people submitting pull requests against src.fp.o MAY also
> include a conversion in the pull request and packagers SHOULD
> merge it.
>
> (FTR, 'rpmautospec convert' does the conversion, incl. the commit
> to dist-git. Manual conversion should not be used.)
An interesting proposal with unsurprising reactions from the expected
people ;)
Can I add +200 if others add -100, and what does that even mean? Kidding
aside, and putting the obvious "Makes my workflow work", "Destroys my
workflow", "Change? Hell no" aside, too, I think it's worthwhile to
take a step back and widen one's view towards the question:
Do we consider dist-git to be a version control system (vcs) for spec
files?
Historically we have not quite, which is no wonder given the cvs
heritage. But, assuming for a moment that we do mean version control
seriously and look at the status quo ante rpmautospec ("legacy specs")
and what we do there:
- We put the version ("release" in our terms) of the spec file in the
version controlled spec file.
- We put the log of the changes in the version controlled files.
How absurd!
Really, from the point of view of version control, anything that takes
this version information out of the versioned spec is better than legacy
specs. rpmautospec is the only such thing which we have right now.
On the practical side, I was sceptical about some shortcomings of
rpmautospec in the beginning, but it's really such a time (and nerve)
saver whenever you need to pick changes - be it from merge requests
against a moved head, from your own feature branches in dist-git forks
where you prepare changes, etc. All information is where it belongs
(change+log), and there are no artificial conflicts (release,
changelog) and no bogus dates.
Also, I find that many packages treat the dist-git log as more or less
worthless nuisance. rpmautospec helps you put both packager and user
info in one place (the commit message) and encourages to care about
both. Since some may not know:
```
Rebase to upstream x.y.z
- shiny new feature S
- various bug fixes
Also, we clean-up the spec file (white space, patch macros).
```
is a commit message which has both user info ("changelog", the first
line/header plus the dashed lines) and the info for other packagers -
how neat is that? You want it, too, admit it :)
We have other "vcs short-comings", of course, such as the fact that we
don't really use merges and feature branches in dist-git. Almost
consequently, rpmautospec does not deal well with merges. It does work
well with cherry-picks, though.
Since it's been mentioned: While (fast forward) merging the ubiquitious
"rebuild for..." commits down to lower releases does not do any "harm",
having a message like "rebuild for bar 24.7" in a release branch where
"bar" is at "23.3" is quite misleading. It's rooted in "cvs think" and
not using feature branches properly. rpmautospec can solves this easily
with cherry-picks now and, possibly, with merges later once it supports
merges better and we accept a true branch model in dist-git ;)
Cheers
Michael
--
_______________________________________________
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
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
