Meeting summary/minutes from today's FESCo meeting (2010-09-14)

[Matthew Garrett]

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 at srcf.ucam.org