This is the second release running that another component of the Fedora Feature process has come and bitten me in the proverbial. This time its the “Major Features”(tm), must be landed by the Alpha release, part of the process.
For Fedora 14 the feature that abused this requirement was python 2.7. Rather than landing by the Alpha release it landed moments before we locked down for the Beta breaking things horribly and causing massive amounts of work post Beta when we were suppose to be stabilising the release. This affected Sugar amongst massively as that’s the language its primarily written in.
For Fedora 15 the abuse was by NetworkManager. Complete API borkage with very little notification (well at least that I saw) moments before the Beta release. Unfortunately again its Sugar that takes the hit and it looks like we’re not going to have it working by release. I’m doing my best to attempt to teach myself python to hack up some form of support but given I’m just learning python converting a network stack isn’t the easiest of things, and work seems to get in the way at the least opportune of moments.
I don’t want to blame developers. Everyone has different agenda’s and issues that they try and balance but what really pisses me off is that its not in by the alpha, or if its going to be massively late there needs to be a lot more heads up or assistance. BTW Massive big kudos to the Evolution developers for getting this pretty close to right for both the F-14 and F-15 releases as they were going through huge API changes. If that’s not going to happen then FESCo or The Board or whoever is in charge of developing the “feature rules and policy” actually needs to bloody well enforce them and say “sorry it needs to go in the next Release”. They do after all have all the way back to alpha of the previous release to land the feature (that was the whole purpose of forking rawhide at alpha and not later in the process) and have all the breakage they like. It gives six months for poor mugs like me to either, organise other busy upstream developers to help, or to work out how to code in python myself to fix it, rather than what seems like six days to attempt to scratch something together. It won’t be popular but maybe a single high profile incident will make everyone step back and think about others and how they may affect them.
With the upcoming FESCo and Board elections I look forward to what people have to say. Why not run for them yourself I hear you say? I’d personally love to but unfortunately with a number of other things going on in my life at the moment I don’t have the time. Either I would have to drop all the package and Sugar/OLPC stuff I’m currently doing to make enough time for it, becoming again a pure Fedora consumer, or remove all traces of the scant personal life that I currently have. I don’t currently wish to do either.
7 thoughts on “More thoughts on the Fedora Feature Process”
The problem is that you didn’t get yourself heard on https://fedorahosted.org/fesco/ticket/572.
Unfortunately, at the time the decision was made, it looked like only
kde-plasma-networkmanagementwas affected. So the
NetworkManagerdevelopers came up with a hack to make
kde-plasma-networkmanagementwork, and so the late change got accepted, due to the pressure from the GNOME camp. We (KDE SIG, or at least the members I’ve talked to on IRC) now regret having accepted that compromise, because the hack does not support the new features introduced in
kde-plasma-networkmanagementupstream and because VPN is broken in the compatibility interface and the NetworkManagement developers show no interest in fixing that at all.
But the impact to Sugar was not known at all because unfortunately nobody from the Sugar camp spoke up against the changes, and the
NetworkManagerdevelopers claimed they had already ported everything except
I never knew that ticket existed until you mentioned it then. Pretty hard to get heard when it wasn’t publicised. The first I knew of the change was when I saw a patch to a completely unrelated package that I maintain. Believe me if I knew of that ticket I would have made myself heard. I’m on both devel and desktop lists and I don’t ever remember seeing it shouted out to devel like all API breaks are suppose to be announced.
it was discussed on the -devel list a bit, in the context of a FESCo meeting agenda iirc.
that’s the problem. It was explicitly announced on a subject that covers the change, there wasn’t a bug opened for the maintainers of the affected packages, nor were they contacted directly. Its impossible for someone to follow all threads every where.
The feature process only applies to things that are actually features. NetworkManager 0.9 isn’t a Fedora 15 Feature: it’s nowhere on http://fedoraproject.org/wiki/Releases/15/FeatureList . It’s just a version bump which breaks the API.
This is, of course, kind of a problem with the feature process: the bits of it that are designed to ensure that large changes land early are kind of rendered moot by the fact that you can simply not declare your large change to be a ‘feature’ and hence ignore the feature process entirely.
The updates policy – https://fedoraproject.org/wiki/Updates_Policy – does apply, but it is rather more lax than the feature process, and only really tightens up on API/ABI changes after Beta.
NM most certainly is a new feature.
2. improvements or changes that require non-trivial cross-package integration
4. significant enough that if not completed properly or without a proper backup plan could delay the release
This is one of the two issues that the Feature Process was created to address.
That is what I thought but what happens when people or teams don’t use the feature process for such a change? At the moment its not dropped out or rolled back and is there such a facility with the policy to do so?
Comments are closed.