[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] QA Proposal v3
From:       Daniel Goller <morfic () gentoo ! org>
Date:       2006-04-25 0:55:50
Message-ID: 444D7396.3070605 () gentoo ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Loeser wrote:
> Daniel Goller <morfic@gentoo.org> said:
>> Mark Loeser wrote:
>>> Here is the newest revision of my proposal.  Not much has changed, but I
>>> added and changed some small things.  Constructive feedback is
>>> appreciated.  I'd like to get this voted on by the council at the next
>>> meeting.
>>>
>>> * The QA team's purpose is to provide cross-team assistance in keeping
>>>   the tree in a good state. This is done primarily by finding and pointing
>>>   out issues to maintainers and, where necessary, taking direct action.
>> describe what makes it necessary and what actions will be taken
>> or if the paragraphs below are meant to do that, you can save that line
>> in that paragraph
> 
> What makes it necessary is if something is broken or goes against
> policy, and the actions are listed below.  I was pretty sure this went
> without saying.

is what you are saying that the line is superfluous since it is covered
by the paragraph below ?

> 
>>> * In case of emergency, or if package maintainers refuse to cooperate,
>>>   the QA team may take action themselves to fix the problem.  The QA
>>>   team does not want to override the maintainer's wishes by default, but only
>>>   wish to do so when the team finds it is in the best interest of users
>>>   and fellow developers to have the issue addressed as soon as possible.
>> define emergency, define as soon as possible (some bugs might be quite
>> tricky to track and might be put on back burner and what little time is
>> available used on things not taking up equal times), how do you know ia
>> dev is not cooperating or if i he/she is just prioritizing
> 
> emergency - something that is broken and affects a great number of users

you could elaborate on "broken" some more, since you seem to have
skipped over my addendum to my email and the terms 'broken' and
'breakage' are used as if they define themselves

> as soon as possible - exactly what it says, as soon as possible


> 
> Basically, use common sense here please :)

common sense ain't that common, to think any two people consider the
same thing as common sense is an assumption, and those are not that good

> 
>>> * In the case of disagreement on policy among QA members, the majority
>>>   of established QA members must agree with the action.
>> you shouldn't disagree about this policy, or you might as well not have
>> this document, write disagree on the solution maybe?
> 
> It was not referring to *this* policy, but the exact policy that is
> dealing with the problem at hand.  In this context, it was meant to be
> read that what some of us to believe is a problem is actually a problem
> here, and that the solution is reasonable.  I will write the whole thing
> out to improve clarity.
>
ok, so we refer to points of this policy as policies. do not leave
wiggle room, either it is a problem or not. discuss the solutions? yes
of course.

>>> * Just because a particular QA violation has yet to cause an issue does
>>>   not change the fact that it is still a QA violation.
>> Then you must be talking about coding style here? remove the point and
>> add it above to coding style, as an example why you will deal with the
>> coding style maybe? no other violation should be left to such vagueness
> 
> No, I'm talking about problems that were not noticed before and we just
> realized the implications of what we are doing.
> 

this can then be struck or combined to the point where you say the list
is not finite, i really wish you would say it is comprehensive yet not
finite, like list everything as a reference, so people can look at it if
they go "oh i think i can do it this way!" then they read the list and
find it in the minor/major/critical section of the comprehensive yet not
finite document.
comprehensive does not mean finite, so i would like to understand why
you refuse to make it a comprehensive list and call it that

>>> * If a particular developer persistently causes breakage, the QA team
>>>   may request that devrel re-evaluates that developer's commit rights.
>>>   Evidence of past breakages will be presented with this request to
>>>   devrel.

>> define persistently, how do you presistently cause breakage? maybe this
>> is one of those non native english speaker moments, but doesn't that
>> mean like every commit is botched?
> 
> Not every commit, but a recognizable pattern can be seen.
>

let's say someone consistently brings us good on the toolchain, but in
the process we get a few hiccups, is that such a pattern that would get
him to meet devrel? (considering it is him who does all the work and the
fixing "as soon as possible" anyway)

are (picking a number) 10 wrong digests the same as 10 instances where
glibc/gcc wouldn't build, or did build but caused a broken system?

>>> * The QA team will maintain a list of current "QA Standards" with
>>>   explanations as to why they are problems, and how to fix the problem.
>>>   The list is not meant by any means to be a comprehensive document, but
>>>   rather a dynamic document that will be updated as new problems are
>>>   discovered.  The QA team will also do their best to ensure all developer
>>>   tools are in line with the current QA standards.
>> as said in the other two posts, maybe write it is a comprehensive list,
>> just that it is not finite? that might clear this point up.
> 
> The wording as it currently stands is what I mean for it to say.  Our
> document should never be considered to cover *every* single thing you
> can do wrong.  It also covers that the document is never complete, and
> that we are always working on improving it.
> 

see above how this list could be utilized, so it should list it all,
really, avoids people going "well, it wasn't listed, repoman didn't
complain, so i thought it was ok"
might also be nice to use that list when you inherit a package from
someone that builds and works fine, but you could go sit down check all
the solutions in it against the list and clean up the ebuild, thus
helping the QA team in the process, aside from not creating new ebuilds
with evil things in them

either way, can you provide a list of such things as they stand right
now? to look over, i think it should be part of the policy/glep and
should be seen beforehand

>>> * QA will take an active role in cleaning up unmaintained and broken
>>>   packages from the tree.  It is also encouraged of members of the QA team to
>>>   assist in mentoring new developers that wish to take over unmaintained
>>>   packages/herds.
>>>
>>>
>> i am not sure how to read this one, it could mean broken packages that
>> are unmaintained, but how it is written it could also mean unmaintained
>>   || broken, not only unmaintained && broken, i really wish you would at
>> least consider not killing off unmaintained and not broken packages, and
>> word it in some way that this comes out clear in that paragraph
> 
> It is written exactly how I meant for it to be interpretted.  We will be
> removing things that are unmaintained *and* broken.  I'm sure the
> security team will agree that this is a problem that currently plagues
> them as well, and I think we can help them out by doing what we can in
> this regard.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFETXOU/aM9DdBw91cRAhzlAKCIKqYLXzLa9tvv+gmzBvOwKgpmUACfe+ly
6t2AX/8lAswhv5/H/mNP+0A=
=W+Wp
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[prev in list] [next in list] [prev in thread] [next in thread]