On Wed, Sep 15, 2010 at 01:05:34AM +0200, Lennart Poettering wrote: > So, we closed all blocker bugs, we worked through the vast majority of > other bugs. I dealt with almost all issues raised in Bill's list, only > few small issues left. While there are some bugs open, we did our > homework. I was kept in the impression during the last week that these > are the criteria to get systemd into F14. But what happens? Out of > nowhere completely new criteria are created, and used to bring this > project down. The criteria primarily flowed from Notting's discussion of systemd acceptance criteria. Was that well communicated beforehand? No. Did all of those criteria get translated into appropriate bugzilla entries? No. Should we have handled this case better? Absolutely yes. With hindsight it was entirely inappropriate of us to make this decision without attempting to involve you in the discussion. I'm genuinely sorry about that. But since this is the situation that we're in now, I think what we're left with is the opportunity to identify what went wrong with our process and how to avoid this kind of thing in future. Systemd was a relatively unusual feature, in that it's core functionality that impacts every spin, it exposes aspects of its functionality in multiple areas and it didn't exist during our previous release cycle. It's not obvious in advance what criteria we should be using for determining whether this kind of feature is acceptable or not. The right time for doing so would probably have been at the initial feature acceptance stage, and in future I'd like to suggest that for features of a similar scale to systemd we ensure that that's done. It makes the feature acceptance process significantly more difficult and longer, but it's time that will almost certainly otherwise be spent in mailing list discussion of the same thing. Having it presented in a structured manner beforehand is proably a net reduction in difficulty. As an aside, it's also obvious that the degree of scruitiny placed on systemd is grossly disproportionate to features in previous releases. I can see why this is frustrating, but I think it's a necessary part of the development of the distribution. NetworkManager was a disruptive piece of core infrastructure that didn't initially provide feature parity with the nfrastructure it replaced, but NetworkManager was necessary to make Fedora a usable desktop operating system in a large number of use cases. In contrast, we're now at the point where we *have* most of the infrastructure to provide a usable desktop operating system. I think it's entirely justified that our tolerance for churn has diminished, and I think being a little more conservative with new features is entirely in line with modifying our udpate policy to ensure that users have a more consistent experience. > This is a really unfriendly move: I cannot win a game where the moment the > game nears it ends completely new rules are created. Quite frankly, this > is a recipe to piss people off, not to make people love developing for > Fedora. Yes, I am very disappointed, Fedora. > > It's also nice to not even bother to ping me for the FESCO > discussion. This all reads like a page from the book "How to piss people > off and scare them away in 7 days". You make up new rules, and then > don't bother to invite the folks mostky affected when you apply them. > > Oh, and next time, if you guys plan a move like that, then please do it > a couple of weeks earlier, so that I can find funnier things to do then > make you folks happy, since that's apparently not possible. I absolutely agree with your criticism. We should do better, and I hope that in future we will. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
