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

[drago01]

On Wed, Sep 15, 2010 at 12:27 PM, M A Young <m.a.young at durham.ac.uk> wrote:
> On Wed, 15 Sep 2010, drago01 wrote:
>
>> I think the main point here wasn't "there are bugs #X, #Y and #Z  that
>> can't be fixed in time so we should revert" but a "we have a bad
>> feeling / are nervous so lets revert" ... the later isn't really a
>> technical decision basis and can (and here it did) piss of the one
>> working on said feature.
>
> In this case the "bad feeling" is justified, because there were too many
> problems too late in the release cycle.

I didn't comment on whether it was justified or not. Just that it is a
bad practice to decide on subjective matters.
Pointing out the "too many problems" and base the decision on them
would be fine (and problems that are already fixed do not count).

The only real issues pointed out where lack of documentation and
system-config-service integration for native services.
Neither that we have with upstart so not really a regression and thus
warrant a reject.

Anyway the point I am trying to make is that technical decisions (and
that is what FESCo is for after all) should be based on *objective*
rather than *subjective* matters.

> It isn't a matter of whether all
> the known bugs are fixed but whether we can be reasonably confident that
> there aren't any more critical bugs that haven't been reported yet or have
> been introduced by the latest updates.

There is no way to know that ... based on this we should not add
anything new "because we can't be sure that they aren't any unknown
critical bugs".
It should be rather "have we found bugs in our testing that can't be
fixed in time" .. yes -> punt to next release; no -> ship it

> Maybe there should be some sort of
> stability test for core features (eg. no major changes, no more than a
> certain number of blocker bugs raised) after the alpha phase.

We already have that its called "Feature freeze".

>> The acceptance criteria should have been present from day one (i.e the
>> day the feature was accepted) not shortly before beta (which pretty
>> much limits the time to work to met them).
>
> I agree. I was worried when systemd appeared in F14 just before the alpha.
> Really we should have been much closer to where we are now at the start of
> the alpha phase, and systemd should have gone in soon after F13 was forked
> off.

IIRC systemd wasn't even written back then.