less-active maintainers who probably heard about rpmautospec, but have lingering doubts,
users who might wonder how it impacts them,
(very importantly) contributors from other rpm-based distros that don’t use rpmautospec, but could.
Article Description:
Outline:
what is the purpose of Release and %changelog fields in rpms
how %autorelease and %autochangelog work
how do the “new” changelogs differ from “old” changelogs (i.e. not much)
what this means for packagers (less busywork and merge conflicts), for contributors to packaging (better pull-request workflow), and for users (no change).
example of a simple version upgrade and how the generated fields look
links to the Change page and other docs
The publishing of the article would be conditional on the changes to the packaging guidelines being merged, currently under review.
Hm. Normally I’d say something like this is better for the Community Blog, but given
I think Magazine might be a better fit for this specific article. Once there’s a draft, I might have a different opinion. Or we might decide to split it into two.
@zbyszek: This proposal is approved for publication on Fedora Magazine. I’ve created card #181 to track the status of this article. You can use that card to ask questions or provide status updates about your article.
So on reflection, I wonder how much of “users who might wonder how it impacts them” is an actual audience here. Will users even know about it in order to wonder?
The “contributors from other rpm-based distros” aspect is solid, I think, but not well-addressed. It would be good to explicitly say “hey, this is a thing your project could adopt, too! here’s how”. (The here’s how could maybe be an article in itself, but doesn’t need to be very detailed at this point. A link to the repo might be enough)
The “If Martin were to do another build, let’s say with a patch added” part is a great example of how this simplifies the process of providing a fix. Since non-packagers can’t push to src.fp.o (I believe), this makes it a lot easier for a user to say “here’s a patch to the code and the spec file that fixes a bug I’m facing” and it makes it easier for the maintainer to apply.
In general, the content is good and suitable for Magazine, but the presentation should maybe be more explicitly user/use-case focused, if that makes sense? Also, the opening paragraph needs to be a little more exciting to hook the reader.
