[gentoo-dev] QA Proposal v3

[gentoo-dev] QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 3547 bytes --]

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.
* 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.
* The QA team may also offer to fix obvious typos and similar minor
  issues, and silence from the package maintainers can be taken as agreement
  in such situations.  Coding style issues fall under this category, and
  while they are not severe, they can make automated checks of the tree more
  difficult.
* There will be cases when our tools are incapable of handling a certain
  situation and policy must be broken in order to get something working
  completely.  This will hopefully not occur very often but each time it
  does occur, the QA team and the maintainer will come to some agreement
  on an interim solution and it is expected that a bug will be opened with
  the appropriate team to work towards a correct solution.
* In the case of disagreement on policy among QA members, the majority
  of established QA members must agree with the action.
* 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.
* Just because a particular QA violation has yet to cause an issue does
  not change the fact that it is still a QA violation.
* 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.
* 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.
* In order to join the QA team, you must be a developer for at least 4
  months and must ask the current lead for approval.
* The QA team will work with Recruiters to keep related documentation
  and quizzes up to date, so that up and coming developers will have access
  to all of the necessary information to avoid past problems.
* 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.


-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] QA Proposal v3

[Thomas Cort]

> * 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.

Maybe there should be something more here about dealing with maintainers 
who are refusing to cooperate. What if the maintainer reverts the 
changes that the QA team makes?

> * 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

Why isn't this list meant to be comprehensive? I know that there will be 
QA problems that come up that you haven't thought about yet, but it 
would be really really nice to have a list with all of the QA problems 
that could come up and how to fix them. It would help new developers 
avoid mistakes and it would benefit the QA team by giving them a 
document that they can direct devs to when there is a problem.

~tcort
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Daniel Goller]

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


> * QA will take an active role in cleaning up unmaintained and broken
>   packages from the tree. 

I hope this is meant to read more like:

"QA will take an active role in cleaning up unmaintained packages from
the tree if they are severly broken or have open security issues."


What i mean here is that unmaintained != broken (if it  works, leave it
be), and partially broken !=  unworthy to be in the tree, for example if
nothing provides equal functions, why get rid of something that works
for the most part, so unmaintained with some bugs just means maintainer
needed, not "buhbye!"

severly broken here would mean does not even compile, or gui comes up
but most functions just create a segfault.

In short, i would like to see the above sentence changed to something a
little less radical. (example provided)

Thanks

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

iD8DBQFESvGh/aM9DdBw91cRArWqAJ9JhfuUr1JvJr4xgOZn0aAlMeil6wCeN22x
rwtxKd77YT2mNTAZbIEyPps=
=akQa
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Colin Kingsley]

Thomas Cort wrote:
>> * 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
> 
> 
> Why isn't this list meant to be comprehensive? I know that there will be 
> QA problems that come up that you haven't thought about yet, but it 
> would be really really nice to have a list with all of the QA problems 
> that could come up and how to fix them. It would help new developers 
> avoid mistakes and it would benefit the QA team by giving them a 
> document that they can direct devs to when there is a problem.
> 
> ~tcort

Is a complete list of QA problems possible? I don't think that would 
necessarily be a finite list.

-tercel
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Daniel Goller]

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

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

> * 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

> * The QA team may also offer to fix obvious typos and similar minor
>   issues, and silence from the package maintainers can be taken as agreement
>   in such situations.  Coding style issues fall under this category, and
>   while they are not severe, they can make automated checks of the tree more
>   difficult.

thanks for the offer, sounds good

> * There will be cases when our tools are incapable of handling a certain
>   situation and policy must be broken in order to get something working
>   completely.  This will hopefully not occur very often but each time it
>   does occur, the QA team and the maintainer will come to some agreement
>   on an interim solution and it is expected that a bug will be opened with
>   the appropriate team to work towards a correct solution.

sounds reasonable

> * 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?

> * 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.

The default could be that the ebuild not be touched unless it is a issue
that breaks the tree or is security related where time is of the
essence. word it in that direction?

> * 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

> * 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?

> * 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.

> * In order to join the QA team, you must be a developer for at least 4
>   months and must ask the current lead for approval.

that shouldn't be too hard

> * The QA team will work with Recruiters to keep related documentation
>   and quizzes up to date, so that up and coming developers will have access
>   to all of the necessary information to avoid past problems.

sounds good

> * 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

finally had some time to read this in more detail
hope the feedback helps

Daniel


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

