Re: [gentoo-project] Call for agenda items - Council meeting 2014-02-25

[Tom Wijsman]

On Mon, 24 Feb 2014 22:43:41 +0100
Chí-Thanh Christopher Nguyễn <chithanh@g.o> wrote:

> Tom Wijsman schrieb:
> >> Thanks, I would like to phrase the question a little more
> >> precisely:
> >>
> >> I would like to ask council to state whether the QA team has the
> >> authority to mandate a policy when there is neither general
> >> agreement that this policy is a good thing, nor the policy would
> >> avert any kind of immediate serious problem for users.
> > That can be reduced to the question whether QA is considered
> > serious.
>
> I don't think so. If the council answers this question in the
> negative, QA still has its emergency powers and can enforce the
> policy set by the council.
> QA can also propose any new policy they consider useful to the
> council, which can then hear the opposing sides and make a decision
> based on that.

You describe a Gentoo Developer, apart from the small difference that
they have this emergency power; when it comes to it, that power is
quite similar to having a Gentoo Developer revert according to policy
and that deemed as OK (under the assumption of there being no QA team).

> > (There is a majority that agrees as well as a serious problem to
> > users in the GTK+ USE flag situation; the former can be deduced
> > from the mailing list, the latter can be realized when controlling
> > the USE flag among a lot of GTK+ packages. It is something that can
> > be done later; on the other hand, if we categorize everything that
> > way it halts progress)
>
> The gtk flag naming problem is not serious in the sense that it will
> break user systems.

It depends on how you define the words; but I find it a serious issue
if you have an USE flag that works one way in a set of packages and
works the other way in another set of packages, it is broken in the
sense that the user now has to use package.use if he has a lot of
packages that have a gtk flag and needs that flag to behave.

> Additionally, it has been known and discussed for a long time.

If it comes up again and again on ML, upsets people in bugs, have people
bring it up independently to both QA and Council; it is of much more
concern than for example a thread about small bug wrangling details.

> Establishing a gtk USE flag policy did not become suddenly so urgent
> that next council meeting was too far in the future.

The discussions, pings and mails act as a nagging reminder.

> > The GLEP states that we can
> >
> >  1) maintain a list of current "QA Standards";
> >
> >  2) ensure all developer tools are in line with the current QA
> >  standards;
> >
> >  3) and apply it as per "In the event that a developer still insists
> >  that a package does not break QA standards, an appeal can be made
> > at the next council meeting. The package should be dealt with per
> > QA's request until such a time that a decision is made by the
> > council."
> >
> > which effectively makes the "QA Standards" act as policy.
>
> I don't think that it is necessarily the case. "QA standard" could
> also mean telling developers to either use gtk USE flags in the QA
> team recommended way, or ensuring through other means that users to
> not encounter unexpected breakage.

The GNOME team's internal policy was a recommendation; as can be seen
from the current state, that doesn't ensure anything. What other means
would ensure that users do not have to micro manage with package.use?

> Another possible interpretation is that QA standards codify
> established good practices which are largely non-controversial (it
> was attempted with saying that live ebuilds should be unkeyworded or
> p.mask'ed IIRC)..

It also depends on who discovers the new problems, who forms the
explanations, who decides how to fix the problem; ...

For that, you can look at mentions like "This is done primarily by
finding and pointing out issues to maintainers and, where necessary,
taking direct action.". But then you once again need to know whether
"issues" are meant as "policy violation", or as "breakage", I think we
can go on for a while here...

We need to remind ourselves that a GLEP is a "Gentoo Linux Enhancement
Proposals" and that it is nowhere a picture perfect policy; so, yes, I
hope the seriousness (and associated consequences) is clarified.

GLEP 48 addresses controversy with "In the event that a developer still
insists that a package does not break QA standards, an appeal can be
made at the next council meeting. The package should be dealt with per
QA's request until such a time that a decision is made by the council.".

> > As "QA Standards" under this interpretation are needed to raise
> > quality; the council should clarify whether we are able to raise the
> > quality level, or rather are restricted to what exists and expect
> > the council to raise the quality instead (by having the council do
> > that).
>
> "raise the quality" is very subjective. This would not restrict QA
> powers at all, because almost any policy can claim that as its aim.

Policy formulation is a power that has a near direct effect on quality.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@g.o
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D