Alex Hudson

Thoughts on Technology, Product, & Strategy

Maintaining bits in Fedora…

Over the past couple of days I got added to the packagers group in FAS and uploaded my first approved RPM – it has been a very interesting process, particularly going through the various policy pages on the wiki (which, while informative, are pretty badly laid out in my opinion – but that’s something I can help fix). Trying cvs again for the first time in years has been an odd experience.

I’ve already managed to make my first mistake – not incorporating changelog information into the commit message, which of course I realised just after I did it – but I’m taking things relatively slowly because I know there’s going to be plenty of stuff to learn still.

I have a couple of other packages which are waiting to be submitted; my rules on this are going to be pretty simple to begin with: I’m only going to submit stuff that I at least use, but mostly stuff that I develop or develop against. So, the first packages of log4c and iniparser are unlikely to set the world alight, but I feel I can do a better job as a packager that way to start with.

What is great is how friendly and helpful Fedora is as a community. nirik has been very helpful as a sponsor, and the whole process of trying to contribute to Fedora is really easy – a lot easier than I expected. I think some other projects could learn a lot from this.


Daily Hatemail spills Stig beans


Thunderbird & calendars


  1. Welcome to the fold — glad that the process of getting involved with Fedora has been fairly easy for you.

  2. jef spaleta

    Here are the general principles I live by as a Fedora package maintainer

    1) I only submit stuff I or my wife find useful. Not cool…useful.

    2) I do not take primary maintainership for things written primarily in a language I don’t know how to write a useful application in. So for me no C## or java for example.

    3) For every package that I submit I do two package reviews before hand for other people who are waiting for their packages to be reviewed. I’m thinking about changing that so that I do three reviews… 2 new reviews and one lingering merge review. If every maintainer followed this rule, we’d take the review que down to zero in no time.

    4) Tell upstream developers you are submitting the package and point them to the submission ticket while the review is ongoing.

    5) Repeatedly encourage an upstream developer to jump in as a co-maintainer. (Once or twice a Fedora release cycle)


  3. Regarding the layout of the packaging guidelines, there is some good news to report.

    Susan Lauber, a Docs Project contributor, is working with the Packaging Committee to rename and categorize all of the guideline pages. There is work to help with there, coordination is happening on the very useful ‘fedora-wiki’ list (a cross-sub-project wiki status and action discussion list.)

    You can check the archives for more information and join in to find out how to help:

Leave a Reply