iD8DBQFETFkI/aM9DdBw91cRAgQWAKDBuxieQZTwcGw+VC2IGGNaGUnO8gCcDPTJ
H296TQyH7S1dA3NfbscYj5Q=
=ypTj
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Daniel Goller]

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


>>> * 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?
> 
defining 'breakage' here might also be a good idea, sorry for not adding
this to the previous post, i really should have asked for that one

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

iD8DBQFETFpo/aM9DdBw91cRAsBvAKDABphEPy1zWVGaHqqZ8JhBYvOTEgCeNa5B
mwUCZpBBis2TnK3gyejjn9Q=
=/ig2
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: QA Proposal v3

[Duncan]

Daniel Goller posted <444C5909.1010606@gentoo.org>, excerpted below,  on
Sun, 23 Apr 2006 23:50:17 -0500:

>> * 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?

Don't take this wrong but you did mention you weren't a native English
speaker, and I think this the interpretation demonstrates that. 
(That isn't to say it couldn't be made clearer, just that your
interpretation isn't likely to occur to a native English speaker, thus the
discussion.)

To me (as a native English speaker), it's strange to consider that a
reference to /this/ policy.  Rather, the reference is to QA policy and
decision making in general -- how a disagreement on QA policy between
members of the QA team is to be handled.

