[Article proposal] rpmautospec

Article Summary:
As part of https://fedoraproject.org/wiki/Changes/Rpmautospec_by_Default, I’d like to write an article that gives a short intro to what rpmautospec means for packagers and users.

The article would be directed at:

  • 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:

  • 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.

+1 from me. Sounds good.

This sounds OK to me for Fedora Magazine. But I wonder if it might be better suited to the Community Blog? @bcotton: thoughts?

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.


@bcotton WDYT: Rpmautospec by default in Fedora Linux

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. :slight_smile:

We can close this here, because the article has been published.

(I wasn’t ignoring Ben’s comment. I had a plan to incorporate the feedback, but it never happened. Sorry, this wasn’t intentional.)

This topic was automatically closed after 180 days. New replies are no longer allowed.