Recently, Rahul Sandaram (Fedora dev and creator of the Omega Fedora Remix) offered to sponsor me to become a Fedora maintainer, which I accepted. A day or so later I pushed my first updates into Fedora for deja-dup – the package I now co-maintain while I learn the ropes.
Previously, one would become a maintainer by first submitting a new package and thereby overtime demonstrating an understanding of the Fedora packaging process and guidelines. However recently a new system was approved whereby one could become a co-maintainer of an existing package, instead. This requires being sponsored by an existing maintainer, which Rahul was for me.
It’s quite a big task, but Rahul was very helpful and patient while I learned about the process. There is a lot of information on the Fedora Wiki but I found there wasn’t really a single place which provided a nice overview, broke down each section in detail, and then explained all the steps required. So that (along with my cautious nature) meant it took a dozen or so clarifying emails back and forth between Rahul and myself.
When I got my first understanding and taste of the system though, I’ve gotta say, I was quite impressed. The scale of the system and architecture and how it all works is amazing. The build files (RPM spec files) of all the packages in Fedora are kept under their own git repository. Hooks into this git system and special build tools manage the whole process. All in all, this automation makes it quite seamless.
So after reading and doing everything Rahul sent to me, I started on my journey.
There are two development systems to update now – rawhide (development tree) and F15 (the upcoming version). I wanted to update both of these to the latest upstream version, 17.90. I also wanted to update the stable Fedora 14 package to an upstream bug-fix release, version 16.1.1.
Cloning deja-dup from the git repo put me in the rawhide branch by default. I updated the spec file – increasing the version, adding python-cloudfiles as a new dependency, and putting in a detailed changelog. I then committed that to my local git repo with a comment linking to upstream. I then pulled those changes from rawhide into the f15 branch and updated f14.
Author: Christopher Smart
Date: Sat Mar 5 21:23:07 2011 +1100
Updated to upstream bugfix version 16.1.1.
"This release fixes a bug in the just-released 16.1 that caused help
documentation to not be translated."
Next I needed to test these packages, so I built a source RPM from the spec for each version. I discovered that one can either do a mock build on their local machine, or use Koji to do a scratch build on Fedora’s online build system. I did both, which worked well.
Using Koji meant I needed to first push my changes back to Fedora first though (or so I thought), so I was hesitant to do it without first checking with Rahul. This was the sort of thing that was emailed back and forth – I didn’t fully understand the system and didn’t want to break anything! For example, in order to test my F14 update I had to push back to the git repo – but what if I made a mistake in the process? Would my build on Koji push this broken package onto everyone’s system?
Fortunately, no. Once all the updating of the spec file and building is complete, the maintainer has to formally submit it into the update process before anything will happen. In addition, each package must then pass approval by other maintainers before it is approved and pushed out. You can see why it took some back and forth between Rahul and myself – I wanted to be sure I wasn’t going to do some damage 🙂
Along the way I discovered new automated ways of doing things, such as validating a spec file, automatically downloading the source tarball to update the spec file, then uploading it to the Fedora build system.
In the end though, I think that I have a pretty good grasp of the overall process and am quite excited by the prospect of becoming a Fedora maintainer. I’m hoping that deja-dup comes out with a new update soon, so that I can do another update!
I’m still a little hesitant to go and change things – I don’t want to do the wrong thing or step on anyone’s toes. I did however create my own page on the Fedora Wiki, complete with a hackergotchi, of course.
So once again, thanks to Rahul for his patience and guidance 🙂
That is way cool. I am about 10 YEARS away from anything like this!!!! You rock!
No, not really 🙂 I’m sure you could do this once shown, it’s not that hard. Plus, I plan to write up an overview document on the wiki with the instructions at some stage.
Congrats!! This seems like something that will keep you busy!
True that. Especially in amongst work and Uni!
Nice overview, but a bit of a correction:
“In addition, each package must then pass approval by other maintainers before it is approved and pushed out.”
Well, not exactly. 🙂
Updates to critical path packages – https://fedoraproject.org/wiki/Critical_Path_Packages – require approval from two testers (not necessarily maintainers), including one proven tester – https://fedoraproject.org/wiki/Proven_tester (in Bodhi) – before they go from updates-testing into updates (stable). Updates to non-critical path packages do not require any explicit approval, but there’s a holding period before you can push the update to stable without any positive feedback in Bodhi (I think it’s a week). If you get any positive feedback, you can push the update to stable immediately.
For Rawhide, none of this applies and all successful builds go straight into the tree.
For a Branched pre-release, the same basic policy as for stable releases applies, but the thresholds are modified somewhat (only one vote from a proven tester is required for critpath updates, and the holding period for non-critpath updates with no feedback is shorter, I think 3 days).
This is (mostly) documented at https://fedoraproject.org/wiki/Updates_Policy .
Thanks very much for your comment and clarification. There’s still quite a bit to read and take all in! 😉