That this is the case would be particularly obvious in context, coming
after (as it does) the previous point, dealing with exceptions due to
imperfect tools and mentioning that there /are/ such exceptions.  The
point in question above doesn't /only/ deal with that, thus it's its own
bullet point, but the thought is clearly to provide some guidance in
dynamic situations, where for whatever reason there's a difference of
opinion within QA on how to proceed (as an imperfect tool exception could
legitimately provoke, again, the handy example, not the only case, thus
it's not a sub-point but its own bullet point).

The other alternative would be unanimous agreement or the decision of the
maintainer in question rules, altho there is of course the middle
possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered
to overrule the maintainer.

As I said, your interpretation, that it applied to /this/ policy, wouldn't
be likely to occur to a native English speaker, and does in fact seem a
bit odd.  However, that's not to say the point isn't valid, as it's
certainly best that the document be clear to all, including non-native
English speakers to whom the point as now written obviously isn't entirely
clear.

Actually, the point about a 2/3 (or whatever) super-majority, vs. simple
majority of the QA team needed to overrule a maintainer, is a good one to
debate as well. Perhaps developers would be less worried about abuse if
the majority required was stronger, thus improving the safety margin. 
Assuming that's the case, the policy as a whole could probably have more
teeth in the case of a super-majority required, than would be possible if
it's only a simple majority.  If some sort of a super-majority was
required, it should be easier to accept certain decisions, when they
seriously impact a developer or Gentoo in general.  I know if I had a
disagreement and out of a five member team, two sided with me and three
against, making it a majority-of-one, I'd be less comfortable with the
outcome than if it had required a 2/3 majority, and thus 4 members of the
team voting against me.

Another way to approach it would be to state that for purposes of packages
(s)he maintains, a developer gets one vote on the QA as well.  Thus, in
ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1
would be deadlock with the developer siding on the keep things as they are
side.

The idea in either case is to minimize the possibility of something
occurring without enough of a majority opinion to make the decision look
arbitrary or subject to immediate reversal upon the whims of a single QA
team member, without making it impotent in certain cases due to a
requirement for a unanimous decision.  Reason in the middle ground?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: QA Proposal v3

[Duncan]

Duncan posted <pan.2006.04.24.06.30.40.205111@cox.net>, excerpted below, 
on Sun, 23 Apr 2006 23:30:41 -0700:

> The idea in either case is to minimize the possibility of something
> occurring without enough of a majority opinion to make the decision look
> arbitrary or subject to immediate reversal upon the whims of a single QA
> team member, without making it impotent in certain cases due to a
> requirement for a unanimous decision.  Reason in the middle ground?

Argh!  Make that:

The idea in either case is to minimize the possibility of something
occurring without enough of a majority opinion, SUCH THAT the decision
looks arbitrary...

IOW, it looks arbitrary if the majority is only a single person. 
Increasing the necessary majority decreases the appearance of
arbitrariness.  As such, given a suitable super-majority requirement,
giving the QA team enough authority to be effective shouldn't be an issue,
because all sides should be comfortable that the decision isn't in fact
arbitrary, nor could it be, due to the super-majority requirement.

Of course, if the QA team ends up being only a couple people...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: QA Proposal v3

[Daniel Goller]

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

Duncan wrote:
> Daniel Goller posted <444C5909.1010606@gentoo.org>, excerpted below,  on
> Sun, 23 Apr 2006 23:50:17 -0500:
> 
>>> * 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?
> 
> Don't take this wrong but you did mention you weren't a native English
> speaker, and I think this the interpretation demonstrates that. 
> (That isn't to say it couldn't be made clearer, just that your
> interpretation isn't likely to occur to a native English speaker, thus the
> discussion.)

no, there should not be disagreement on the QA policy, seriously, only
disagreement on the solution is logical and possible
the exception is not covered by policy, the possibility for exceptions
is however integrated into the policy, so the only disagreements could
be in how the exception is implemented, maybe 3 QA devs find solution A
best while 5 find B best, but all devs should agree that an exception is
granted because the current tools do not allow adherence to usual QA
standards

> 
> To me (as a native English speaker), it's strange to consider that a
> reference to /this/ policy.  Rather, the reference is to QA policy and
> decision making in general -- how a disagreement on QA policy between
> members of the QA team is to be handled.

to me a policy is the writing as a whole with all the bullet points, not
each individual point being a policy, and even if you would explain yes
each point is a policy, then the points should not be argued within QA,
see above for what would leave room for argument

> 
> That this is the case would be particularly obvious in context, coming
> after (as it does) the previous point, dealing with exceptions due to
> imperfect tools and mentioning that there /are/ such exceptions.  The
> point in question above doesn't /only/ deal with that, thus it's its own
> bullet point, but the thought is clearly to provide some guidance in
> dynamic situations, where for whatever reason there's a difference of
> opinion within QA on how to proceed (as an imperfect tool exception could
> legitimately provoke, again, the handy example, not the only case, thus
> it's not a sub-point but its own bullet point).
> 
> The other alternative would be unanimous agreement or the decision of the
> maintainer in question rules, altho there is of course the middle
> possibilities of say 3/5 or 2/3 or 3/4 super-majority required in ordered
> to overrule the maintainer.
> 
> As I said, your interpretation, that it applied to /this/ policy, wouldn't
> be likely to occur to a native English speaker, and does in fact seem a
> bit odd.  However, that's not to say the point isn't valid, as it's
> certainly best that the document be clear to all, including non-native
> English speakers to whom the point as now written obviously isn't entirely
> clear.

i'm afraid i have to repeat that the policy is the sum of all points,
the writing, so all QA devs should agree on this one policy, and only
have discussions on solution to individual points, and not the actual
points of the policy, if there was room for discussion of the points of
the policy, then the policy is not ready for consumption by the
developer community

> 
> Actually, the point about a 2/3 (or whatever) super-majority, vs. simple
> majority of the QA team needed to overrule a maintainer, is a good one to
> debate as well. Perhaps developers would be less worried about abuse if
> the majority required was stronger, thus improving the safety margin. 
> Assuming that's the case, the policy as a whole could probably have more
> teeth in the case of a super-majority required, than would be possible if
> it's only a simple majority.  If some sort of a super-majority was
> required, it should be easier to accept certain decisions, when they
> seriously impact a developer or Gentoo in general.  I know if I had a
> disagreement and out of a five member team, two sided with me and three
> against, making it a majority-of-one, I'd be less comfortable with the
> outcome than if it had required a 2/3 majority, and thus 4 members of the
> team voting against me.
> 
> Another way to approach it would be to state that for purposes of packages
> (s)he maintains, a developer gets one vote on the QA as well.  Thus, in
> ordered to overrule h(im|er), the QA team would need 50%+2, since 50%+1
> would be deadlock with the developer siding on the keep things as they are
> side.
> 
> The idea in either case is to minimize the possibility of something
> occurring without enough of a majority opinion to make the decision look
> arbitrary or subject to immediate reversal upon the whims of a single QA
> team member, without making it impotent in certain cases due to a
> requirement for a unanimous decision.  Reason in the middle ground?
> 

well, i do find your majority rules interesting, something that should
be discussed and the best solution should be written down and made part
of the policy


the reason for my feedback was to have things laid out much clearer,
less vague and thus avoid problems down the road by situations occuring
in which things go like "well i thought i (a QA dev) had the right to
...." or "i (reg dev) didn't know they (QA) could do ..."
be clear on both sides by laying this out so there are no
misunderstandings or misinterpretations


and seriously, i never have heard a single point of a policy be called a
policy, thus my reply as it has been to the point and in this reply

Thanks,

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

iD8DBQFETHtg/aM9DdBw91cRArQ1AKCzgD4q7Xmng+R4dGbOw629njM/mgCfdj+P
qMmtY4iSgvG1LOPLACvi6zM=
=D4eg
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

On Sunday 23 April 2006 01:51, 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.

It looks reasonable to me.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 200 bytes --]

[gentoo-dev] Re: Re: QA Proposal v3

[Duncan]

Daniel Goller posted <444C7B60.1030608@gentoo.org>, excerpted below,  on
Mon, 24 Apr 2006 02:16:48 -0500:

> the reason for my feedback was to have things laid out much clearer,
> less vague and thus avoid problems down the road by situations occuring
> in which things go like "well i thought i (a QA dev) had the right to
> ...." or "i (reg dev) didn't know they (QA) could do ..."
> be clear on both sides by laying this out so there are no
> misunderstandings or misinterpretations

Agreed.  I'm not prepared to try to argue the definition of "policy"
further here, so I'll yield the point.  If others find value in the
point, they'll take it up.  If not, well it must not have been that
important to other than you and me after all.  =8^)

