Meeting summary/minutes from today's FESCo meeting (2010-09-14)
mjg59 at srcf.ucam.org
Wed Sep 15 01:52:51 UTC 2010
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
More information about the devel