In any case, two things of value came of it.  For Gentoo, it provoked the
super-majority idea, which may or may not resonate enough to take root but
I think it's worth debating, anyway.  For myself, I became aware of a
word interpretation inconsistency I wasn't aware of, thus gaining insight
into myself. Maybe it's me that's out of sync.  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 5345 bytes --]

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.

> > * 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
as soon as possible - exactly what it says, as soon as possible

Basically, use common sense here please :)

> > * 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.

> > * 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.

> > * 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.

> > * 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.

> > * 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.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Mark Loeser <halcy0n@gentoo.org> said:
> 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.

On second reading, this could be worded better.  Taking direct action is
necessary when something is an emergency, maintainers do not cooperate,
etc.  It is all elaborated on later on in the document.  I did not mean
to say that it is always necessary to take direct action.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]

Thomas Cort <tcort@gentoo.org> said:
> >* 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.
> 
> Maybe there should be something more here about dealing with maintainers 
> who are refusing to cooperate. What if the maintainer reverts the 
> changes that the QA team makes?

Well then, we have a problem and that is when we would call in devrel to
handle it.  I really hope at no point it comes to the situation where we
need to override what the maintainer thinks is best, much less call in
devrel.

> >* 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
> 
> Why isn't this list meant to be comprehensive? I know that there will be 
> QA problems that come up that you haven't thought about yet, but it 
> would be really really nice to have a list with all of the QA problems 
> that could come up and how to fix them. It would help new developers 
> avoid mistakes and it would benefit the QA team by giving them a 
> document that they can direct devs to when there is a problem.

I addressed this in my reply to morfic, basically, it is just the
wording that threw you off :)  I mean that it can never be complete, so
don't think it ever is.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-dev] Re: QA Proposal v3

[Duncan]

Mark Loeser posted <20060424131128.GH690@aerie.halcy0n.com>, excerpted
below,  on Mon, 24 Apr 2006 09:11:28 -0400:

>> > * 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.

What about "... cleaning up and removing from the tree unmaintained
packages as they are found to be broken."?

If I'm not mistaken, that makes the meaning crystal clear.  (Maybe
"cleaning up /or/ removing"?)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]

Duncan <1i5t5.duncan@cox.net> said:
> Mark Loeser posted <20060424131128.GH690@aerie.halcy0n.com>, excerpted
> below,  on Mon, 24 Apr 2006 09:11:28 -0400:
> 
> >> > * 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.
> 
> What about "... cleaning up and removing from the tree unmaintained
> packages as they are found to be broken."?

Works for me, and gets the point across more clearly.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] QA Proposal v3

[Mark Loeser]

[-- Attachment #1: Type: text/plain, Size: 464 bytes --]

And now in GLEP format for those who like that sort of thing :)

http://www.gentoo.org/proj/en/glep/glep-0048.html


I made the two wording changes so it is more clear what I wanted to
communicate.

-- 
Mark Loeser   -   Gentoo Developer (cpp gcc-porting qa toolchain x86)
email         -   halcy0n AT gentoo DOT org
                  mark AT halcy0n DOT com
web           -   http://dev.gentoo.org/~halcy0n/
                  http://www.halcy0n.com

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-dev] QA Proposal v3

[Daniel Goller]

-----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