[gentoo-dev] [RFC] QA Team's role

[gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

The following is a small blurb which we would like the council to decide
on at their next meeting.  This came about after discussions with QA team
members, the Devrel QA liaison, and a few council members.  If anyone
has any suggestions for how it could be improved, I'd appreciate it.

Yes, Gentoo is supposed to be fun, but we also have a responsibility to our
users to ensure we are providing them with the best possible distro we
can.  We are not out to get anyone, and hope that we never have to do
anything except ask you to fix the problem we have found.

And here is the document:

* The QA team's purpose is to provide cross-herd 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.
* 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.
* In case of emergency, or if package maintainers refuse to cooperate,
  the QA team may take action themselves to fix the problem.
* 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.
* In the case of disagreement on policy among QA members, the majority
  of established QA members must agree with the action.
* 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".  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.


-- 
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] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Sun, 26 Feb 2006 17:22:17 -0500 Mark Loeser <halcy0n@gentoo.org>
wrote:
| Yes, Gentoo is supposed to be fun, but we also have a responsibility
| to our users to ensure we are providing them with the best possible
| distro we can.

What, you mean the tree isn't someone's personal playground?

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

Should probably clarify that one. It's in there because there are some
situations where we find obvious typos (e.g. 'souce' instead of
'source' in DEPEND) and file a bug to alert the maintainer. If the
maintainer fixes it within a few days, there's no problem, but if not
there's no point in letting the bug sit there -- someone from QA should
be able to fix it themselves.

Equally, we don't want to just fix stuff without telling people that
they made a mistake, because then they're more likely to do it again.

| * The QA team will maintain a list of current "QA Standards".  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.

Hrm, do we want to include the thing about the QA standards providing
rationale and explanations rather than hard rules here?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[johnm]

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

On Sun, Feb 26, 2006 at 10:58:35PM +0000, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> | * The QA team will maintain a list of current "QA Standards".  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.
> 
> Hrm, do we want to include the thing about the QA standards providing
> rationale and explanations rather than hard rules here?

Either sounds fine to me as long as they are clear, simple, and where
possible brief.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Daniel Goller]

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

On Sunday 26 February 2006 16:58, Ciaran McCreesh wrote:
> On Sun, 26 Feb 2006 17:22:17 -0500 Mark Loeser <halcy0n@gentoo.org>
>
> wrote:
> | Yes, Gentoo is supposed to be fun, but we also have a responsibility
> | to our users to ensure we are providing them with the best possible
> | distro we can.
>
> What, you mean the tree isn't someone's personal playground?

I do not know what he did refer to, however the following quote from 
ChrisWhite's blog does come to mind:
[snip]
"Well, I was told by ciaranm to "stop treating the tree like your toy" or 
something to that effect. Now, I'm going to respond to this with "Yes, it is 
my toy". Before you all go phsyco and what not, let's take a look at what 
Gentoo really is."
[/snip]

Following this is a rather sad rationalization as to why it is a toy.

http://www.securesystem.info/tiki-view_blog_post.php?blogId=3&postId=111

>
> | * 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.
>
> Should probably clarify that one. It's in there because there are some
> situations where we find obvious typos (e.g. 'souce' instead of
> 'source' in DEPEND) and file a bug to alert the maintainer. If the
> maintainer fixes it within a few days, there's no problem, but if not
> there's no point in letting the bug sit there -- someone from QA should
> be able to fix it themselves.
>
> Equally, we don't want to just fix stuff without telling people that
> they made a mistake, because then they're more likely to do it again.
>
> | * The QA team will maintain a list of current "QA Standards".  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.
>
> Hrm, do we want to include the thing about the QA standards providing
> rationale and explanations rather than hard rules here?

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Ciaran McCreesh <ciaranm@gentoo.org> said:
> On Sun, 26 Feb 2006 17:22:17 -0500 Mark Loeser <halcy0n@gentoo.org>
> wrote:
> | * The QA team will maintain a list of current "QA Standards".  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.
> 
> Hrm, do we want to include the thing about the QA standards providing
> rationale and explanations rather than hard rules here?

Yea, I meant to add that in.  I'd like for all of our standards to
include explanations and show the wrong and right way to do it.

-- 
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] [RFC] QA Team's role

[johnm]

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

My personal opinion here is that a _LOT_ of this should be common sense.
But just to put in my two pennies..

On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser <halcy0n@gentoo.org> wrote:
> * The QA team's purpose is to provide cross-herd 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.

Please clarify "neccessary". I don't want to see repeat occurances of
non-issues bogging down real work. Also, please define around this a
clear and documented policy so when its enforced, its well defended.

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

I have no objections, on the understanding that there is a definitive
understanding of whats being changed and legitimate things aren't
accidentally replaced.

> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.

This is part and parcel of your first point and should be included as
part of that. ie: definition of neccessary and surrounding policy.

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

> * In the case of disagreement on policy among QA members, the majority
>   of established QA members must agree with the action.

Perhaps pushing it to an open forum on -dev/-core for consensus works
better here?

> * Just because a particular QA violation has yet to cause an issue does
>   not change the fact that it is still a QA violation.

Is this a statement or a policy? I assume that if this is policy the
non-visible issue would go about appropriate scrutany, and in turn a
long-term solution made in the situation where it is not easily
resolvable/avoidable.

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

This is the case at the moment anyways isn't it? And this shouldn't be
in a QA capacity but as a herd or individual. Perhaps this is better
suited in a different proposal?

> * The QA team will maintain a list of current "QA Standards".  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.
> 

Can I suggest that such a document is also refered to by the policy
surrounding a violations resolution. Especially when considering a
violation which is not documented (and therefore can be fairly unknown)
so that violations not listed might be treated with more tact.

Thanks for presenting this to the list.
- John

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Sun, 26 Feb 2006 23:11:21 +0000 johnm@gentoo.org wrote:
| On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser
| <halcy0n@gentoo.org> wrote:
| > * The QA team's purpose is to provide cross-herd 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.
| 
| Please clarify "neccessary". I don't want to see repeat occurances of
| non-issues bogging down real work. Also, please define around this a
| clear and documented policy so when its enforced, its well defended.

The problem is... It's impossible to document every single way in which
someone can screw up. For example, I wouldn't've thought to document
"you should not run mkdir in global scope", because I didn't think
anyone would be daft enough to do it. Policy *has* to rely upon the
basic assumption that developers won't do something crazy.

| > * 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.
| 
| I have no objections, on the understanding that there is a definitive
| understanding of whats being changed and legitimate things aren't
| accidentally replaced.

Example of where this clause would be used, had said bug not been
fixed quickly anyway: bug #122902.

| > * In the case of disagreement on policy among QA members, the
| > majority of established QA members must agree with the action.
| 
| Perhaps pushing it to an open forum on -dev/-core for consensus works
| better here?

The problem with that is, it usually ends up with too many pointless
comments from people saying how things could be fixed in the distant
future, or whining that it isn't explicitly forbidden by policy on
situations where the screwup was too weird to be documented previously.

| > * Just because a particular QA violation has yet to cause an issue
| > does not change the fact that it is still a QA violation.
| 
| Is this a statement or a policy? I assume that if this is policy the
| non-visible issue would go about appropriate scrutany, and in turn a
| long-term solution made in the situation where it is not easily
| resolvable/avoidable.

This is to cover for situations where people claim that their screwups
are ok because no-one has yet reported it as broken.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[johnm]

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

On Sun, Feb 26, 2006 at 11:21:47PM +0000, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Sun, 26 Feb 2006 23:11:21 +0000 johnm@gentoo.org wrote:
> | On Sun, Feb 26, 2006 at 05:22:17PM -0500, Mark Loeser
> | <halcy0n@gentoo.org> wrote:
> | > * The QA team's purpose is to provide cross-herd 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.
> | 
> | Please clarify "neccessary". I don't want to see repeat occurances of
> | non-issues bogging down real work. Also, please define around this a
> | clear and documented policy so when its enforced, its well defended.
> 
> The problem is... It's impossible to document every single way in which
> someone can screw up. For example, I wouldn't've thought to document
> "you should not run mkdir in global scope", because I didn't think
> anyone would be daft enough to do it. Policy *has* to rely upon the
> basic assumption that developers won't do something crazy.

yeah, thats totally understandable. Its a best-efforts thing. I just
don't want neccessary to be deemed true for something which has an
arguable point with technical merit. Blatent mkdir-esque madness would
be more black than white, and I'd hope for this to try and sanitise the
gray :)

> | > * In the case of disagreement on policy among QA members, the
> | > majority of established QA members must agree with the action.
> | 
> | Perhaps pushing it to an open forum on -dev/-core for consensus works
> | better here?
> 
> The problem with that is, it usually ends up with too many pointless
> comments from people saying how things could be fixed in the distant
> future, or whining that it isn't explicitly forbidden by policy on
> situations where the screwup was too weird to be documented previously.

This is very much a case-by-case thing. I still feel the debate should
be better answered outside of conflicting qa members.

> | > * Just because a particular QA violation has yet to cause an issue
> | > does not change the fact that it is still a QA violation.
> | 
> | Is this a statement or a policy? I assume that if this is policy the
> | non-visible issue would go about appropriate scrutany, and in turn a
> | long-term solution made in the situation where it is not easily
> | resolvable/avoidable.
> 
> This is to cover for situations where people claim that their screwups
> are ok because no-one has yet reported it as broken.

I guess that also falls under the first point, based on the quality or
vagueness of the documention :)

- John

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

johnm@gentoo.org said:
> yeah, thats totally understandable. Its a best-efforts thing. I just
> don't want neccessary to be deemed true for something which has an
> arguable point with technical merit. Blatent mkdir-esque madness would
> be more black than white, and I'd hope for this to try and sanitise the
> gray :)

Later on we tried to address that by saying the majority of the QA team
members must agree with the action.  It is normally pretty black and
white when things are necessary, and I do not know how we can accurately
describe those problems without limiting our scope.

> > The problem with that is, it usually ends up with too many pointless
> > comments from people saying how things could be fixed in the distant
> > future, or whining that it isn't explicitly forbidden by policy on
> > situations where the screwup was too weird to be documented previously.
> 
> This is very much a case-by-case thing. I still feel the debate should
> be better answered outside of conflicting qa members.

Well, instead of putting the debate into an even larger crowd, this
enables the QA team to act in the way it sees best first.  If people
believe we were wrong, then we give them the option to talk to the
council about one of our changes.  Also, we aren't unwilling to hear
alternatives and we hope to work with the maintainer on these problems.

-- 
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] [RFC] QA Team's role

[Donnie Berkholz]

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

Mark Loeser wrote:
> Well, instead of putting the debate into an even larger crowd, this
> enables the QA team to act in the way it sees best first.  If people
> believe we were wrong, then we give them the option to talk to the
> council about one of our changes.  Also, we aren't unwilling to hear
> alternatives and we hope to work with the maintainer on these problems.

As Stuart mentioned, this is not a good idea. If the maintainer
disagrees with QA-made changes, the changes should be reverted until a
higher-level decision is made. This mirrors FreeBSD policy [1], which
seems to be working quite well for them. A particularly relevant part is
this:

"Any disputed change must be backed out pending resolution of the
dispute if requested by a maintainer. Security related changes may
override a maintainer's wishes at the Security Officer's discretion."

Thanks,
Donnie

1.
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/rules.html


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Donnie Berkholz <spyderous@gentoo.org> said:
> Mark Loeser wrote:
> > Well, instead of putting the debate into an even larger crowd, this
> > enables the QA team to act in the way it sees best first.  If people
> > believe we were wrong, then we give them the option to talk to the
> > council about one of our changes.  Also, we aren't unwilling to hear
> > alternatives and we hope to work with the maintainer on these problems.
> 
> As Stuart mentioned, this is not a good idea. If the maintainer
> disagrees with QA-made changes, the changes should be reverted until a
> higher-level decision is made. This mirrors FreeBSD policy [1], which
> seems to be working quite well for them. A particularly relevant part is
> this:
> 
> "Any disputed change must be backed out pending resolution of the
> dispute if requested by a maintainer. Security related changes may
> override a maintainer's wishes at the Security Officer's discretion."

Which is basically what we are saying.  Stuart seems to be saying to
leave things "broken" and wait until a higher level decision is made.
We want to fix it/back it out/do whatever, and then come to some
resolution later if we couldn't at first.

-- 
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] [RFC] QA Team's role

[Donnie Berkholz]

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

Mark Loeser wrote:
> Donnie Berkholz <spyderous@gentoo.org> said:
>> Mark Loeser wrote:
>>> Well, instead of putting the debate into an even larger crowd, this
>>> enables the QA team to act in the way it sees best first.  If people
>>> believe we were wrong, then we give them the option to talk to the
>>> council about one of our changes.  Also, we aren't unwilling to hear
>>> alternatives and we hope to work with the maintainer on these problems.
>> As Stuart mentioned, this is not a good idea. If the maintainer
>> disagrees with QA-made changes, the changes should be reverted until a
>> higher-level decision is made. This mirrors FreeBSD policy [1], which
>> seems to be working quite well for them. A particularly relevant part is
>> this:
>>
>> "Any disputed change must be backed out pending resolution of the
>> dispute if requested by a maintainer. Security related changes may
>> override a maintainer's wishes at the Security Officer's discretion."
> 
> Which is basically what we are saying.  Stuart seems to be saying to
> leave things "broken" and wait until a higher level decision is made.
> We want to fix it/back it out/do whatever, and then come to some
> resolution later if we couldn't at first.

No, it's the exact opposite of what you're saying. You want to commit
first and let the maintainer bring it to the council. I'm saying the
maintainer has the right to have any non-security commit to his/her
package reverted pending a decision.

The maintainer should be the absolute authority over his/her packages,
and only the council should be able to overrule maintainer decisions in
the case of disagreement between the maintainer and anybody else.

Thanks,
Donnie


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Donnie Berkholz <spyderous@gentoo.org> said:
> No, it's the exact opposite of what you're saying. You want to commit
> first and let the maintainer bring it to the council. I'm saying the
> maintainer has the right to have any non-security commit to his/her
> package reverted pending a decision.

Yea, I realize now I read it wrong :)

> The maintainer should be the absolute authority over his/her packages,
> and only the council should be able to overrule maintainer decisions in
> the case of disagreement between the maintainer and anybody else.

I think it really depends on the situation, but in general I disagree
that something should be left in a state that the QA team finds
questionable/broken.  It should be a very rare occurence that this comes
up, since we don't really want to override what the maintainer says, but
I think the QA team should have this right in extreme circumstances.

-- 
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] [RFC] QA Team's role

[Donnie Berkholz]

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

Mark Loeser wrote:
> Donnie Berkholz <spyderous@gentoo.org> said:
>> The maintainer should be the absolute authority over his/her packages,
>> and only the council should be able to overrule maintainer decisions in
>> the case of disagreement between the maintainer and anybody else.
> 
> I think it really depends on the situation, but in general I disagree
> that something should be left in a state that the QA team finds
> questionable/broken.  It should be a very rare occurence that this comes
> up, since we don't really want to override what the maintainer says, but
> I think the QA team should have this right in extreme circumstances.

So if QA thinks one way is right, and the package maintainer thinks
another way is right, you say QA always trumps?

I'm looking at this as "innocent until proven guilty" versus "guilty
until proven innocent." When parties are in disagreement, the _current_
situation should stand until the council (or the two groups in question)
resolves it. That assumes lack of extenuating circumstances such as
security vulnerabilities or major tree breakage.

Thanks,
Donnie


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ned Ludd]

On Sun, 2006-02-26 at 19:34 -0800, Donnie Berkholz wrote:
> Mark Loeser wrote:
> > Donnie Berkholz <spyderous@gentoo.org> said:
> >> The maintainer should be the absolute authority over his/her packages,
> >> and only the council should be able to overrule maintainer decisions in
> >> the case of disagreement between the maintainer and anybody else.
> > 
> > I think it really depends on the situation, but in general I disagree
> > that something should be left in a state that the QA team finds
> > questionable/broken.  It should be a very rare occurence that this comes
> > up, since we don't really want to override what the maintainer says, but
> > I think the QA team should have this right in extreme circumstances.
> 
> So if QA thinks one way is right, and the package maintainer thinks
> another way is right, you say QA always trumps?
> 
> I'm looking at this as "innocent until proven guilty" versus "guilty
> until proven innocent." When parties are in disagreement, the _current_
> situation should stand until the council (or the two groups in question)
> resolves it. That assumes lack of extenuating circumstances such as
> security vulnerabilities or major tree breakage.

The devs asked for a council. A council was elected. The council decided
that QA trumps devs. If anybody has a problem with that they are free to
object at the next council meeting.
-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Donnie Berkholz]

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

Ned Ludd wrote:
> On Sun, 2006-02-26 at 19:34 -0800, Donnie Berkholz wrote:
>> I'm looking at this as "innocent until proven guilty" versus "guilty
>> until proven innocent." When parties are in disagreement, the _current_
>> situation should stand until the council (or the two groups in question)
>> resolves it. That assumes lack of extenuating circumstances such as
>> security vulnerabilities or major tree breakage.
> 
> The devs asked for a council. A council was elected. The council decided
> that QA trumps devs. If anybody has a problem with that they are free to
> object at the next council meeting.

The council decided that QA trumps devs for documented policy. It didn't
decide, at least from what I saw, that QA could just do whatever they
feel like without any sort of change to the policy.

Thanks,
Donnie


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz
<spyderous@gentoo.org> wrote:
| The maintainer should be the absolute authority over his/her packages,
| and only the council should be able to overrule maintainer decisions
| in the case of disagreement between the maintainer and anybody else.

So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global scope
and refuses to move it, QA will have to get council approval to fix it?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Lance Albertson]

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

Ciaran McCreesh wrote:
> On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | The maintainer should be the absolute authority over his/her packages,
> | and only the council should be able to overrule maintainer decisions
> | in the case of disagreement between the maintainer and anybody else.
> 
> So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global scope
> and refuses to move it, QA will have to get council approval to fix it?

Use some common sense when showing an example please. We all know that
something that stupid needs to be delt with quickly.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| > So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global
| > scope and refuses to move it, QA will have to get council approval
| > to fix it?
| 
| Use some common sense when showing an example please. We all know that
| something that stupid needs to be delt with quickly.

If we all recognise that level of stupidity, please explain how the
heck this got into the tree:

http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap_cmds/bootstrap_cmds-44.ebuild?rev=1.1&content-type=text/plain

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Monday 27 February 2006 18:15, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson
>
> <ramereth@gentoo.org> wrote:
> | > So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global
> | > scope and refuses to move it, QA will have to get council approval
> | > to fix it?
> |
> | Use some common sense when showing an example please. We all know
> | that something that stupid needs to be delt with quickly.
>
> If we all recognise that level of stupidity, please explain how the
> heck this got into the tree:
>
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap
>_cmds/bootstrap_cmds-44.ebuild?rev=1.1&content-type=text/plain

Probably because although it isn't a good ebuild it still works and does 
not violate the sandbox. While it does things in the wrong way/place it 
does not do the wrong things.

I do not think that anyone would argue against QA (or other developers) 
fixing urgent big tree breakages. (and rm -rf / would certainly qualify). 
What I see as the argument is that QA should show a degree of flexibility 
in it's policies, and not just enforce because of the policy. This 
especially in those cases where there is no way to provide the ebuild 
without breaking policy, or doing so would mean a greater inconvenience 
to the users.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| > http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap
| >_cmds/bootstrap_cmds-44.ebuild?rev=1.1&content-type=text/plain
| 
| Probably because although it isn't a good ebuild it still works and
| does not violate the sandbox. While it does things in the wrong
| way/place it does not do the wrong things.

Huh? It violates the sandbox even if you do 'emerge sync' and never
touch the ebuild. Look at the frickin' mkdir!

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 15:48, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> Huh? It violates the sandbox even if you do 'emerge sync' and never
> touch the ebuild. Look at the frickin' mkdir!

Hmm. Didn't realise that the sandbox is more restrictive in those cases 
(and that the ebuild is sourced then). The mkdir in toplevel is of course 
wrong.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Mon, 27 Feb 2006 10:47:58 -0600
Lance Albertson <ramereth@gentoo.org> wrote:

> We all know that
> something that stupid needs to be delt with quickly.

So you're agreeing that someone needs to be able to act should a
package maintainer screw up sufficiently badly, and the obvious
candidate for that role is the QA team. The ability to overrule package
maintainers doesn't, and shouldn't, mean that they'll go around doing so
willy-nilly, but it should be there as a last resort should it be
necessary.

(Yes, I'm taking that sentence out of context, but the fact that it
comes up at all says something, to my mind.)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[John Mylchreest]

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

On Mon, Feb 27, 2006 at 05:30:27PM +0000, Stephen Bennett <spb@gentoo.org> wrote:
> (Yes, I'm taking that sentence out of context, but the fact that it
> comes up at all says something, to my mind.)

Your mind is a dark and twisted place!

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Monday 27 February 2006 11:47, Lance Albertson wrote:
> Ciaran McCreesh wrote:
> > On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz
> >
> > <spyderous@gentoo.org> wrote:
> > | The maintainer should be the absolute authority over his/her packages,
> > | and only the council should be able to overrule maintainer decisions
> > | in the case of disagreement between the maintainer and anybody else.
> >
> > So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global scope
> > and refuses to move it, QA will have to get council approval to fix it?
>
> Use some common sense when showing an example please. We all know that
> something that stupid needs to be delt with quickly.

we've had at least one ebuild do stuff in /tmp in global scope ... of course 
that was a mistake the dev felt really bad about and it was fixed once 
noticed, so not sure this is an appropriate example ;)
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Donnie Berkholz]

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

Ciaran McCreesh wrote:
> On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz
> <spyderous@gentoo.org> wrote:
> | The maintainer should be the absolute authority over his/her packages,
> | and only the council should be able to overrule maintainer decisions
> | in the case of disagreement between the maintainer and anybody else.
> 
> So if the maintainer sticks SANDBOX_DISABLE="1" rm -fr / in global scope
> and refuses to move it, QA will have to get council approval to fix it?

I already addressed that in the next email in the thread.

"That assumes lack of extenuating circumstances such as
security vulnerabilities or major tree breakage."

Thanks,
Donnie


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ned Ludd]

On Sun, 2006-02-26 at 16:29 -0800, Donnie Berkholz wrote:
> Mark Loeser wrote:
> > Well, instead of putting the debate into an even larger crowd, this
> > enables the QA team to act in the way it sees best first.  If people
> > believe we were wrong, then we give them the option to talk to the
> > council about one of our changes.  Also, we aren't unwilling to hear
> > alternatives and we hope to work with the maintainer on these problems.
> 
> As Stuart mentioned, this is not a good idea. If the maintainer
> disagrees with QA-made changes, the changes should be reverted until a
> higher-level decision is made. This mirrors FreeBSD policy [1], which
> seems to be working quite well for them. A particularly relevant part is
> this:
> 
> "Any disputed change must be backed out pending resolution of the
> dispute if requested by a maintainer. Security related changes may
> override a maintainer's wishes at the Security Officer's discretion."

I think I agree with the part that security@ having near final say.

If I had to put a pecking order together how I think it would
look/should be would result in something like the following.

gentoo-(infra|council)
  - gentoo-security
    - gentoo-(devrel|base)
       -gentoo-qa
          - gentoo-(hardened|server)
            - gentoo-(desktop|misc|maintainers|etc..)

-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 00:09:28 -0500 Ned Ludd <solar@gentoo.org> wrote:
| I think I agree with the part that security@ having near final say.

Security have (admittedly not very often) screwed up in the past.
Fixing a security issue at the expense of utterly h0rking an arch, for
example, is not an acceptable solution...

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[John Mylchreest]

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

On Sun, Feb 26, 2006 at 07:09:29PM -0500, Mark Loeser <halcy0n@gentoo.org> wrote:
> > > The problem with that is, it usually ends up with too many pointless
> > > comments from people saying how things could be fixed in the distant
> > > future, or whining that it isn't explicitly forbidden by policy on
> > > situations where the screwup was too weird to be documented previously.
> > 
> > This is very much a case-by-case thing. I still feel the debate should
> > be better answered outside of conflicting qa members.
> 
> Well, instead of putting the debate into an even larger crowd, this
> enables the QA team to act in the way it sees best first.  If people
> believe we were wrong, then we give them the option to talk to the
> council about one of our changes.  Also, we aren't unwilling to hear
> alternatives and we hope to work with the maintainer on these problems.

I've yet to read the rest of this subthread this morning, but while its
fresh in my mind I would also like to see less of a requirement from the
council. They are there purely for technical direction and not for a
teams beck and call. Regardless, I can see your point - although I would
still prefer to see a little more public discussion when the QA team are
unable to satisfactorily come to an answer between themselves and the
maintainer in question.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

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

Ciaran McCreesh wrote:
> 
> | > * In the case of disagreement on policy among QA members, the
> | > majority of established QA members must agree with the action.
> | 
> | Perhaps pushing it to an open forum on -dev/-core for consensus works
> | better here?
> 
> The problem with that is, it usually ends up with too many pointless
> comments from people saying how things could be fixed in the distant
> future, or whining that it isn't explicitly forbidden by policy on
> situations where the screwup was too weird to be documented previously.
> 

The rather blunt point here is to limit the power of the QA team itself.
 The QA team decides what new policy to enforce, and when the QA team
can't agree "the majority of established QA members" must agree to
action.  Which is in itself rather vague.

Perhaps "The majority of active QA members, where an active member is
designated as 'a QA member who responds to the corresponding mail to the
qa'".  This would be similar to how the recent QA lead was chosen, mail
was sent, yay's and nay's were collected from those who cared, and then
the decision was made.

This is meant to prevent the case where the QA team ( or a subset; "the
established QA members" ) decides to make unilateral changes to the tree
( or large subset thereof ) without even necessarily talking to the
affected developers.

While you may not think that soliciting comments is useful ( and in some
limited cases I would agree with you ) giving people the opportunity to
comment also means you just covered your ass, in terms of people going
"where the hell did that come from?"

-Alec Warner

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

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

On Sun, 2006-02-26 at 18:41 -0500, Alec Warner wrote:
> While you may not think that soliciting comments is useful ( and in some
> limited cases I would agree with you ) giving people the opportunity to
> comment also means you just covered your ass, in terms of people going
> "where the hell did that come from?"

It also means that the QA team has learned from the lessons of the past
(ie devrel).  Given Ciaran's personal and vocal history on those
lessons, one would naturally assume that he'd jump at this chance to put
his own previously stated views on how policy should be derived into
practice :)

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Alec Warner <antarus@gentoo.org> said:
> This is meant to prevent the case where the QA team ( or a subset; "the
> established QA members" ) decides to make unilateral changes to the tree
> ( or large subset thereof ) without even necessarily talking to the
> affected developers.
> 
> While you may not think that soliciting comments is useful ( and in some
> limited cases I would agree with you ) giving people the opportunity to
> comment also means you just covered your ass, in terms of people going
> "where the hell did that come from?"

We don't plan on going around and making changes without discussing
issues with the maintainers.  We put this in so that if the maintainer
is unwilling to work with us for some reason, that we are able to come
up with what we believe to be the best fix.  As I said earlier in the
document, we plan to work as much with maintainers as possible, but
sometimes that may prove to be impossible.

-- 
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] [RFC] QA Team's role

[John Mylchreest]

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

On Sun, Feb 26, 2006 at 07:12:52PM -0500, Mark Loeser <halcy0n@gentoo.org> wrote:
> Alec Warner <antarus@gentoo.org> said:
> > This is meant to prevent the case where the QA team ( or a subset; "the
> > established QA members" ) decides to make unilateral changes to the tree
> > ( or large subset thereof ) without even necessarily talking to the
> > affected developers.
> > 
> > While you may not think that soliciting comments is useful ( and in some
> > limited cases I would agree with you ) giving people the opportunity to
> > comment also means you just covered your ass, in terms of people going
> > "where the hell did that come from?"
> 
> We don't plan on going around and making changes without discussing
> issues with the maintainers.  We put this in so that if the maintainer
> is unwilling to work with us for some reason, that we are able to come
> up with what we believe to be the best fix.  As I said earlier in the
> document, we plan to work as much with maintainers as possible, but
> sometimes that may prove to be impossible.

In this specific instance, impossible is effectively a point of view.
For me the question comes down to this.. If QA trump maintainer, then
who picks the QA staff? If anyone can become QA staff, then this is
questionable in itself. is QA becoming another council with a sole
purpose? If so I'd like to see an election again. At the end of the day
the pack have to have faith in the team doing the work, and
disagreements are obviously contrary to that.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 09:09:01 +0000 John Mylchreest <johnm@gentoo.org>
wrote:
| In this specific instance, impossible is effectively a point of view.
| For me the question comes down to this.. If QA trump maintainer, then
| who picks the QA staff? If anyone can become QA staff, then this is
| questionable in itself. is QA becoming another council with a sole
| purpose? If so I'd like to see an election again. At the end of the
| day the pack have to have faith in the team doing the work, and
| disagreements are obviously contrary to that.

QA consists of whoever is on the QA project page. To be added, you must
convince the existing QA team that you know what you're doing.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[John Mylchreest]

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

On Mon, Feb 27, 2006 at 04:37:52PM +0000, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> On Mon, 27 Feb 2006 09:09:01 +0000 John Mylchreest <johnm@gentoo.org>
> wrote:
> | In this specific instance, impossible is effectively a point of view.
> | For me the question comes down to this.. If QA trump maintainer, then
> | who picks the QA staff? If anyone can become QA staff, then this is
> | questionable in itself. is QA becoming another council with a sole
> | purpose? If so I'd like to see an election again. At the end of the
> | day the pack have to have faith in the team doing the work, and
> | disagreements are obviously contrary to that.
> 
> QA consists of whoever is on the QA project page. To be added, you must
> convince the existing QA team that you know what you're doing.

My point was the more along the lines that the existing QA team need 
to convince the rest of the development community that they know what 
they're doing first. Whats stopping the existing QA team disregarding
all new applicants because they enjoy having authority? Especially when
its mis-placed authority.

-- 
Role:            Gentoo Linux Kernel Lead
Gentoo Linux:    http://www.gentoo.org
Public Key:      gpg --recv-keys 9C745515
Key fingerprint: A0AF F3C8 D699 A05A EC5C  24F7 95AA 241D 9C74 5515


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 17:09:42 +0000 John Mylchreest <johnm@gentoo.org>
wrote:
| My point was the more along the lines that the existing QA team need 
| to convince the rest of the development community that they know what 
| they're doing first. Whats stopping the existing QA team disregarding
| all new applicants because they enjoy having authority? Especially
| when its mis-placed authority.

Oh, that one's easy. We're all lazy and would never turn down someone
decent who is going to reduce our workload :P

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

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

Hi Mark,

Thanks for posting this.  I've a few suggestions to make (see below).  I
support all the other points in your proposal.

On Sun, 2006-02-26 at 17:22 -0500, Mark Loeser wrote:
> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.

I'd like to see this say

  * In case of emergency, or after a failed appeal by the package
    maintainer to the council, the QA team may take action themselves 
    to fix the problem, if the package maintainer(s) are unavailable
    or refuse to co-operate.

That still gives the QA team the powers it needs for an enforcement
role, which is all that it needs.

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

I'd like to see an alternative wording:

  * In the event that a developer still insists that a package does not
    break QA standards, or that the QA standards are somehow defective, 
    an appeal can be made at the next council meeting.

If it is an emergency, then the QA team is still free to intervene
before the council meeting.  But, where it isn't an emergency, there is
no need for immediate action, and so there should be no action until the
appeal has been heard.  

The original wording is, imho, unfairly unbalanced.  What will happen
under the original wording is that the QA team is free to force their
demands up front, and most developers will go with the flow rather than
take the trouble to take the issue to the council.  

The QA team has no monopoly on what is right or wrong in Gentoo, and
neither do package maintainers.  If there is a disagreement that leads
to an appeal, the onus should be on the QA team to have to present their
case to the council, as they are the ones pushing for change.

> * Just because a particular QA violation has yet to cause an issue does
>   not change the fact that it is still a QA violation.

I'd support the above if the following statement was also included:

  * QA standards, and the actions required to resolve them, must be
    pragmatic and proportional to the impact on actual end-users of
    Gentoo.

Gentoo would be best served by a QA team that spent its time tackling
issues that are urgent and important to end-users (quadrant 1 & 2
activities).  A QA team that gets bogged down in the thick of thin
things is a symptom of a team that has become self-serving.

> * The QA team will maintain a list of current "QA Standards".  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.

These QA standards are policy changes that affect the whole tree.  The
QA team does *not* own QA policy - we all do, as contributors to Gentoo.
I'm asking the council to agree an adequate process for the approval of
QA standards by a wider group than just the QA team.  Maybe changes
could be batched up into a GLEP, say once a quarter, with the option of
fast-tracking GLEPs in between for emergency QA policy changes?  This
would allow the QA team to perform effectively, and have the added
benefit of ensuring that the wider developer community knew what was
coming in advance, and could "buy in" to the changes.

There's a secondary issue here for me.  None of our tools are perfect;
we all have to work pragmatically within the capabilities of what we
have.  Some of the real QA issues in the tree arise from the limitations
of our tools.  I'd like to see the following incorporated into the QA
team's mandate.

  * If the QA team wishes to push standards about specific aspects of
    our tools, then those standards must be endorsed by the leads of
    those tools.

Why?  Because the QA team has no monopoly on what is right and wrong
with the tree.  If any proposed QA standard cannot pass a simple litmus
test of the endorsement of the leads of the tools, how can it be fit for
enforcement against the wider development community?  What is a package
maintainer to do?  He/she can't go back to the tools team in question
and ask for a fix; all they will get is that the tools team in question
doesn't agree with the QA team, and doesn't support that particular
standard.  Better to have QA standards that are strongly supported than
to have QA standards supported by just the one team.

I'd like to see the QA team's primary role stated as "educational"
first, then watchdog, then intervener in that order (emergencies
not-withstanding).

With that in mind, I suggest that the QA standards must include
educational information about the problem(s) that the standard
addresses, before they can be approved.  This is in no way to challenge
the legitimacy of the agreed standards.  It's to help all developers do
better QA on their own work (everyone does a better job if they
understand the reasons why).  It also serves the dual purpose of helping
the next generation of QA testers when the current team members have
moved on.  This could be Ciaran's opportunity to see TheDoc become an
"offical" document.  There are few things worse than standards
autocratically and inflexibily applied long after the original
supporters have left, and no-one else can remember why they were
necessary in the first place.

There *may* be arguments about how much effort it takes to produce this
educational material, and I'm sympathetic to that.  But for me, what it
boils down to is this: QA is something that we all need to do.  I'd
rather have a QA team that's busy teaching the rest of us do things
better than spending all its time cleaning up after a developer
community that becomes more dazed and confused and left behind as time
goes on.  And it also scales much better :)

This document does nothing to address the QA of anything other than the
package tree.  If the scope of the team is limited to just the package
tree, then I'd like to see the team named appropriately - tree-qa
perhaps - because they would be a general, all-ranging QA team.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Stuart Herbert <stuart@gentoo.org> said:
> On Sun, 2006-02-26 at 17:22 -0500, Mark Loeser wrote:
> > * In case of emergency, or if package maintainers refuse to cooperate,
> >   the QA team may take action themselves to fix the problem.
> 
> I'd like to see this say
> 
>   * In case of emergency, or after a failed appeal by the package
>     maintainer to the council, the QA team may take action themselves 
>     to fix the problem, if the package maintainer(s) are unavailable
>     or refuse to co-operate.
> 
> That still gives the QA team the powers it needs for an enforcement
> role, which is all that it needs.

Your change seems to imply that the QA team must wait for the council's
okay to go forth and fix the package, rather the QA team able to act on
its own.  If that is the case, I don't see how we would ever be able to
get things done when someone disagrees with us.

> > * 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.
> 
> I'd like to see an alternative wording:
> 
>   * In the event that a developer still insists that a package does not
>     break QA standards, or that the QA standards are somehow defective, 
>     an appeal can be made at the next council meeting.
> 
> If it is an emergency, then the QA team is still free to intervene
> before the council meeting.  But, where it isn't an emergency, there is
> no need for immediate action, and so there should be no action until the
> appeal has been heard.  

Again, then we are going to get into the argument of the definition of
an emergency and never be able to get anything done.  We really hope
problems never come down to this, which is why we left it worded this
way.

> The QA team has no monopoly on what is right or wrong in Gentoo, and
> neither do package maintainers.  If there is a disagreement that leads
> to an appeal, the onus should be on the QA team to have to present their
> case to the council, as they are the ones pushing for change.

Again, this is taking away any power that the QA team might have, and
gets us stuck in the current situation where we can't do anything when
someone disagrees with us.  We are hoping that most people are not going
to see us as idiots running around trying to change everything just because
we don't like it.  It is expected that people will trust us to some degree,
and we are giving a way for people to challenge our decisions if they
believe we are wrong.

> 
> > * Just because a particular QA violation has yet to cause an issue does
> >   not change the fact that it is still a QA violation.
> 
> I'd support the above if the following statement was also included:
> 
>   * QA standards, and the actions required to resolve them, must be
>     pragmatic and proportional to the impact on actual end-users of
>     Gentoo.
> 
> Gentoo would be best served by a QA team that spent its time tackling
> issues that are urgent and important to end-users (quadrant 1 & 2
> activities).  A QA team that gets bogged down in the thick of thin
> things is a symptom of a team that has become self-serving.

This is not quantifiable at all and will just get us into arguments with
people that disagree with us that there is a problem present.

> 
> > * The QA team will maintain a list of current "QA Standards".  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.
> 
> These QA standards are policy changes that affect the whole tree.  The
> QA team does *not* own QA policy - we all do, as contributors to Gentoo.
> I'm asking the council to agree an adequate process for the approval of
> QA standards by a wider group than just the QA team.  Maybe changes
> could be batched up into a GLEP, say once a quarter, with the option of
> fast-tracking GLEPs in between for emergency QA policy changes?  This
> would allow the QA team to perform effectively, and have the added
> benefit of ensuring that the wider developer community knew what was
> coming in advance, and could "buy in" to the changes.

Again, this bogs us down in useless process if someone wants to argue a
change that clearly breaks things, but isn't documented.  It is
impossible to document every single thing that is a problem, and we are
asking for some freedom to be able to work on issues that fall under QA.

> There's a secondary issue here for me.  None of our tools are perfect;
> we all have to work pragmatically within the capabilities of what we
> have.  Some of the real QA issues in the tree arise from the limitations
> of our tools.  I'd like to see the following incorporated into the QA
> team's mandate.
> 
>   * If the QA team wishes to push standards about specific aspects of
>     our tools, then those standards must be endorsed by the leads of
>     those tools.

So the Portage team will have to agree with us on every single problem
that is a QA issue?  This seems like something we can leave alone until
it doesn't work, at which point we bring it before the council to figure
out how we can best handle this situation.  Saying that another team
must approve all QA checks just seems silly.

> Why?  Because the QA team has no monopoly on what is right and wrong
> with the tree.  If any proposed QA standard cannot pass a simple litmus
> test of the endorsement of the leads of the tools, how can it be fit for
> enforcement against the wider development community?  What is a package
> maintainer to do?  He/she can't go back to the tools team in question
> and ask for a fix; all they will get is that the tools team in question
> doesn't agree with the QA team, and doesn't support that particular
> standard.  Better to have QA standards that are strongly supported than
> to have QA standards supported by just the one team.

All of this seems to assume that the QA team is going to abuse its
power.  So far we have had very few problems when we ask people to
fix issues that we have found for their packages.  Is this going to
always be true?  No, and someone needs to be able to get problems fixed
instead of just leaving things the way they are, and we want to fill
that role.

> I'd like to see the QA team's primary role stated as "educational"
> first, then watchdog, then intervener in that order (emergencies
> not-withstanding).

Which is what we plan on doing, and have been doing so far.

> With that in mind, I suggest that the QA standards must include
> educational information about the problem(s) that the standard
> addresses, before they can be approved.  This is in no way to challenge
> the legitimacy of the agreed standards.  It's to help all developers do
> better QA on their own work (everyone does a better job if they
> understand the reasons why).  It also serves the dual purpose of helping
> the next generation of QA testers when the current team members have
> moved on.  This could be Ciaran's opportunity to see TheDoc become an
> "offical" document.

We are working on a document, and hope to document all of the problems
and why they are problems.  We don't plan on saying something is just
wrong and not give an explanation.


-- 
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] [RFC] QA Team's role

[Daniel Goller]

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

On Sunday 26 February 2006 18:34, Mark Loeser wrote:
> Stuart Herbert <stuart@gentoo.org> said:
> > On Sun, 2006-02-26 at 17:22 -0500, Mark Loeser wrote:
> > > * In case of emergency, or if package maintainers refuse to cooperate,
> > >   the QA team may take action themselves to fix the problem.
> >
> > I'd like to see this say
> >
> >   * In case of emergency, or after a failed appeal by the package
> >     maintainer to the council, the QA team may take action themselves
> >     to fix the problem, if the package maintainer(s) are unavailable
> >     or refuse to co-operate.
> >
> > That still gives the QA team the powers it needs for an enforcement
> > role, which is all that it needs.
>
> Your change seems to imply that the QA team must wait for the council's
> okay to go forth and fix the package, rather the QA team able to act on
> its own.  If that is the case, I don't see how we would ever be able to
> get things done when someone disagrees with us.

give the QA team the power to fix things, likely they act on something being 
broken rather than impose style changes, i do not think we want to start 
discussions and appeals while broken packages remain broken

>
> > > * 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.
> >
> > I'd like to see an alternative wording:
> >
> >   * In the event that a developer still insists that a package does not
> >     break QA standards, or that the QA standards are somehow defective,
> >     an appeal can be made at the next council meeting.
> >
> > If it is an emergency, then the QA team is still free to intervene
> > before the council meeting.  But, where it isn't an emergency, there is
> > no need for immediate action, and so there should be no action until the
> > appeal has been heard.
>
> Again, then we are going to get into the argument of the definition of
> an emergency and never be able to get anything done.  We really hope
> problems never come down to this, which is why we left it worded this
> way.

again, give the QA team the benefit of the doubt, if they are willing to fix 
it before the maintainer, gentoo only has to gain, while hopefully everyone 
learns what not to repeat in the future
>
> > The QA team has no monopoly on what is right or wrong in Gentoo, and
> > neither do package maintainers.  If there is a disagreement that leads
> > to an appeal, the onus should be on the QA team to have to present their
> > case to the council, as they are the ones pushing for change.
>
> Again, this is taking away any power that the QA team might have, and
> gets us stuck in the current situation where we can't do anything when
> someone disagrees with us.  We are hoping that most people are not going
> to see us as idiots running around trying to change everything just because
> we don't like it.  It is expected that people will trust us to some degree,
> and we are giving a way for people to challenge our decisions if they
> believe we are wrong.

again, the QA team should have final say, and their decision should only be 
appealable after the fact, not stallable with appeals before the fact
leave the tree as is (unbroken/unfixed) until the council could review any 
appeal

>
> > > * Just because a particular QA violation has yet to cause an issue does
> > >   not change the fact that it is still a QA violation.
> >
> > I'd support the above if the following statement was also included:
> >
> >   * QA standards, and the actions required to resolve them, must be
> >     pragmatic and proportional to the impact on actual end-users of
> >     Gentoo.
> >
> > Gentoo would be best served by a QA team that spent its time tackling
> > issues that are urgent and important to end-users (quadrant 1 & 2
> > activities).  A QA team that gets bogged down in the thick of thin
> > things is a symptom of a team that has become self-serving.
>
> This is not quantifiable at all and will just get us into arguments with
> people that disagree with us that there is a problem present.
>
> > > * The QA team will maintain a list of current "QA Standards".  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.
> >
> > These QA standards are policy changes that affect the whole tree.  The
> > QA team does *not* own QA policy - we all do, as contributors to Gentoo.
> > I'm asking the council to agree an adequate process for the approval of
> > QA standards by a wider group than just the QA team.  Maybe changes
> > could be batched up into a GLEP, say once a quarter, with the option of
> > fast-tracking GLEPs in between for emergency QA policy changes?  This
> > would allow the QA team to perform effectively, and have the added
> > benefit of ensuring that the wider developer community knew what was
> > coming in advance, and could "buy in" to the changes.
>
> Again, this bogs us down in useless process if someone wants to argue a
> change that clearly breaks things, but isn't documented.  It is
> impossible to document every single thing that is a problem, and we are
> asking for some freedom to be able to work on issues that fall under QA.

the list of documented "Don't"s should be an open list, not an ultimate and 
final list, just because i mess up in a way noone ever thought of documenting 
before, should not give me the chance to be ignorant to the fact that i 
indeed broke a package/the tree

>
> > There's a secondary issue here for me.  None of our tools are perfect;
> > we all have to work pragmatically within the capabilities of what we
> > have.  Some of the real QA issues in the tree arise from the limitations
> > of our tools.  I'd like to see the following incorporated into the QA
> > team's mandate.
> >
> >   * If the QA team wishes to push standards about specific aspects of
> >     our tools, then those standards must be endorsed by the leads of
> >     those tools.
>
> So the Portage team will have to agree with us on every single problem
> that is a QA issue?  This seems like something we can leave alone until
> it doesn't work, at which point we bring it before the council to figure
> out how we can best handle this situation.  Saying that another team
> must approve all QA checks just seems silly.
>
> > Why?  Because the QA team has no monopoly on what is right and wrong
> > with the tree.  If any proposed QA standard cannot pass a simple litmus
> > test of the endorsement of the leads of the tools, how can it be fit for
> > enforcement against the wider development community?  What is a package
> > maintainer to do?  He/she can't go back to the tools team in question
> > and ask for a fix; all they will get is that the tools team in question
> > doesn't agree with the QA team, and doesn't support that particular
> > standard.  Better to have QA standards that are strongly supported than
> > to have QA standards supported by just the one team.
>
> All of this seems to assume that the QA team is going to abuse its
> power.  So far we have had very few problems when we ask people to
> fix issues that we have found for their packages.  Is this going to
> always be true?  No, and someone needs to be able to get problems fixed
> instead of just leaving things the way they are, and we want to fill
> that role.

agreed, most objections seem to aim at preventing abuse of power rather than 
commenting on how a QA team can work reliably

>
> > I'd like to see the QA team's primary role stated as "educational"
> > first, then watchdog, then intervener in that order (emergencies
> > not-withstanding).
>
> Which is what we plan on doing, and have been doing so far.

just make sure the QA team can't be paralyzed with stubborn devs filing appeal 
after appeal, give them the power to act too, not just 
educate/watch/intervene in security issues

>
> > With that in mind, I suggest that the QA standards must include
> > educational information about the problem(s) that the standard
> > addresses, before they can be approved.  This is in no way to challenge
> > the legitimacy of the agreed standards.  It's to help all developers do
> > better QA on their own work (everyone does a better job if they
> > understand the reasons why).  It also serves the dual purpose of helping
> > the next generation of QA testers when the current team members have
> > moved on.  This could be Ciaran's opportunity to see TheDoc become an
> > "offical" document.
>
> We are working on a document, and hope to document all of the problems
> and why they are problems.  We don't plan on saying something is just
> wrong and not give an explanation.

all in all gentoo can only gain from an active, able to act QA team

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

Hi Mark,

On 2/27/06, Mark Loeser <halcy0n@gentoo.org> wrote:
> Your change seems to imply that the QA team must wait for the council's
> okay to go forth and fix the package, rather the QA team able to act on
> its own.  If that is the case, I don't see how we would ever be able to
> get things done when someone disagrees with us.

In the event of a disagreement, that's exactly what I'm asking for. 
Hopefully, disagreements will be rare.  But, when they do arise, and
it is not an emergency, I see no reason why the QA team needs the
ability to force its point of view onto others.

> Again, then we are going to get into the argument of the definition of
> an emergency and never be able to get anything done.  We really hope
> problems never come down to this, which is why we left it worded this
> way.

Me too.  But it will, sooner or later, and when something isn't an
emergency, there's no reason why a change cannot wait until the
dispute has been resolved.

I have no desire to stop the QA team being able to act in an
emergency.  It's in all our interests for action to be taken in an
emergency.

> > The QA team has no monopoly on what is right or wrong in Gentoo, and
> > neither do package maintainers.  If there is a disagreement that leads
> > to an appeal, the onus should be on the QA team to have to present their
> > case to the council, as they are the ones pushing for change.
>
> Again, this is taking away any power that the QA team might have

I find that an interesting statement.  The only power my proposals
remove is to stop you bullying people by insisting you are always
right before a peer review has happened.  If there is a genuine QA
problem, and you can't convince the developer in question of that,
there's still a fair process that allows you to enforce when concensus
has failed.

Without these safeguards, my feeling is that the QA team is free to
enforce without concensus at all times.  I don't believe that is in
the best interests of Gentoo, and is a significant shift in the way we
govern ourselves.

I don't see any compelling reason for the QA team to be judge, jury
and executioner, with the council acting as a post-execution appeals
panel.  Wasn't devrel broken up into separate investigation and
enforcement teams over these very same concerns, raised by a member of
the QA team?

> This is not quantifiable at all and will just get us into arguments with
> people that disagree with us that there is a problem present.

If you mean that it creates grey areas where the output of automated
tools cannot always be right, I agree.  If you're saying that it's
beyond your capacity as human beings to weigh up the merits of an
argument on more than just narrowly-defined technical facts, then are
you best placed to be making the decision in the first place?

If a policy is to be supportable and implementable, it has to be
reasonable, and it has to be managed by reasonable people.  I feel
that what you're asking for, on this point, is more dogmatic than
reasonable.

Case in point.  I've presented to you that, after two and a half
years, the situation that has sparked this debate off hasn't affected
users.  I've explained that it is a third scenario, and that it is
different to the two (legitimate) scenarios that you've been busy
getting fixed.  From where I'm sat, it would seem reasonable to accept
that, although this is a problem when looked at purely from a
technical point of view, this scenario isn't causing problems at this
time, and we could all move on to dealing with more important matters.
 If there was a real problem, there would be enough evidence after two
and a half years for you to show me, and that would convince me (and
any other reasonable person) that I was wrong, and that action was
worth taking.

You haven't presented that evidence, or if you have, I haven't seen it
since getting up this morning.

Instead, we have a proposed QA policy that says "we're always right,
and when we're not, we still get our way until you convince the
council to let you back out the changes we demand."  I think that's
unreasonable.  That's why I oppose this point.  To me, it smacks of
wanting to have your own way whether you're right or not.  I can't
support that.

> Again, this bogs us down in useless process if someone wants to argue a
> change that clearly breaks things, but isn't documented.  It is
> impossible to document every single thing that is a problem, and we are
> asking for some freedom to be able to work on issues that fall under QA.

As already mentioned, if it's not documented, how on earth do you
expect to raise the general quality of the QA done by each and every
developer?  How do you expect to be able to consistently enforce your
own QA standards?

If it's not documented, then you're left with making it up as you go
along.  That's in no-one's interest.

This comes back to my point about the QA team needing to be an
educational role first and foremost.

> So the Portage team will have to agree with us on every single problem
> that is a QA issue?  This seems like something we can leave alone until
> it doesn't work, at which point we bring it before the council to figure
> out how we can best handle this situation.  Saying that another team
> must approve all QA checks just seems silly.

I'm asserting that it isn't working.  Case in point.  Brian, as
co-lead of the Portage team, has said that we won't be adding
DEST_PREFIX to Portage.  If the Portage team won't agree with your
interpretation of what is or isn't a valid QA check, why should you
have the right to go ahead anyway and enforce that check on the
package maintainers?

It's not silly.  What do you have to fear about having your proposed
QA standards backed by key teams?  If your arguments have merit, they
will be supported.

What I think is silly is the QA team claiming for itself the power to
enforce standards just on their say so.

> All of this seems to assume that the QA team is going to abuse its
> power.  So far we have had very few problems when we ask people to
> fix issues that we have found for their packages.  Is this going to
> always be true?  No, and someone needs to be able to get problems fixed
> instead of just leaving things the way they are, and we want to fill
> that role.

I think you're already abusing that power, by calling for a package to
be removed when it's causing no trouble to anyone, and when the
workarounds create a worse user experience than what is already there.
 When the developer in question declines to remove the package, your
response is a proposed QA mandate that is unbalanced.

Genuine problems need to be fixed.  My proposals do not stop you from
doing that.  They also ensure that we have a balanced QA approach that
genuinely serves the needs of the project.

> > I'd like to see the QA team's primary role stated as "educational"
> > first, then watchdog, then intervener in that order (emergencies
> > not-withstanding).
>
> Which is what we plan on doing, and have been doing so far.

Walk the talk.  Create the educational material.

> We are working on a document, and hope to document all of the problems
> and why they are problems.  We don't plan on saying something is just
> wrong and not give an explanation.

:)

Best regards,
Stu
--

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 09:00:15 +0000 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| > Again, then we are going to get into the argument of the definition
| > of an emergency and never be able to get anything done.  We really
| > hope problems never come down to this, which is why we left it
| > worded this way.
| 
| Me too.  But it will, sooner or later, and when something isn't an
| emergency, there's no reason why a change cannot wait until the
| dispute has been resolved.

And, when such a case occurs, there's nothing *requiring* QA to commit
before the dispute is resolved. It's extremely likely that QA will work
hard to ensure that everyone is happy before something gets changed.
However, there are situations where waiting for a month would lead to
considerable damage, and in those situations QA must be free to act.

| Without these safeguards, my feeling is that the QA team is free to
| enforce without concensus at all times.  I don't believe that is in
| the best interests of Gentoo, and is a significant shift in the way we
| govern ourselves.

The only change is that someone will actually be doing the enforcing,
rather than allowing egregious QA violations to sit in the tree for
years because one or two developers refuse to accept that what they're
doing is wrong.

| I don't see any compelling reason for the QA team to be judge, jury
| and executioner, with the council acting as a post-execution appeals
| panel.

'Executioner' is far too harsh a term. QA is fixing packages. QA is not
permanently removing developers from the project, nor even suspending
commit access.

| Wasn't devrel broken up into separate investigation and
| enforcement teams over these very same concerns, raised by a member of
| the QA team?

Heh. This is a perfect example of argumentum ad hominem. It's also an
invalid argument, since there's a huge difference between fixing a
package and kicking off a developer.

| You haven't presented that evidence, or if you have, I haven't seen it
| since getting up this morning.

Dude. You had to write it up in your user guide. That's a pretty good
indication that something is extremely screwed up.

| Instead, we have a proposed QA policy that says "we're always right,
| and when we're not, we still get our way until you convince the
| council to let you back out the changes we demand."  I think that's
| unreasonable.  That's why I oppose this point.  To me, it smacks of
| wanting to have your own way whether you're right or not.  I can't
| support that.

No, it says that the QA team can, where necessary, act without having
to wait for a month for a council decision.

| As already mentioned, if it's not documented, how on earth do you
| expect to raise the general quality of the QA done by each and every
| developer?  How do you expect to be able to consistently enforce your
| own QA standards?
| 
| If it's not documented, then you're left with making it up as you go
| along.  That's in no-one's interest.

Are you saying that because it's not documented that one should not
call mkdir in global scope, the QA team cannot expect people to know
not to do so?


| This comes back to my point about the QA team needing to be an
| educational role first and foremost.

Sure. No-one's disputing that. Hence why we're filing all these bugs,
rather than just fixing things straight off.

| It's not silly.  What do you have to fear about having your proposed
| QA standards backed by key teams?  If your arguments have merit, they
| will be supported.

Abuse from people like you whenever someone finally gets brave enough
to document all the ways in which webapp-config is broken.

| I think you're already abusing that power, by calling for a package to
| be removed when it's causing no trouble to anyone, and when the
| workarounds create a worse user experience than what is already there.
|  When the developer in question declines to remove the package, your
| response is a proposed QA mandate that is unbalanced.

No no no. We asked for the package to be fixed. You refused, and
repeatedly closed the bug on us. Since QA couldn't fix the package
cleanly without help from the maintainer, the more drastic solution was
proposed. Had you, instead of closing the bug and refusing to
acknowledge the problem, offered alternatives straight away, QA could
have worked with you to get the thing fixed. This has happened on other
QA bugs, where a developer thought of a different solution to the
problem -- on other bugs, there was no problem because said developer
started a discussion rather than closing the bug off as WONTFIX,
INVALID or CANTFIX.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Monday 27 February 2006 12:08, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 09:00:15 +0000 "Stuart Herbert"
>
> <stuart.herbert@gmail.com> wrote:
> | > Again, then we are going to get into the argument of the definition
> | > of an emergency and never be able to get anything done.  We really
> | > hope problems never come down to this, which is why we left it
> | > worded this way.
> |
> | Me too.  But it will, sooner or later, and when something isn't an
> | emergency, there's no reason why a change cannot wait until the
> | dispute has been resolved.
>
> And, when such a case occurs, there's nothing *requiring* QA to commit
> before the dispute is resolved. It's extremely likely that QA will work
> hard to ensure that everyone is happy before something gets changed.
> However, there are situations where waiting for a month would lead to
> considerable damage, and in those situations QA must be free to act.

if something is going to lead to "considerable damage" and the maintainer is 
unwilling to resolve the issue, then i'm pretty sure there's more to be 
resolved here than fixing a package

not sure leaving this power open ended is really needed
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 12:21:29 -0500 Mike Frysinger <vapier@gentoo.org>
wrote:
| if something is going to lead to "considerable damage" and the
| maintainer is unwilling to resolve the issue, then i'm pretty sure
| there's more to be resolved here than fixing a package

Sure. There're other parts of the document that address that. Getting
the issue fixed, however, has higher priority than any disciplinary
action.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Mon, Feb 27, 2006 at 05:08:34PM +0000, Ciaran McCreesh wrote:
> Abuse from people like you whenever someone finally gets brave enough
> to document all the ways in which webapp-config is broken.

wrobel and I would be very interested to see such a document. In the
meantime, we shall continue to look forward to more whining and moaning from you
et al.
-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

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

On Mon, 2006-02-27 at 17:08 +0000, Ciaran McCreesh wrote:
> Abuse from people like you whenever someone finally gets brave enough
> to document all the ways in which webapp-config is broken.

This isn't the first time we've heard this tune from you, and alas I
fear it won't be the last.

You know where bugzilla is.  You know how to contact any of the
webapp-config maintainers via email, or via IRC.  We're ready to listen
to your input, and to work with you (or anyone else) on fixing any
genuine problems that webapp-config has.  The more feedback we get, the
better we can make this package for everyone's enjoyment.

Please make sure you test your issues against webapp-config v1.5.10 or
later, as that is the latest testing version of the package.

But - if you're not going to take up any of those means of contacting us
with your issues, and instead prefer to behave like this, making general
statements about quality that you're not willing to substantiate and
share with the package maintainers in question, then kindly step down
from the QA team.  

There can be no place for someone who prefers to abuse the mantle of QA
work to attack other people's reputations, exactly like you've just
done, if the Gentoo QA team is to have credibility.

Put up, or shut up, once and for all.

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 20:26:10 +0000 Stuart Herbert <stuart@gentoo.org>
wrote:
| On Mon, 2006-02-27 at 17:08 +0000, Ciaran McCreesh wrote:
| > Abuse from people like you whenever someone finally gets brave
| > enough to document all the ways in which webapp-config is broken.
| 
| This isn't the first time we've heard this tune from you, and alas I
| fear it won't be the last.
| 
| You know where bugzilla is.  You know how to contact any of the
| webapp-config maintainers via email, or via IRC.  We're ready to
| listen to your input, and to work with you (or anyone else) on fixing
| any genuine problems that webapp-config has.  The more feedback we
| get, the better we can make this package for everyone's enjoyment.

Then please start with bug 120088. Once that one's fixed we'll go from
there.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Mon, Feb 27, 2006 at 08:37:09PM +0000, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 20:26:10 +0000 Stuart Herbert <stuart@gentoo.org>
> wrote:
> | On Mon, 2006-02-27 at 17:08 +0000, Ciaran McCreesh wrote:
> | > Abuse from people like you whenever someone finally gets brave
> | > enough to document all the ways in which webapp-config is broken.
> | 
> | This isn't the first time we've heard this tune from you, and alas I
> | fear it won't be the last.
> | 
> | You know where bugzilla is.  You know how to contact any of the
> | webapp-config maintainers via email, or via IRC.  We're ready to
> | listen to your input, and to work with you (or anyone else) on fixing
> | any genuine problems that webapp-config has.  The more feedback we
> | get, the better we can make this package for everyone's enjoyment.
> 
> Then please start with bug 120088. Once that one's fixed we'll go from
> there.

#120088 (dev-lang/php breaks non-interactivity and does not work on default USE)
has nothing to do with webapp-config. What's your point?

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 20:45:30 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
| > Then please start with bug 120088. Once that one's fixed we'll go
| > from there.
| 
| #120088 (dev-lang/php breaks non-interactivity and does not work on
| default USE) has nothing to do with webapp-config. What's your point?

My point is that that's a nasty QA bug that's relying upon input from
Stuart to be fixed. Whilst that one's still alive, I'm not going to go
around filing more similar "breaks non-interactively" bugs because the
discussion will just get repeated over and over.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Mon, Feb 27, 2006 at 08:54:45PM +0000, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 20:45:30 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
> | > Then please start with bug 120088. Once that one's fixed we'll go
> | > from there.
> | 
> | #120088 (dev-lang/php breaks non-interactivity and does not work on
> | default USE) has nothing to do with webapp-config. What's your point?
> 
> My point is that that's a nasty QA bug that's relying upon input from
> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
> around filing more similar "breaks non-interactively" bugs because the
> discussion will just get repeated over and over.

Nice snipping there. Let me quote what was above:
| > Abuse from people like you whenever someone finally gets brave
| > enough to document all the ways in which webapp-config is broken.

Please back up this claim without trying to change the subject.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Grant Goodyear]

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

Ciaran McCreesh wrote:
> My point is that that's a nasty QA bug that's relying upon input from
> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
> around filing more similar "breaks non-interactively" bugs because the
> discussion will just get repeated over and over.

Huh?  I just read through the bug, and it actually appears to be
resolved pending Chris' testing w/ the needed USE flags added to the
various profiles.  I'll admit that the fix is inelegant, but I'm missing
where it's waiting upon Stuart for additional info.  Am I missing something?

-g2boojum-


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen P. Becker]

Grant Goodyear wrote:
> Ciaran McCreesh wrote:
>> My point is that that's a nasty QA bug that's relying upon input from
>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>> around filing more similar "breaks non-interactively" bugs because the
>> discussion will just get repeated over and over.
> 
> Huh?  I just read through the bug, and it actually appears to be
> resolved pending Chris' testing w/ the needed USE flags added to the
> various profiles.  I'll admit that the fix is inelegant, but I'm missing
> where it's waiting upon Stuart for additional info.  Am I missing something?

Yes, you are missing that the bug really isn't fixed.  There are still
USE combinations which would be otherwise perfectly valid, but which
cause php to fail to emerge, thus reaking non-interactivity and forcing
people to (ab)use /etc/portage/package.use to get things working properly.

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


27.2.2006, 22:18:05, Stephen P. Becker wrote:

> Grant Goodyear wrote:
>> Ciaran McCreesh wrote:
>>> My point is that that's a nasty QA bug that's relying upon input from
>>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>> around filing more similar "breaks non-interactively" bugs because the
>>> discussion will just get repeated over and over.
>> 
>> Huh?  I just read through the bug, and it actually appears to be
>> resolved pending Chris' testing w/ the needed USE flags added to the
>> various profiles.  I'll admit that the fix is inelegant, but I'm missing
>> where it's waiting upon Stuart for additional info.  Am I missing something?

> There are still USE combinations which would be otherwise perfectly valid,
> but which cause php to fail to emerge, thus reaking non-interactivity and
> forcing people to (ab)use /etc/portage/package.use to get things working
> properly.

Yeah, and there will be, since chosing between stuff like mysql or recode on
behalf of the user is plain stupid and produces unexpected outcome, since
portage can't handle build_with_use this way, since portage can't handle use
flags conflict at emerge --pretend/--ask time, and last but not least since
there's no such policy that would mandate such changes.

However, I'm still one ear wrt the original topic, which was "all the ways
in which webapp-config is broken".


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Grant Goodyear]

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

Stephen P. Becker wrote:
> Grant Goodyear wrote:
>> Ciaran McCreesh wrote:
>>> My point is that that's a nasty QA bug that's relying upon input from
>>> Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>> around filing more similar "breaks non-interactively" bugs because the
>>> discussion will just get repeated over and over.
>> Huh?  I just read through the bug, and it actually appears to be
>> resolved pending Chris' testing w/ the needed USE flags added to the
>> various profiles.  I'll admit that the fix is inelegant, but I'm missing
>> where it's waiting upon Stuart for additional info.  Am I missing something?
> 
> Yes, you are missing that the bug really isn't fixed.  There are still
> USE combinations which would be otherwise perfectly valid, but which
> cause php to fail to emerge, thus reaking non-interactivity and forcing
> people to (ab)use /etc/portage/package.use to get things working properly.

Well, I did say that it was an inelegant fix....  In any event, I
appreciate your response about php brokenness (I'll come back to this
below), but does this php brokenness require additional info from Stuart
to fix?

Let me try breaking things down a bit to see if I can understand the
various specific problems:

0.  Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other
very much.  *Shrug*  That's not really a problem, it just means that one
needs hip-waders to get through all of the muck.  No big deal; that's
part of being a dev with a really large project.

1.  A fresh Gentoo install w/ default USE flags will fail to compile
dev-lang/php.  That one is being "solved" by adding some additional USE
flags to the default profile.  The claim from the php team is that the
correct fix is a version of portage with USE-based dependencies.  The QA
folks would prefer to see the php ebuild implement a set of sane
defaults to prevent breakages, instead, if I understand correctly, which
in practice would mean that the ebuild would detect whether or not deps
were built with the correct USE flags, and work around any "broken" deps
 in the ebuild.  (I must be missing something, since the latter strikes
me as notably _bad_, since it would mean that two people with identical
USE flags would get different outcomes depending on how their
dependencies are built.)

2.  There are a variety of otherwise-valid USE-flag combinations that
will cause php to fail to build (or be otherwise unusable).  That's
hardly surprising, since dev-lang/php has ~100 USE flags, which means
~2**100 (~10**30) possible USE-flag combinations.  Let's see, there are
roughly pi*10**7 seconds per year, so if we could test one build of php
per second it would only take considerably longer than the lifetime of
the universe to test all of the possible combinations.  Clearly QA of
the current ebuild has to be rather illusory.  Do we have a bug open
about this?  Are there any reasonable suggestions on how to fix it?  I
do realize that the problem is complicated by the fact that people
really do use fairly esoteric php builds on production machines.  That
said, the current situation really is a nightmare!

3.  There are a number of people (not just ciaranm) who consider the
webapp idea to be brilliant in concept, but horribly flawed in its
execution.  (I'm personally fairly agnostic, although the one time that
I had to create a webapp-enabled ebuild I found the process to be
incredibly confusing.  I just assumed that with great flexibility comes
great pain.)  However, I've never known precisely why people feel that
way, and I can't find any bugs about it, so perhaps we could have a real
debate about this issue?  I don't think that bug #120088 is it.

-g2boojum-


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

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

Stephen P. Becker wrote:
> Grant Goodyear wrote:
> 
>>Ciaran McCreesh wrote:
>>
>>>My point is that that's a nasty QA bug that's relying upon input from
>>>Stuart to be fixed. Whilst that one's still alive, I'm not going to go
>>>around filing more similar "breaks non-interactively" bugs because the
>>>discussion will just get repeated over and over.
>>
>>Huh?  I just read through the bug, and it actually appears to be
>>resolved pending Chris' testing w/ the needed USE flags added to the
>>various profiles.  I'll admit that the fix is inelegant, but I'm missing
>>where it's waiting upon Stuart for additional info.  Am I missing something?
> 
> 
> Yes, you are missing that the bug really isn't fixed.  There are still
> USE combinations which would be otherwise perfectly valid, but which
> cause php to fail to emerge, thus reaking non-interactivity and forcing
> people to (ab)use /etc/portage/package.use to get things working properly.
> 
> -Steve

The bug is about *default* use flags breaking interactivity.  There are
donzens of packages that die in pkg_setup if incorrect USE flags are
sepcified, because use-dependencies are not implemented.  I don't
believe anyone is trying to enforce interactivity in that case, because
as far as I'm aware there is no workaround present.

-Alec Warner

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 15:04:52 -0600 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > My point is that that's a nasty QA bug that's relying upon input
| > from Stuart to be fixed. Whilst that one's still alive, I'm not
| > going to go around filing more similar "breaks non-interactively"
| > bugs because the discussion will just get repeated over and over.
| 
| Huh?  I just read through the bug, and it actually appears to be
| resolved pending Chris' testing w/ the needed USE flags added to the
| various profiles.  I'll admit that the fix is inelegant, but I'm
| missing where it's waiting upon Stuart for additional info.  Am I
| missing something?

Yup. It's a huge policy violation being passed off as a feature. See
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
in the paragraph starting "Occasionally, ebuilds will have conflicting
USE flags for functionality.".

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Monday 27 February 2006 22:34, Ciaran McCreesh wrote:

> Yup. It's a huge policy violation being passed off as a feature. See
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=
>1 in the paragraph starting "Occasionally, ebuilds will have conflicting
> USE flags for functionality.".

If that was the only consideration in this case I would agree with you. I 
do however also see Stuart's point on use_with. While it is by itself a 
horible kludge, I agree that it's not really proper design to check for 
all kinds of flags (a changing set) to verify that php was built with a 
certain feature.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

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

On Mon, 2006-02-27 at 20:54 +0000, Ciaran McCreesh wrote:
> My point is that that's a nasty QA bug that's relying upon input from
> Stuart to be fixed. 

I'm afraid you've been mis-informed.  The PHP herd has provided a set of
default USE flags to go into the profiles, and there's a comment at the
bottom of the bug clearly stating that they're currently being tested.

> Whilst that one's still alive, I'm not going to go
> around filing more similar "breaks non-interactively" bugs because the
> discussion will just get repeated over and over.

This point is another example of an attempt to enforce an undocumented
QA policy, which is where I made my input, as the architect of our new
(and well-received) PHP packages.  ... and then the discussion
deteriorated into something I'm not particularly proud of, for my part
in it.

Now, back to the topic at hand.  Either you have genuine QA issues for
webapp-config, which we'd love to know about so that we can fix them, or
you don't.  Which is it?

Best regards,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 21:12:22 +0000 Stuart Herbert <stuart@gentoo.org>
wrote:
| This point is another example of an attempt to enforce an undocumented
| QA policy, which is where I made my input, as the architect of our new
| (and well-received) PHP packages.  ... and then the discussion
| deteriorated into something I'm not particularly proud of, for my part
| in it.

Huh?

I quote the official policy:

http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
> Occasionally, ebuilds will have conflicting USE flags for
> functionality. Checking for them and returning an error is not a
> viable solution. Instead, you must pick one of the USE flags in
> conflict to favour. One example comes from the msmtp ebuilds. The
> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL
> at all. Because GnuTLS is more featureful than OpenSSL, it is
> favoured:

It's a QA violation, and not a feature as you claim.

I find it particularly worrying that you try to pass of blatant policy
violations as a feature. The first step in QA is detecting that there
is a problem.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


27.2.2006, 22:32:39, Ciaran McCreesh wrote:

> I quote the official policy:

> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>> Occasionally, ebuilds will have conflicting USE flags for
>> functionality. Checking for them and returning an error is not a
>> viable solution. Instead, you must pick one of the USE flags in
>> conflict to favour. One example comes from the msmtp ebuilds. The
>> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL
>> at all. Because GnuTLS is more featureful than OpenSSL, it is
>> favoured:

> It's a QA violation, and not a feature as you claim.

> I find it particularly worrying that you try to pass of blatant policy
> violations as a feature. The first step in QA is detecting that there
> is a problem.

No, that's not a policy document, ebuild policy is documented here:
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

Moreover, the cited howto is wrong, since it will break built_with_use
checks, as explained on the relevant bug and as explained here on mailing
list before. The howto also doesn't apply to cases like recode vs. mysql,
because that's a completely different functionality, you can't exactly
choose which one is better on behalf of the user.

So, to sum it up - you can't make up for portage's lack of features by
inventing a policy that doesn't work. Once again - until portage can handle
USE-based dependencies and until portage can handle conflicting use flags,
there's nothing that could be done here.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 04:49, Jakub Moc wrote:
> No, that's not a policy document, ebuild policy is documented here:
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&
>part=3&chap=1

so what, you want us to duplicate everything in one document and place it in 
the other just because one has the title "Policy" ?  that's retarded

the dev handbook documents proper ebuild development regardless of the title 
on a particular page
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| No, that's not a policy document, ebuild policy is documented here:
| http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

No, the whole thing is policy.

| Moreover, the cited howto is wrong, since it will break built_with_use
| checks

No, that's a separate issue.

| The howto also doesn't apply to cases like
| recode vs. mysql, because that's a completely different
| functionality, you can't exactly choose which one is better on behalf
| of the user.

No, it does apply.

| So, to sum it up - you can't make up for portage's lack of features by
| inventing a policy that doesn't work. Once again - until portage can
| handle USE-based dependencies and until portage can handle
| conflicting use flags, there's nothing that could be done here.

Until Portage can handle conflicting USE flags, one should take the
policy-mandated solution that has been sufficient for everyone else for
four years or more. Sure, it's not perfect, but it's a hell of a lot
better than repeatedly exploding in the user's face midway through an
install.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 15:39:40, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | No, that's not a policy document, ebuild policy is documented here:
> |
> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1

> No, the whole thing is policy.

No, it isn't. And silently sticking parts of unofficial gentoo devmanual
into official Gentoo docs, and then silently turning them into a "policy"
enforced under QA disguise is a bad very practice, and pretending that this
has been in the mentioned _howto_ (not policy) for a long time as just plain
silly. Since you haven't answered the question in one of my previous emails
at all, let me ask again:

When and where has been the following change discussed and who approved
that?

http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo


> | Moreover, the cited howto is wrong, since it will break built_with_use
> | checks

> No, that's a separate issue.

No, it isn't. If you want something to have as a policy, it needs to be
error-free, reasonably applicable and not doing more harm than if it isn't
applied at all. And implementing such stuff requires a proper discussion,
considering the consequences and some sort of consent among affected
developers. (Also, that howto example is less than fortunate/clear,
like some user noted in Bug 124401).

> | The howto also doesn't apply to cases like
> | recode vs. mysql, because that's a completely different
> | functionality, you can't exactly choose which one is better on behalf
> | of the user.

> No, it does apply.

No, it doesn't, you can't reasonably favour one of two completely different
functionalities based on some automagic assumption/developer discretion.
That doesn't benefit users in any way and just produces unexpected results
(hey, I explicitely enabled "recode" use flag and php compiled without, the
ebuild is broken, fix0r it!)

> | So, to sum it up - you can't make up for portage's lack of features by
> | inventing a policy that doesn't work. Once again - until portage can
> | handle USE-based dependencies and until portage can handle
> | conflicting use flags, there's nothing that could be done here.

> Until Portage can handle conflicting USE flags, one should take the
> policy-mandated solution that has been sufficient for everyone else for
> four years or more. Sure, it's not perfect, but it's a hell of a lot
> better than repeatedly exploding in the user's face midway through an
> install.

No, noone should enforce a policy that

- doesn't exist (see above)
- hasn't been discussed properly and approved (see above)
- it's consequences haven't been considered wrt whether its benefits
overweight the negatives and whether is useful at all.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Tue, 28 Feb 2006 16:08:05 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> When and where has been the following change discussed and who
> approved that?
> 
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

According to my recollection, it was discussed between members of QA
and devrel. According to the CVS logs, it was committed by a member of
devrel, at QA's request. You can't pass it off as a QA project
conspiracy, since they didn't make the change.
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 16:29:07, Stephen Bennett wrote:

> On Tue, 28 Feb 2006 16:08:05 +0100
> Jakub Moc <jakub@gentoo.org> wrote:

>> When and where has been the following change discussed and who
>> approved that?
>> 
>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

> According to my recollection, it was discussed between members of QA
> and devrel. According to the CVS logs, it was committed by a member of
> devrel, at QA's request. You can't pass it off as a QA project
> conspiracy, since they didn't make the change.

I'm sorry, but discussing such stuff affecting pretty much everyone who
writes ebuilds among a couple of people simply isn't enough to make this a
policy. And then silently applying this and starting to scream "QA
violation, look, what a nasty QA violation!!!" is plain ridiculous.

Punting every single piece of broken sh*t from the tree requires notifying
everyone on -dev ml and allowing a period of time before it's actually done,
so silently changing/stating policies is a very broken practice.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Tue, 28 Feb 2006 16:42:30 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> Punting every single piece of broken sh*t from the tree requires
> notifying everyone on -dev ml and allowing a period of time before
> it's actually done, so silently changing/stating policies is a very
> broken practice.

This wasn't a silent change. It's been policy for as long as I can
remember; it was just made explicit in the devrel documentation with
that commit.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Policies (was: [RFC] QA Team's role)

[Danny van Dyk]

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

Hi Jakub,

Jakub Moc schrieb:
| 28.2.2006, 16:29:07, Stephen Bennett wrote:
|>>When and where has been the following change discussed and who
|>>approved that?
|>>
|>>http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo
|>According to my recollection, it was discussed between members of QA
|>and devrel. According to the CVS logs, it was committed by a member of
|>devrel, at QA's request. You can't pass it off as a QA project
|>conspiracy, since they didn't make the change.
| I'm sorry, but discussing such stuff affecting pretty much everyone who
| writes ebuilds among a couple of people simply isn't enough to make this a
| policy. And then silently applying this and starting to scream "QA
| violation, look, what a nasty QA violation!!!" is plain ridiculous.
Well, it was common sense before. Especially because it was part of the
devmanual. I know, the next argument will be: The devmanual is not
official. However, this particular text had been part of the devmanual
for a long time. Many devs read it and afaict nobody objected against it
while it was 'unofficial'. In my opinion, there was enough time to raise
a hand and yell: 'I don't like it'.

Beside this, I'd like to support the non-interactive mode on the base of
efficiency: It is better to install a package with a default and sane
set of USE flags instead of breaking the whole update process.

However, this incident should be logged by portage.

| Punting every single piece of broken sh*t from the tree requires notifying
| everyone on -dev ml and allowing a period of time before it's actually
done,
| so silently changing/stating policies is a very broken practice.
Nobody changed anything. It was written down before in the devmanual and
then incorporated into the developer handbook.

If you don't agree with the contents, why didn't you raise your
opposition earlier?

If you agree with the contents, please ask yourself if the current
discussion is necessary.

I'm looking forward to your answers on the last 2 points.
Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEBHk1aVNL8NrtU6IRAlRbAKCH233GWmOQWlRy/DQQh/aRR++4ZACfd230
rYQgmnvH9Y/0YSijnCSAOIc=
=QQEa
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)

[Jakub Moc]

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


28.2.2006, 17:24:21, Danny van Dyk wrote:

> Hi Jakub,

> If you don't agree with the contents, why didn't you raise your
> opposition earlier?

I don't feel any need to raise opposition against some unofficial manual,
what would be the point in that? I'm raising my hand against silently
incorporating parts of it (that affect a lot of stuff in the tree) into
official docs without a proper discussion, even more so that they are being
claimed as an official QA policy now. Documents located in private devspace
of some devs are non-official and noone checks their contents for
correctness, they are private activity of those devs.

> If you agree with the contents, please ask yourself if the current
> discussion is necessary.

See above.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] Policies (was: [RFC] QA Team's role)

[Mike Frysinger]

On Tuesday 28 February 2006 11:39, Jakub Moc wrote:
> 28.2.2006, 17:24:21, Danny van Dyk wrote:
> > If you don't agree with the contents, why didn't you raise your
> > opposition earlier?
>
> I don't feel any need to raise opposition against some unofficial manual,
> what would be the point in that? I'm raising my hand against silently 
> incorporating parts of it (that affect a lot of stuff in the tree) into
> official docs without a proper discussion, even more so that they are being
> claimed as an official QA policy now. Documents located in private devspace
> of some devs are non-official and noone checks their contents for
> correctness, they are private activity of those devs.

input was solicited from the developer community before about ciaranm's 
unofficial manual with notes that the plan was to incorporate it piece by 
piece into the official dev handbook
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| 28.2.2006, 15:39:40, Ciaran McCreesh wrote:
| > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org>
| > wrote:
| > | No, that's not a policy document, ebuild policy is documented
| > | here:
| > |
| > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1
| 
| > No, the whole thing is policy.
| 
| No, it isn't.

'Fraid it is. Everything in the devrel handbook that isn't explicitly
marked as a guideline is policy.

| And silently sticking parts of unofficial gentoo
| devmanual into official Gentoo docs, and then silently turning them
| into a "policy" enforced under QA disguise is a bad very practice,
| and pretending that this has been in the mentioned _howto_ (not
| policy) for a long time as just plain silly. Since you haven't
| answered the question in one of my previous emails at all, let me ask
| again:
| 
| When and where has been the following change discussed and who
| approved that?
| 
| http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

Wouldn't know. That was nothing to do with me. I just wrote the
original text (or actually, that might not even have been me). It
finding its way into the policy docs was devrel's doing.

| > | Moreover, the cited howto is wrong, since it will break
| > | built_with_use checks
| 
| > No, that's a separate issue.
| 
| No, it isn't. If you want something to have as a policy, it needs to
| be error-free, reasonably applicable and not doing more harm than if
| it isn't applied at all. And implementing such stuff requires a
| proper discussion, considering the consequences and some sort of
| consent among affected developers. (Also, that howto example is less
| than fortunate/clear, like some user noted in Bug 124401).

built_with_use isn't a question of conflicting USE flags. It's a
separate question of dependency resolution, and in this situation it
*can't* be solved using the method that's been standard for four years
or more.

| > | The howto also doesn't apply to cases like
| > | recode vs. mysql, because that's a completely different
| > | functionality, you can't exactly choose which one is better on
| > | behalf of the user.
| 
| > No, it does apply.
| 
| No, it doesn't, you can't reasonably favour one of two completely
| different functionalities based on some automagic
| assumption/developer discretion. That doesn't benefit users in any
| way and just produces unexpected results (hey, I explicitely enabled
| "recode" use flag and php compiled without, the ebuild is broken,
| fix0r it!)

By all means warn the user. There's nothing in policy disallowing that.

| No, noone should enforce a policy that
| 
| - doesn't exist (see above)

The whole devrel handbook is policy, except where otherwise noted. See
Mike's reply.

| - hasn't been discussed properly and approved (see above)

Nothing in the devrel handbook was discussed properly or approved.

| - it's consequences haven't been considered wrt whether its benefits
| overweight the negatives and whether is useful at all.

This one doesn't rule out the policy item in question.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 16:29:10, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | 28.2.2006, 15:39:40, Ciaran McCreesh wrote:
| >> On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org>
| >> wrote:
| >> | No, that's not a policy document, ebuild policy is documented
| >> | here:
| >> |
| >> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable&part=3&chap=1
> | 
| >> No, the whole thing is policy.
> | 
> | No, it isn't.

> 'Fraid it is. Everything in the devrel handbook that isn't explicitly
> marked as a guideline is policy.

Sorry, such procedure is not acceptable until you change the whole
metastructure of the project so that a bunch of people is allowed to dictate
to others whatever they think is fit. (Another question is how many people
will want to work on such project.) Until that's done, things should be
discussed and some form of consent reached.

> | When and where has been the following change discussed and who |
> approved that? |  |
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo

> Wouldn't know. That was nothing to do with me. I just wrote the
> original text (or actually, that might not even have been me). It
> finding its way into the policy docs was devrel's doing.

Again, see above.

| >> | Moreover, the cited howto is wrong, since it will break
| >> | built_with_use checks
> | 
| >> No, that's a separate issue.
> | 
> | No, it isn't. If you want something to have as a policy, it needs to
> | be error-free, reasonably applicable and not doing more harm than if
> | it isn't applied at all. And implementing such stuff requires a
> | proper discussion, considering the consequences and some sort of
> | consent among affected developers. (Also, that howto example is less
> | than fortunate/clear, like some user noted in Bug 124401).

> built_with_use isn't a question of conflicting USE flags. It's a
> separate question of dependency resolution, and in this situation it
> *can't* be solved using the method that's been standard for four years
> or more.

Sure it is. You can't silently enable/disable some feature if other ebuilds
are checking for that feature using those very use flags that you have
ignored/overriden/bypassed. Such checks are useless then and more stuff gets
broken than gets fixed.

> | No, it doesn't, you can't reasonably favour one of two completely |
> different functionalities based on some automagic | assumption/developer
> discretion. That doesn't benefit users in any | way and just produces
> unexpected results (hey, I explicitely enabled | "recode" use flag and php
> compiled without, the ebuild is broken, | fix0r it!)

> By all means warn the user. There's nothing in policy disallowing that.

That doesn't work, it breaks other things as explained above. Please, don't
use a hammer where watchmaker's screwdriver is a proper tool, otherwise
you'll severely damage the whole thing. One minute spent on tweaking use
flags is much less important than a bunch of useful features missing just
because you've hammered the whole stuff together.

> | No, noone should enforce a policy that
> | 
> | - doesn't exist (see above)

> The whole devrel handbook is policy, except where otherwise noted. See
> Mike's reply.

Then any significant change there requires a sane procedure.


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Wednesday 01 March 2006 02:37, Jakub Moc wrote:
> 28.2.2006, 16:29:10, Ciaran McCreesh wrote:
> > The whole devrel handbook is policy, except where otherwise noted. See
> > Mike's reply.
>
> Then any significant change there requires a sane procedure.

which does not change the fact that the devrel handbook is policy unless 
otherwise noted as suggestion or guideline
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 10:08, Jakub Moc wrote:
> 28.2.2006, 15:39:40, Ciaran McCreesh wrote:
> > On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> > | No, that's not a policy document, ebuild policy is documented here:
> >
> > http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printabl
> >e&part=3&chap=1
> >
> > No, the whole thing is policy.
>
> No, it isn't.

yes, it is ... that's the point of the handbook
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


27.2.2006, 22:32:39, Ciaran McCreesh wrote:

> I quote the official policy:

> http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
>> Occasionally, ebuilds will have conflicting USE flags for
>> functionality. Checking for them and returning an error is not a
>> viable solution. Instead, you must pick one of the USE flags in
>> conflict to favour. One example comes from the msmtp ebuilds. The
>> package can use either SSL with GnuTLS, SSL with OpenSSL, or no SSL
>> at all. Because GnuTLS is more featureful than OpenSSL, it is
>> favoured:

And - one more note - when and where has been the following change discussed
and who approved that?!

http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25&r2=1.26&root=gentoo


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Mon, 27 Feb 2006 21:12:22 +0000
Stuart Herbert <stuart@gentoo.org> wrote:

> On Mon, 2006-02-27 at 20:54 +0000, Ciaran McCreesh wrote:
> > My point is that that's a nasty QA bug that's relying upon input
> > from Stuart to be fixed. 
> 
> I'm afraid you've been mis-informed.  The PHP herd has provided a set
> of default USE flags to go into the profiles, and there's a comment
> at the bottom of the bug clearly stating that they're currently being
> tested.

That's not a fix. That's a workaround. The PHP ebuilds are still
broken; all that's changed is that the breakage isn't apparent on a
default install.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Monday 27 February 2006 16:12, Stuart Herbert wrote:
> On Mon, 2006-02-27 at 20:54 +0000, Ciaran McCreesh wrote:
> > Whilst that one's still alive, I'm not going to go
> > around filing more similar "breaks non-interactively" bugs because the
> > discussion will just get repeated over and over.
>
> This point is another example of an attempt to enforce an undocumented
> QA policy

the non-interactive rule has never been stated, just hinted at

for example, the dev handbook mentions offhand:
* Testing the package
Please keep in mind the general requirements of an ebuild here. The src_test 
routine must not be interactive.

if you like i can rectify this situation in the Ebuild policy guide
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


27.2.2006, 21:37:09, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 20:26:10 +0000 Stuart Herbert <stuart@gentoo.org>
> wrote:
> | On Mon, 2006-02-27 at 17:08 +0000, Ciaran McCreesh wrote:
| >> Abuse from people like you whenever someone finally gets brave
| >> enough to document all the ways in which webapp-config is broken.
> | 
> | This isn't the first time we've heard this tune from you, and alas I
> | fear it won't be the last.
> | 
> | You know where bugzilla is.  You know how to contact any of the
> | webapp-config maintainers via email, or via IRC.  We're ready to
> | listen to your input, and to work with you (or anyone else) on fixing
> | any genuine problems that webapp-config has.  The more feedback we
> | get, the better we can make this package for everyone's enjoyment.

> Then please start with bug 120088. Once that one's fixed we'll go from
> there.

<rhetorical question>
May I ask how is that related to webapp-config?
</rhetorical question>

You can't escape this way... so don't even try. You've been talking about
broken webapp-config, then go ahead and show us the breakage. If there's
nothing you have to say in that respect, then just rather stick foot in your
mouth next time you are going to assault someone.

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| <rhetorical question>
| May I ask how is that related to webapp-config?
| </rhetorical question>

It is related to Stuart, and hence utterly relevant to the conversation.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


27.2.2006, 22:33:21, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | <rhetorical question>
> | May I ask how is that related to webapp-config?
> | </rhetorical question>

> It is related to Stuart, and hence utterly relevant to the conversation.

Ah, sure - so the topic is that you have personal issues with Stuart and are
washing your dirty laundry in a public ML?

You still haven't posted posted a *single example* of webapp-config
brokeness. You, I'd say you should either back up claims about "all the ways
in which webapp-config is broken" or apologize to the concerned developers
for false claims.

Still waiting.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen P. Becker]

> You still haven't posted posted a *single example* of webapp-config
> brokeness. You, I'd say you should either back up claims about "all the ways
> in which webapp-config is broken" or apologize to the concerned developers
> for false claims.
> 
> Still waiting.
> 

OK, here is one.  It seems that webapp-config silently assumes your 
webserver is apache by default.  If a user uses lighttpd for example, 
this is totally incorrect.

Now, this doesn't cause webapp-config to fail to emerge, but the first 
time you emerge any webapp, you get a big nasty error about no Apache 
group available, which further requires the end user to dig around the 
webapp-config manpage to figure out the correct file to edit *just* to 
get a silly php script to install in the correct location.

And please, don't tell me this is a feature.  It breaks noninteractivity 
for every "webapp" in the entire tree.

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 13:54:36, Stephen P. Becker wrote:

>> You still haven't posted posted a *single example* of webapp-config
>> brokeness. You, I'd say you should either back up claims about "all the ways
>> in which webapp-config is broken" or apologize to the concerned developers
>> for false claims.
>> 
>> Still waiting.
>> 

> OK, here is one.  It seems that webapp-config silently assumes your 
> webserver is apache by default.  If a user uses lighttpd for example, 
> this is totally incorrect.

Why don't you voice your solutions on Bug 11007? The whole underlying stuff
is hell broader than what webapp-config assumes or doesn't assume.

> Now, this doesn't cause webapp-config to fail to emerge, but the first 
> time you emerge any webapp, you get a big nasty error about no Apache 
> group available, which further requires the end user to dig around the 
> webapp-config manpage to figure out the correct file to edit *just* to 
> get a silly php script to install in the correct location.

The above is a direct result of purging all kind of useful predefined
users/groups from /etc/{passwd,group} without considering any wider
consequences. It has already caused circular deps and broke a couple of
things, included but non-limited to installing Gentoo itself (search
bugzilla for related bugs). Where is the whole benefit from this, I still
have to see.

webapp-config should be updated to handle such situation more gracefully, so
why don't you file a bug about this? Is that all you have wrt "all the ways
in which webapp-config is broken"? If so, that's not really much of a
justification of the broad claim ciaranm has made as a QA project member.

> And please, don't tell me this is a feature.  It breaks noninteractivity 
> for every "webapp" in the entire tree.

What kind of non-interactivity? What's this universal non-interactivity
blurb of yours and ciaranm's about? There's no such thing when it comes to
configuration. If you want automated "configuration", then please use
Windows and stop moaning. If you don't want to read manpages or at least
--help, then please use Windows as well. If you want to use non-default
setup, then you need to change default values, that's what common sense
dictates at least. And don't use the (non)-interactivity magical formular in
a context where it has zero sense.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen P. Becker]

> webapp-config should be updated to handle such situation more gracefully, so
> why don't you file a bug about this? Is that all you have wrt "all the ways
> in which webapp-config is broken"? If so, that's not really much of a
> justification of the broad claim ciaranm has made as a QA project member.

I only encountered the problem the day before yesterday, and hadn't 
gotten around to filing the bug yet.  I assure you that I intend on 
doing so.

> 
>> And please, don't tell me this is a feature.  It breaks noninteractivity 
>> for every "webapp" in the entire tree.
> 
> What kind of non-interactivity? What's this universal non-interactivity
> blurb of yours and ciaranm's about? There's no such thing when it comes to
> configuration. If you want automated "configuration", then please use
> Windows and stop moaning. If you don't want to read manpages or at least
> --help, then please use Windows as well. If you want to use non-default
> setup, then you need to change default values, that's what common sense
> dictates at least. And don't use the (non)-interactivity magical formular in
> a context where it has zero sense.

No! You are completely missing the point.  The non-interactivity of 
which we speak is the idea that when you emerge some package, it is 
perfectly reasonable (and in fact should be required) to expect that 
package to install to your userland with no further prodding.  There 
should be no USE collisions which cause the emerge to die.  There should 
be no default configuration which will break other packages in the tree 
by default.

Note that in no way am I talking about auto-configuration, as that would 
be silly.  The example problem with webapp-config which I have described 
here forces a user to intervene to get packages to install to the proper 
location.  This is not desirable.

Basically, I really don't see why webapp-config can't have some logic 
built in which makes it smart enough to figure out which webserver 
somebody is using.

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 15:00:49, Stephen P. Becker wrote:

>> What kind of non-interactivity? What's this universal non-interactivity
>> blurb of yours and ciaranm's about? There's no such thing when it comes to
>> configuration. If you want automated "configuration", then please use
>> Windows and stop moaning. If you don't want to read manpages or at least
>> --help, then please use Windows as well. If you want to use non-default
>> setup, then you need to change default values, that's what common sense
>> dictates at least. And don't use the (non)-interactivity magical formular in
>> a context where it has zero sense.

> No! You are completely missing the point.  The non-interactivity of 
> which we speak is the idea that when you emerge some package, it is 
> perfectly reasonable (and in fact should be required) to expect that 
> package to install to your userland with no further prodding.  There 
> should be no USE collisions which cause the emerge to die.  There should 
> be no default configuration which will break other packages in the tree 
> by default.

> Note that in no way am I talking about auto-configuration, as that would 
> be silly.  The example problem with webapp-config which I have described 
> here forces a user to intervene to get packages to install to the proper 
> location.  This is not desirable.

Selecting a webserver to use with a webapp package is a part of
configuration. So again, the whole non-interactive idea is irrelevant wrt
webapp-config and non-default setups. No defaults in default config won't
work/won't improve anything either, since some webapps need to have their
config files server-owned. Running a server and webapps is not a no-brainer
which should just automagically work; to the contrary - users should think
about what they are doing or they just should run a server app.

> Basically, I really don't see why webapp-config can't have some logic 
> built in which makes it smart enough to figure out which webserver 
> somebody is using.

Sure, you can make webapp-config depend on virtual/magic where

RDEPEND="|| ( app-admin/artificial-intelligence app-admin/mind-reader )

and then

emerge lighttpd apache <a couple of servers here> <some random webapps here>

I think it's pretty much obvious that this just won't work since such
virtual doesn't and won't exist.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 15:00, Stephen P. Becker wrote:

> Basically, I really don't see why webapp-config can't have some logic
> built in which makes it smart enough to figure out which webserver
> somebody is using.

Please remember that the apache group is just another name for httpd 
group. And it is not linked to the apache webserver. Perhaps the group 
should be renamed, and webapp-config should require it's presence when it 
is installed.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

On 2/28/06, Stephen P. Becker <geoman@gentoo.org> wrote:
> OK, here is one.  It seems that webapp-config silently assumes your
> webserver is apache by default.  If a user uses lighttpd for example,
> this is totally incorrect.
>
> Now, this doesn't cause webapp-config to fail to emerge, but the first
> time you emerge any webapp, you get a big nasty error about no Apache
> group available, which further requires the end user to dig around the
> webapp-config manpage to figure out the correct file to edit *just* to
> get a silly php script to install in the correct location.

There's no need to be rude about php scripts.

Thank you for reporting this error.

We've committed a fix for this problem upstream.  We'll probably roll
out w-c 1.5.11 at the weekend.  That'll give us suitable time to test
this, and to incorporate the QA issues from Ciaran that we're still
waiting for.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 14:21:14 +0000 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| We've committed a fix for this problem upstream.  We'll probably roll
| out w-c 1.5.11 at the weekend.  That'll give us suitable time to test
| this, and to incorporate the QA issues from Ciaran that we're still
| waiting for.

It's going to take longer than that for me to get you a full, properly
explained list of every QA issue I can find. Now, I *could* give you
the shorter list of stuff I noticed within half an hour of using it,
but I'd rather get this done properly if I'm doing it at all.

I'm still not convinced that it's worth my while, however, based upon
your past attitude of claiming "it's a feature". My time could better
be spent helping out developers who will actually fix their breakages.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

On 2/28/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> I'm still not convinced that it's worth my while

*You* chose to mention webapp-config in this thread.  Stop making
excuses.  Make good on your claims.

Put up, or shut up.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| You still haven't posted posted a *single example* of webapp-config
| brokeness. You, I'd say you should either back up claims about "all
| the ways in which webapp-config is broken" or apologize to the
| concerned developers for false claims.

Fine. If posting a single way in which webapp-config is broken will
make you happy, here you go:

From webapp.eclass:

    function webapp_read_config ()
    {

This is a whitespace / coding style breakage. The correct format should
be:

    webapp_read_config() {

Yes, it's an utterly trivial problem, but it is a QA violation. Getting
a complete list is something that takes a heck of a lot longer, and I
have yet to be convinced that my time would not be better spent
elsewhere.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 14:52 +0000, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | You still haven't posted posted a *single example* of webapp-config
> | brokeness. You, I'd say you should either back up claims about "all
> | the ways in which webapp-config is broken" or apologize to the
> | concerned developers for false claims.
> 
> Fine. If posting a single way in which webapp-config is broken will
> make you happy, here you go:
> 
> From webapp.eclass:
> 
>     function webapp_read_config ()
>     {
> 
> This is a whitespace / coding style breakage. The correct format should
> be:
> 
>     webapp_read_config() {
> 
> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
> a complete list is something that takes a heck of a lot longer, and I
> have yet to be convinced that my time would not be better spent
> elsewhere.
Wow. That is ... impressive. After about two days of asking for any real
bugs you are able to show a trivial syntax issue?

Please stop yelling "it si teh b0rk!" if you can't even list any serious
issues, and stop being rude to other people.

Thanks,
Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 16:12:32, Patrick Lauer wrote:

>> This is a whitespace / coding style breakage. The correct format should
>> be:
>> 
>>     webapp_read_config() {
>> 
>> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
>> a complete list is something that takes a heck of a lot longer, and I
>> have yet to be convinced that my time would not be better spent
>> elsewhere.
> Wow. That is ... impressive. After about two days of asking for any real
> bugs you are able to show a trivial syntax issue?

> Please stop yelling "it si teh b0rk!" if you can't even list any serious
> issues, and stop being rude to other people.

Patrick++

If you can't do any better, then please apologize for your conduct and false
claims and shut up... TIA.


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| If you can't do any better, then please apologize for your conduct
| and false claims and shut up... TIA.

Sure I can do better. But you didn't originally ask for better, you
asked for anything. If better's what you're after:

    SLOT="${PVR}"

Now, please apologise for insinuating that I don't have any real claims
to make. I find it extremely offensive that you're questioning my
technical ability.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 15:42 +0000, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.
> 
> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:
> 
>     SLOT="${PVR}"
> 
> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.
Ok, sorry for being dumb :-)
What exactly is the issue there? I don't see the issue in setting SLOT
depending on ... uhm ... some variable. Looks kinda logical at first
glance, but I'm not aware of the issues it causes.

Thanks for explaining,

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <patrick@gentoo.org>
wrote:
| Ok, sorry for being dumb :-)
| What exactly is the issue there? I don't see the issue in setting SLOT
| depending on ... uhm ... some variable. Looks kinda logical at first
| glance, but I'm not aware of the issues it causes.

PVR includes the revision of an ebuild. This means that if a revbump is
made on a webapp package to fix a critical flaw, users will still have
the old broken package installed too. This is especially relevant for
security issues, but also applies to other kinds of fix.

Ebuilds can't override this either. Read on in the eclass and you'll
notice that it checks that SLOT hasn't been changed to something sane.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 17:35:32, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer <patrick@gentoo.org>
> wrote:
> | Ok, sorry for being dumb :-)
> | What exactly is the issue there? I don't see the issue in setting SLOT
> | depending on ... uhm ... some variable. Looks kinda logical at first
> | glance, but I'm not aware of the issues it causes.

> PVR includes the revision of an ebuild. This means that if a revbump is
> made on a webapp package to fix a critical flaw, users will still have
> the old broken package installed too. This is especially relevant for
> security issues, but also applies to other kinds of fix.

Not including the revision into the SLOT can break the apps by removing the
needed files from a live site... I still can't see any *QA* violation there.

> Ebuilds can't override this either. Read on in the eclass and you'll
> notice that it checks that SLOT hasn't been changed to something sane.

Yeah, it checks for that since that's the way the eclass is designed. You
can't declare a slot in a kernel ebuild either.

Well, starts to be boring - so, either come with something valid from QA
standpoint or stop now.

-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| > PVR includes the revision of an ebuild. This means that if a
| > revbump is made on a webapp package to fix a critical flaw, users
| > will still have the old broken package installed too. This is
| > especially relevant for security issues, but also applies to other
| > kinds of fix.
| 
| Not including the revision into the SLOT can break the apps by
| removing the needed files from a live site... I still can't see any
| *QA* violation there.

Again, that's a design flaw. It's an eclass that's abusing SLOT, thus
it's a QA issue.

| Yeah, it checks for that since that's the way the eclass is designed.
| You can't declare a slot in a kernel ebuild either.

One is a design flaw. The other is not.

| Well, starts to be boring - so, either come with something valid from
| QA standpoint or stop now.

This is a valid issue from a QA standpoint. This is also why I'm not
going to waste my time doing a proper list -- rather than addressing
issues, they are being passed off as irrelevant or even features.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 18:09:54, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| >> PVR includes the revision of an ebuild. This means that if a
| >> revbump is made on a webapp package to fix a critical flaw, users
| >> will still have the old broken package installed too. This is
| >> especially relevant for security issues, but also applies to other
| >> kinds of fix.
> | 
> | Not including the revision into the SLOT can break the apps by
> | removing the needed files from a live site... I still can't see any
> | *QA* violation there.

> Again, that's a design flaw. It's an eclass that's abusing SLOT, thus
> it's a QA issue.

OK, so kernel-2.eclass is abusing the slot as well, go scream on kernel
devs.

> | Yeah, it checks for that since that's the way the eclass is designed.
> | You can't declare a slot in a kernel ebuild either.

> One is a design flaw. The other is not.

Ah, tell me about the dual standards :P

> | Well, starts to be boring - so, either come with something valid from
> | QA standpoint or stop now.

> This is a valid issue from a QA standpoint. This is also why I'm not
> going to waste my time doing a proper list -- rather than addressing
> issues, they are being passed off as irrelevant or even features.

Next time, rather think a couple of times up before claiming something very
broken on a public mailing list where you have no proof for such claims.
Will be immensely helpful for everyone involved.

Thanks.


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| OK, so kernel-2.eclass is abusing the slot as well, go scream on
| kernel devs.

No. kernel-2 installs sources, not an actual package.

| > | Yeah, it checks for that since that's the way the eclass is
| > | designed. You can't declare a slot in a kernel ebuild either.
| 
| > One is a design flaw. The other is not.
| 
| Ah, tell me about the dual standards :P

Not dual standards at all. There's nothing wrong with saying "don't do
x unless you're doing y", with appropriate justification.

| > | Well, starts to be boring - so, either come with something valid
| > | from QA standpoint or stop now.
| 
| > This is a valid issue from a QA standpoint. This is also why I'm not
| > going to waste my time doing a proper list -- rather than addressing
| > issues, they are being passed off as irrelevant or even features.
| 
| Next time, rather think a couple of times up before claiming
| something very broken on a public mailing list where you have no
| proof for such claims. Will be immensely helpful for everyone
| involved.

No proof?

Sheesh, you'll probably claim that this isn't broken next too:

    if [ "${IS_UPGRADE}" = "1" ] ; then
        einfo "Removing old version ${REMOVE_PKG}"

        emerge -C "${REMOVE_PKG}"
    fi

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 17:38 +0000, Ciaran McCreesh wrote:
> Sheesh, you'll probably claim that this isn't broken next too:
> 
>     if [ "${IS_UPGRADE}" = "1" ] ; then
>         einfo "Removing old version ${REMOVE_PKG}"
> 
>         emerge -C "${REMOVE_PKG}"
>     fi
Ciaran,
(and this is valid for all emails to technical lists,)
please save us some time and many emails by stating what is wrong when
you show a QA violation.
Many among us don't think in assembler and don't know enough about the
code to decide if/why something is wrong. This in turn causes someone
(like me) to send an email asking what is wrong, causing another reply
by you etc. etc.

It's a bit like me stating:
"The bug is in line 14:
	i+=2
"
If you don't know the code you won't understand why.

Now if I said "line 14 increments by two, but then you won't ever get
out of the loop since the exit condition won't be met" everyone could
understand it and evaluate my statement.

If you show a wrong code snippet please explain _why_ it is wrong in the
same email.

Thanks,

Patrick

-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Dan Meltzer]

On 2/28/06, Patrick Lauer <patrick@gentoo.org> wrote:
> On Tue, 2006-02-28 at 17:38 +0000, Ciaran McCreesh wrote:
> > Sheesh, you'll probably claim that this isn't broken next too:
> >
> >     if [ "${IS_UPGRADE}" = "1" ] ; then
> >         einfo "Removing old version ${REMOVE_PKG}"
> >
> >         emerge -C "${REMOVE_PKG}"
> >     fi
> Ciaran,
> (and this is valid for all emails to technical lists,)
> please save us some time and many emails by stating what is wrong when
> you show a QA violation.
> Many among us don't think in assembler and don't know enough about the
> code to decide if/why something is wrong. This in turn causes someone
> (like me) to send an email asking what is wrong, causing another reply
> by you etc. etc.
>
> It's a bit like me stating:
> "The bug is in line 14:
>         i+=2
> "
> If you don't know the code you won't understand why.
>
> Now if I said "line 14 increments by two, but then you won't ever get
> out of the loop since the exit condition won't be met" everyone could
> understand it and evaluate my statement.
>
> If you show a wrong code snippet please explain _why_ it is wrong in the
> same email.

I believe the bug is calling emerge from within the eclass.


>
> Thanks,
>
> Patrick
>
> --
> Stand still, and let the rest of the universe move
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.1-ecc0.1.6 (GNU/Linux)
>
> iD8DBQBEBI+UqER3hOUoZM4RAjzxAJ9tvaSOY3625NaptPTj/yLxXrIXJACeITwy
> 43JQjZpI+HEckc6Mla3f9l0=
> =so5q
> -----END PGP SIGNATURE-----
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer <patrick@gentoo.org>
wrote:
| (and this is valid for all emails to technical lists,)
| please save us some time and many emails by stating what is wrong when
| you show a QA violation.

Oh come on. I'm not going to insult the intelligence of people reading
this list by explaining something that frickin' obvious. When it's a
subtle issue I explain why it's wrong. When it isn't, I try to avoid
wasting everyone's time by making them read a huge explanation of
something they all already know.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Wernfried Haas]

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

On Tue, Feb 28, 2006 at 06:12:57PM +0000, Ciaran McCreesh wrote:
> Oh come on. I'm not going to insult the intelligence of people reading
> this list by explaining something that frickin' obvious. When it's a
> subtle issue I explain why it's wrong. When it isn't, I try to avoid
> wasting everyone's time by making them read a huge explanation of
> something they all already know.

Explaining stuff usually helps more than elitism. Those who already
know it can simply skip it, those who don't may learn a bit and
everyone wins. A lot of people are subscribed to this list and not
everyone is an ebuild dev, but some may be tomorrow's devs.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

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

Re: [gentoo-dev] [RFC] QA Team's role

[Fernando J. Pereda]

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

On Tue, Feb 28, 2006 at 06:59:49PM +0100, Patrick Lauer wrote:
> If you show a wrong code snippet please explain _why_ it is wrong in the
> same email.

Ehm.... you mean it is not obvious that calling emerge inside an eclass
is utterly wrong ?

-- 
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Tue, 28 Feb 2006 18:59:49 +0100
Patrick Lauer <patrick@gentoo.org> wrote:

> (and this is valid for all emails to technical lists,)
> please save us some time and many emails by stating what is wrong when
> you show a QA violation.

This is a technical discussion list, and as such it is fair to assume
that anyone getting involved in a discussion on a particularly topic
knows enough about said topic to understand what is going on. If you
can't see what's wrong with the snippet he gave, then you shouldn't be
in the discussion, and, frankly, probably shouldn't have commit rights
to the tree either.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 18:19 +0000, Stephen Bennett wrote:
> On Tue, 28 Feb 2006 18:59:49 +0100
> Patrick Lauer <patrick@gentoo.org> wrote:
> 
> > (and this is valid for all emails to technical lists,)
> > please save us some time and many emails by stating what is wrong when
> > you show a QA violation.
> 
> This is a technical discussion list, and as such it is fair to assume
> that anyone getting involved in a discussion on a particularly topic
> knows enough about said topic to understand what is going on. If you
> can't see what's wrong with the snippet he gave, then you shouldn't be
> in the discussion, and, frankly, probably shouldn't have commit rights
> to the tree either.
Yeah, like it took me about two minutes of staring at the snippet to see
why it's evil when reading a short explanation would have made me see
that in 15 seconds. 

After all not everyone reading this list is a code ninja, please just
stop this email pingpong and (like we do it with bugs) explain what is
the issue instead of letting people guess. 

That might even teach those that are not yet super-gurus and is in
general a nice thing to do.
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Tue, 28 Feb 2006 17:38:10 +0000
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

>     if [ "${IS_UPGRADE}" = "1" ] ; then
>         einfo "Removing old version ${REMOVE_PKG}"
> 
>         emerge -C "${REMOVE_PKG}"
>     fi

Uh, what the fuck is that doing in an eclass ?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Alec Warner]

Ciaran McCreesh wrote:

>On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
>| OK, so kernel-2.eclass is abusing the slot as well, go scream on
>| kernel devs.
>
>No. kernel-2 installs sources, not an actual package.
>
>| > | Yeah, it checks for that since that's the way the eclass is
>| > | designed. You can't declare a slot in a kernel ebuild either.
>| 
>| > One is a design flaw. The other is not.
>| 
>| Ah, tell me about the dual standards :P
>
>Not dual standards at all. There's nothing wrong with saying "don't do
>x unless you're doing y", with appropriate justification.
>
>| > | Well, starts to be boring - so, either come with something valid
>| > | from QA standpoint or stop now.
>| 
>| > This is a valid issue from a QA standpoint. This is also why I'm not
>| > going to waste my time doing a proper list -- rather than addressing
>| > issues, they are being passed off as irrelevant or even features.
>| 
>| Next time, rather think a couple of times up before claiming
>| something very broken on a public mailing list where you have no
>| proof for such claims. Will be immensely helpful for everyone
>| involved.
>
>No proof?
>
>Sheesh, you'll probably claim that this isn't broken next too:
>
>    if [ "${IS_UPGRADE}" = "1" ] ; then
>        einfo "Removing old version ${REMOVE_PKG}"
>
>        emerge -C "${REMOVE_PKG}"
>    fi
>
>  
>
Semantics of the logic aside, calling emerge from within an ebuild is a 
BIG nono.

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Thomas de Grenier de Latour]

On Tue, 28 Feb 2006 13:02:10 -0500,
Alec Warner <antarus@gentoo.org> wrote:

> Ciaran McCreesh wrote:
> 
> >    if [ "${IS_UPGRADE}" = "1" ] ; then
> >        einfo "Removing old version ${REMOVE_PKG}"
> >
> >        emerge -C "${REMOVE_PKG}"
> >    fi
> >
> >  
> >
> Semantics of the logic aside, calling emerge from within an ebuild is
> a BIG nono.
> 

Reading the comments in the eclass, i can undestand the motivation.
 # why do we do this?  well ...
 #
 # normally, emerge -u installs a new version and then removes the
 # old version.  however, if the new version goes into a different
 # slot to the old version, then the old version gets left behind
 #
 # if USE=-vhosts, then we want to remove the old version, because
 # the user is relying on portage to do the magical thing for it


Two suggestions (don't really know what they are worth though):

* Short term, still evil, but less than calling emerge:
 pkg_postinst() {
    ...
    if ! use vhost ; then
       echo 0 > ${ROOT}var/db/pkg/${CATEGORY}/${PN}-${PVR}/SLOT
    fi
 }
This way, emerge's autoclean (the slow one, at the end) would 
remove old version of USE="-vhost" packages, since they would be 
all slotted "0".

* Long term, don't know how difficult it would be: Do some kind of
USE-expansion of the SLOT variable, to allow something like 
  SLOT="vhost? ( ${PVR} ) !vhost? ( 0 )"
This would only affect SLOT when read from porttree sure. In vartree, 
and in the ebuild env in general, it  should still be the reduced 
version ("${PVR}" or "0") that is used.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
> On Tue, 28 Feb 2006 13:02:10 -0500,
> Alec Warner <antarus@gentoo.org> wrote:
> 
> > Ciaran McCreesh wrote:
> > 
> > >    if [ "${IS_UPGRADE}" = "1" ] ; then
> > >        einfo "Removing old version ${REMOVE_PKG}"
> > >
> > >        emerge -C "${REMOVE_PKG}"
> > >    fi

For those who are interested, ciaranm has kindly filed bug #124443, so please
comment there.
-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
> On Tue, 28 Feb 2006 13:02:10 -0500,
> Alec Warner <antarus@gentoo.org> wrote:
> 
> > Ciaran McCreesh wrote:
> > 
> > >    if [ "${IS_UPGRADE}" = "1" ] ; then
> > >        einfo "Removing old version ${REMOVE_PKG}"
> > >
> > >        emerge -C "${REMOVE_PKG}"
> > >    fi

That's #124440, not #124443 which is the SLOT issue.
-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 18:38:10, Ciaran McCreesh wrote:


> Sheesh, you'll probably claim that this isn't broken next too:

>     if [ "${IS_UPGRADE}" = "1" ] ; then
>         einfo "Removing old version ${REMOVE_PKG}"

>         emerge -C "${REMOVE_PKG}"
>     fi

No, I won't claim that... I'd rather love to know why didn't you point out
to an obvious eclass flaw about 30 emails and many hours ago, saving us from
all the eclass formating, slotting and ewarn blurb. The above needs to be
fixed, period.

To return to the original topic - focus your QA efforts on real issues. Same
goes for that non-interactivity stuff. QA that serves no other purpose than
inventing problems to enforce an inevitably hackish solution (there's no
good one because the needed tools are not available) is not useful at all.
There's nothing useful in inventing policies that create more problems than
they solve and that are forcing shitty bash code into the tree to work
around missing features.

Portage is a tool to install and manage packages, and serves no good purpose
on its own. Crippling installed packages and their available features for
the sole purpose of having nice ebuild tree with clean bash code is not what
QA is for. Improving the whole process is fine and welcome, as long as it
doesn't unnecessarily interfere with the desired outcome. Users need to
install some software they want to use and need its features, portage and
ebuids are only the means to do that, not a holy cow.


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Danny van Dyk]

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

Jakub Moc schrieb:
| 28.2.2006, 18:38:10, Ciaran McCreesh wrote:

| No, I won't claim that... I'd rather love to know why didn't you point out
| to an obvious eclass flaw about 30 emails and many hours ago, saving
us from
| all the eclass formating, slotting and ewarn blurb. The above needs to be
| fixed, period.
|
| To return to the original topic - focus your QA efforts on real
issues. Same
| goes for that non-interactivity stuff. QA that serves no other purpose
than
interactivie stuff in the tree (outside of pkg_config() function) _is_ a
QA problem.

| inventing problems to enforce an inevitably hackish solution (there's no
| good one because the needed tools are not available) is not useful at all.

| Portage is a tool to install and manage packages, and serves no good
purpose
| on its own. Crippling installed packages and their available features for
| the sole purpose of having nice ebuild tree with clean bash code is
not what
| QA is for. Improving the whole process is fine and welcome, as long as it
Wrong. This is exactly what QA is for. There are additional duties for
the QA team beside clean bash code.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFEBKe7aVNL8NrtU6IRAl75AKCT9h+9V4sM9YxRgIoaD+136dug9ACgkqoI
chBYTGNn2hEChDAi/WfV1+k=
=INNg
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 20:09:02 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| 28.2.2006, 18:38:10, Ciaran McCreesh wrote:
| > Sheesh, you'll probably claim that this isn't broken next too:
| 
| >     if [ "${IS_UPGRADE}" = "1" ] ; then
| >         einfo "Removing old version ${REMOVE_PKG}"
| 
| >         emerge -C "${REMOVE_PKG}"
| >     fi
| 
| No, I won't claim that... I'd rather love to know why didn't you
| point out to an obvious eclass flaw about 30 emails and many hours
| ago, saving us from all the eclass formating, slotting and ewarn
| blurb.

Why didn't you look before accusing me of not having valid issues? I
mean, it's pretty frickin' hard to miss that one.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 20:09:02 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | 28.2.2006, 18:38:10, Ciaran McCreesh wrote:
> | > Sheesh, you'll probably claim that this isn't broken next too:
> | >
> | >     if [ "${IS_UPGRADE}" = "1" ] ; then
> | >         einfo "Removing old version ${REMOVE_PKG}"
> | >
> | >         emerge -C "${REMOVE_PKG}"
> | >     fi
> |
> | No, I won't claim that... I'd rather love to know why didn't you
> | point out to an obvious eclass flaw about 30 emails and many hours
> | ago, saving us from all the eclass formating, slotting and ewarn
> | blurb.
>
> Why didn't you look before accusing me of not having valid issues? I
> mean, it's pretty frickin' hard to miss that one.

This code (or an equivalent kludge/hack) does however allow features that are 
of great value to our users. While I agree that such hacks should be avoided 
if possible, I think in this case it is not. As such the appropriate response 
is to isolate the hack in a central place, where it is clear to be seen and 
can easilly be fixed. This allows the quality of the hack to be ensured, 
relieving many webapps from doing hacks themselves.

While this hack is being used, some effort should be put into constructively 
creating a proper solution for the problems that were hacked around. Saying 
"this is not allowed because of X policy" is not helpful as the costs of 
disallowing it greatly outweigh the costs of overlooking it in a controlled 
manner.

Paul

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

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


1.3.2006, 13:09:55, Paul de Vrieze wrote:

> On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:

>> | >     if [ "${IS_UPGRADE}" = "1" ] ; then
>> | >         einfo "Removing old version ${REMOVE_PKG}"
>> | >
>> | >         emerge -C "${REMOVE_PKG}"
>> | >     fi

> This code (or an equivalent kludge/hack) does however allow features that are
> of great value to our users. While I agree that such hacks should be avoided
> if possible, I think in this case it is not. As such the appropriate response
> is to isolate the hack in a central place, where it is clear to be seen and 
> can easilly be fixed. This allows the quality of the hack to be ensured, 
> relieving many webapps from doing hacks themselves.

> While this hack is being used, some effort should be put into
> constructively creating a proper solution for the problems that were
> hacked around. Saying  "this is not allowed because of X policy" is not
> helpful as the costs of  disallowing it greatly outweigh the costs of
> overlooking it in a controlled  manner.

Well yeah, but the problem here is that portage doesn't allow such stuff to
be used safely (locking issues, race conditions). And yeah, it's kinda
lacking sort of feature that would have its use in a couple of places.

--

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Simon Stelling]

Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | OK, so kernel-2.eclass is abusing the slot as well, go scream on
> | kernel devs.
> 
> No. kernel-2 installs sources, not an actual package.

Not exactly. The webapp stuff gets installed to /usr/share/webapps/${PN}/${PVR},
which is about the equivalent of /usr/src/linux because you will never point
your webserver to that directory. If you do, you're just dumb and deserve a
security flaw. webapp-config installs the packages to /var/www (equivalent of
/boot), where the webserver should make it available. So the SLOT="${PVR}" is
not an issue in this case.

-- 
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
blubb@gentoo.org
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 04:35:32PM +0000, Ciaran McCreesh wrote:
> Ebuilds can't override this either. Read on in the eclass and you'll
> notice that it checks that SLOT hasn't been changed to something sane.

Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to whatever the
hell you want. But don't let my facts get in the way of your nonsense.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 17:02:11 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
| On Tue, Feb 28, 2006 at 04:35:32PM +0000, Ciaran McCreesh wrote:
| > Ebuilds can't override this either. Read on in the eclass and you'll
| > notice that it checks that SLOT hasn't been changed to something
| > sane.
| 
| Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to
| whatever the hell you want. But don't let my facts get in the way of
| your nonsense.

And it sticks out a nasty ewarn and says that the ebuild is probably
broken.

Again, you're dismissing QA issues as nonsense, and you wonder why I
don't waste my time doing a full audit.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote:
> And it sticks out a nasty ewarn and says that the ebuild is probably
> broken.

Which it _probably_ is. See, this is a numbers game. In most cases, if you use
the webapp eclass, setting SLOT="0" is incorrect. There are some cases in which
it's just fine. Until FEATURES="mindreader" is implemented, how is the eclass to
know what you're trying to do? So it prints a warning and doesn't die. Number of
angry users storming bugs.g.o - 0. 

> Again, you're dismissing QA issues as nonsense, and you wonder why I
> don't waste my time doing a full audit.

No, what I was trying to do was call your distaste for fact-checking
nonsensical, apologies if it wasn't crystal clear. Please keep the QA issues
coming.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 12:51, Renat Lumpau wrote:
> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote:
> > And it sticks out a nasty ewarn and says that the ebuild is probably
> > broken.
>
> Which it _probably_ is. See, this is a numbers game. In most cases, if you
> use the webapp eclass, setting SLOT="0" is incorrect. There are some cases
> in which it's just fine. Until FEATURES="mindreader" is implemented, how is
> the eclass to know what you're trying to do? So it prints a warning and
> doesn't die. Number of angry users storming bugs.g.o - 0.

why do you need to be a mindreader ?  the user requested they control the 
package, thus it isnt a bug, so dont issue a warning
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 20:59:42, Mike Frysinger wrote:

> On Tuesday 28 February 2006 12:51, Renat Lumpau wrote:
>> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote:
>> > And it sticks out a nasty ewarn and says that the ebuild is probably
>> > broken.
>>
>> Which it _probably_ is. See, this is a numbers game. In most cases, if you
>> use the webapp eclass, setting SLOT="0" is incorrect. There are some cases
>> in which it's just fine. Until FEATURES="mindreader" is implemented, how is
>> the eclass to know what you're trying to do? So it prints a warning and
>> doesn't die. Number of angry users storming bugs.g.o - 0.

> why do you need to be a mindreader ?  the user requested they control the 
> package, thus it isnt a bug, so dont issue a warning
> -mike

Sure, and when *ebuild* requested it instead, then portage will be
automagically informed. So yeah, we can implement yet another variable into
the eclass, and we can do tons of other magic voodoo about three lines of
eclass that noone has ever noticed until today, and the whole thing can be a
lot more complex for sure. Sorry, I call this a complete waste of time.

-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 15:10, Jakub Moc wrote:
> 28.2.2006, 20:59:42, Mike Frysinger wrote:
> > On Tuesday 28 February 2006 12:51, Renat Lumpau wrote:
> >> On Tue, Feb 28, 2006 at 05:11:57PM +0000, Ciaran McCreesh wrote:
> >> > And it sticks out a nasty ewarn and says that the ebuild is probably
> >> > broken.
> >>
> >> Which it _probably_ is. See, this is a numbers game. In most cases, if
> >> you use the webapp eclass, setting SLOT="0" is incorrect. There are some
> >> cases in which it's just fine. Until FEATURES="mindreader" is
> >> implemented, how is the eclass to know what you're trying to do? So it
> >> prints a warning and doesn't die. Number of angry users storming
> >> bugs.g.o - 0.
> >
> > why do you need to be a mindreader ?  the user requested they control the
> > package, thus it isnt a bug, so dont issue a warning
>
> Sure, and when *ebuild* requested it instead, then portage will be
> automagically informed. So yeah, we can implement yet another variable into 
> the eclass, and we can do tons of other magic voodoo about three lines of
> eclass that noone has ever noticed until today, and the whole thing can be
> a lot more complex for sure. Sorry, I call this a complete waste of time.

whats your point ?  if an ebuild author wants to control the SLOT, then they 
should be able to without having an invalid warning issued on the subject

considering the nature of the warning, it should be trivial to make it into a 
proper QA check by having the class see where files were installed and then 
warn/abort if certain conditions are met

there's no reason for the user to see this crap
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 21:39:43, Mike Frysinger wrote:

> whats your point ?  if an ebuild author wants to control the SLOT, then
> they should be able to without having an invalid warning issued on the
> subject

> considering the nature of the warning, it should be trivial to make it into a
> proper QA check by having the class see where files were installed and then 
> warn/abort if certain conditions are met

> there's no reason for the user to see this crap
> -mike

Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
eclass inherited illegally crap and a couple of others - this isn't going
anywhere.

You are trying to solve something that noone ever complained about. Why not
rather solve stuff like ebuilds that depend unconditionally on arts, but
because they inherit kde eclass they get bogus arts use flag from the
eclass. This is an issue that's truly confusing and that people are filing
bugs about. There's the difference between doing something useful and
wasting time on an artificially invented issue.

--

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
> 28.2.2006, 21:39:43, Mike Frysinger wrote:
> > whats your point ?  if an ebuild author wants to control the SLOT, then
> > they should be able to without having an invalid warning issued on the
> > subject
> >
> > considering the nature of the warning, it should be trivial to make it
> > into a proper QA check by having the class see where files were installed
> > and then warn/abort if certain conditions are met
> >
> > there's no reason for the user to see this crap
>
> Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
> eclass inherited illegally crap and a couple of others - this isn't going
> anywhere.

unrelated ... that is a portage limitation that has deeper work going on 
around it to resolve the issue properly ... this is an eclass limitation that 
can be resolved now

> You are trying to solve something that noone ever complained about. Why not
> rather solve stuff like ebuilds that depend unconditionally on arts, but
> because they inherit kde eclass they get bogus arts use flag from the
> eclass. This is an issue that's truly confusing and that people are filing
> bugs about. There's the difference between doing something useful and
> wasting time on an artificially invented issue.

right, so from now on people shouldnt bother fixing issues until a bug is 
filed, that way we know someone actually cares enough to have the issue 
resolved

today's lesson: proactive QA is frowned upon, it's only a bug when a user 
files a report at bugs.gentoo.org
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote:
> today's lesson: proactive QA is frowned upon, it's only a bug when a user 
> files a report at bugs.gentoo.org

I don't think that's the lesson. It oughtta be: we need a way to figure out
which QA issues are important and which are less so. A QA team member's opinion
(personal attacks, whatever) should be an important input but not the final say.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Dan Meltzer]

On 2/28/06, Renat Lumpau <rl03@gentoo.org> wrote:
> On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote:
> > today's lesson: proactive QA is frowned upon, it's only a bug when a user
> > files a report at bugs.gentoo.org
>
> I don't think that's the lesson. It oughtta be: we need a way to figure out
> which QA issues are important and which are less so. A QA team member's opinion
> (personal attacks, whatever) should be an important input but not the final say.

eh, see, from what I can tell you are just deciding to make it complicated.

Do a quick bugzie search for bugs reported in the last week by
ciaranm, I don't think he's singling you out.  I think he's responding
to your stubbornness.
>
> --
> Renat Lumpau       all things web-apps
> C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
> America - land of the free*
> *Void where prohibited, restrictions apply. Cash value 1/100c.
>
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 04:55:52PM -0500, Dan Meltzer wrote:
> eh, see, from what I can tell you are just deciding to make it complicated.

How is having a process for resolving disagreements complicating things? I
should be able to escalate a conflict (differing opinions on whether something
is a QA issue and how serious it is).  From what I understand, the QA team
leader already admitted ciaranm doesn't listen to him.

> Do a quick bugzie search for bugs reported in the last week by
> ciaranm, I don't think he's singling you out.  I think he's responding
> to your stubbornness.

Did I say I think he's singling me out? He brought up an issue relevant to my
herd and I chimed in. And if by being stubborn you mean not ignoring his utter
lack of ability to work with others, sure, call me stubborn.


-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 21:50:40 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
| On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote:
| > today's lesson: proactive QA is frowned upon, it's only a bug when
| > a user files a report at bugs.gentoo.org
| 
| I don't think that's the lesson. It oughtta be: we need a way to
| figure out which QA issues are important and which are less so. A QA
| team member's opinion (personal attacks, whatever) should be an
| important input but not the final say.

Important QA issues are, first and foremost, the ones that can be
detected and fixed quickly.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 09:57:05PM +0000, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 21:50:40 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
> | On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote:
> | > today's lesson: proactive QA is frowned upon, it's only a bug when
> | > a user files a report at bugs.gentoo.org
> | 
> | I don't think that's the lesson. It oughtta be: we need a way to
> | figure out which QA issues are important and which are less so. A QA
> | team member's opinion (personal attacks, whatever) should be an
> | important input but not the final say.
> 
> Important QA issues are, first and foremost, the ones that can be
> detected and fixed quickly.

You mean like whitespace and syntax that affects noone?

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Grant Goodyear]

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

Renat Lumpau wrote:
> On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote:
>> today's lesson: proactive QA is frowned upon, it's only a bug when a user 
>> files a report at bugs.gentoo.org
> 
> I don't think that's the lesson. It oughtta be: we need a way to figure out
> which QA issues are important and which are less so. A QA team member's opinion
> (personal attacks, whatever) should be an important input but not the final say.

At the risk of trying to get this conversation back on track, here's
what has been happening:  Some members of the QA team are working on a
new QA tool to identify QA problems in the portage tree.  As they add
new tests, they run their tool on the tree, and file bugs on any
packages that are found to violate that particular QA test.  I think
it's fair to say that these QA checks will find problems ranging from
not-awful-but-annoying to could-break-your-system, but they are all bugs
that ought to be fixed eventually.  Now, if you're currently working on
fixing a big problem and thus too busy to fix the little one, that's
perfectly reasonable, but to not fix a small bug because you know there
are larger bugs that aren't fixed just seems lazy.

So, back to the big issue, are there any real complaints about the QA
team essentially formulating QA policy?  Should new QA policies instead
follow the same rules as new global USE flags or eclasses--an e-mail to
-dev asking for comments first?  Does QA trump, or does the maintainer
trump when it comes to disputes?

-g2boojum-


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 04:14:33PM -0600, Grant Goodyear wrote:
> I think
> it's fair to say that these QA checks will find problems ranging from
> not-awful-but-annoying to could-break-your-system, but they are all bugs
> that ought to be fixed eventually.  Now, if you're currently working on
> fixing a big problem and thus too busy to fix the little one, that's
> perfectly reasonable, but to not fix a small bug because you know there
> are larger bugs that aren't fixed just seems lazy.

I agree completely. However, ciaranm seems to think that if we don't fix a
whitespace issue immediately, we'll ignore the rest of his QA comments and it's
therefore not worth it to let us know about the bigger issues:

in #gentoo-qa today:
18:39 <@ciaranm> pfff, if they won't fix whitespace, what're the chances of
                 them fixing anything else?

That's an odd position to take.

> So, back to the big issue, are there any real complaints about the QA
> team essentially formulating QA policy?  Should new QA policies instead
> follow the same rules as new global USE flags or eclasses--an e-mail to
> -dev asking for comments first?  Does QA trump, or does the maintainer
> trump when it comes to disputes?

Yes. Here's a quote from Halcy0n (with his permission):

  Don't mistake me not getting involved for approval.  I am just not going to
  get involved in every single dev->dev disagreement, and certainly not when I
  do not have all of the facts.  I wasn't aware that every team leader was
  accountable for how devs on their team behaved.

This is not meant as a comment on Halcy0n's abilities as a team leader, as I
understand he has attempted to manage the issue but "reasonable effort" has
failed.

So, my concern is: if the QA team can't manage its members effectively, should
they be entrusted with tree-wide powers?

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Renat Lumpau <rl03@gentoo.org> said:
> Yes. Here's a quote from Halcy0n (with his permission):
> 
>   Don't mistake me not getting involved for approval.  I am just not going to
>   get involved in every single dev->dev disagreement, and certainly not when I
>   do not have all of the facts.  I wasn't aware that every team leader was
>   accountable for how devs on their team behaved.
> 
> This is not meant as a comment on Halcy0n's abilities as a team leader, as I
> understand he has attempted to manage the issue but "reasonable effort" has
> failed.
> 
> So, my concern is: if the QA team can't manage its members effectively, should
> they be entrusted with tree-wide powers?

Since one dev so far has stepped "out of line", and this is by no means the
only time it has happened, I don't see how this argument has any
merit.  If it becomes a pattern where all members of the QA team are
causing problems, then I can see it as being valid.

I don't think you will find one person that is going to say they are
capable of changing how Ciaran interacts with people.  This is an
entirely different issue though, and I have talked to Ciaran about it.
What I was saying above is that I am not going to go and get involved
every single time someone has a disagreement.  This situation has
obviously grown to be ridiculous and I have had a talk with him about
it, so he knows my feelings on the situation, and what I expect.

-- 
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] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 06:34:32PM -0500, Mark Loeser wrote:
> Renat Lumpau <rl03@gentoo.org> said:
> > Yes. Here's a quote from Halcy0n (with his permission):
> > 
> >   Don't mistake me not getting involved for approval.  I am just not going to
> >   get involved in every single dev->dev disagreement, and certainly not when I
> >   do not have all of the facts.  I wasn't aware that every team leader was
> >   accountable for how devs on their team behaved.
> > 
> > This is not meant as a comment on Halcy0n's abilities as a team leader, as I
> > understand he has attempted to manage the issue but "reasonable effort" has
> > failed.
> > 
> > So, my concern is: if the QA team can't manage its members effectively, should
> > they be entrusted with tree-wide powers?
> 
> Since one dev so far has stepped "out of line", and this is by no means the
> only time it has happened, I don't see how this argument has any
> merit.  If it becomes a pattern where all members of the QA team are
> causing problems, then I can see it as being valid.
> 
> I don't think you will find one person that is going to say they are
> capable of changing how Ciaran interacts with people.  This is an
> entirely different issue though, and I have talked to Ciaran about it.
> What I was saying above is that I am not going to go and get involved
> every single time someone has a disagreement.  This situation has
> obviously grown to be ridiculous and I have had a talk with him about
> it, so he knows my feelings on the situation, and what I expect.

So you're saying it's ok to have one team member who steps out of line and
cannot be managed?  Are all teams allowed that exception?

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Renat Lumpau <rl03@gentoo.org> said:
> So you're saying it's ok to have one team member who steps out of line and
> cannot be managed?  Are all teams allowed that exception?

Did you read what I said?  I talked to him and told him what I expect.
I'm telling you to not expect him to change, not that I expect QA team
members to behave that way.

-- 
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] [RFC] QA Team's role

[Lance Albertson]

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

Mark Loeser wrote:

> I don't think you will find one person that is going to say they are
> capable of changing how Ciaran interacts with people.  This is an
> entirely different issue though, and I have talked to Ciaran about it.
> What I was saying above is that I am not going to go and get involved
> every single time someone has a disagreement.  This situation has
> obviously grown to be ridiculous and I have had a talk with him about
> it, so he knows my feelings on the situation, and what I expect.

I should note that if are a Gentoo Developer and have
problems/concerns/issues with Ciaran's attitude/actions, please comment
on bug #114944. (this bug is only open to Gentoo developers). Its better
if you say it yourself in this bug rather than letting other people
quoting what you say.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| I should note that if are a Gentoo Developer and have
| problems/concerns/issues with Ciaran's attitude/actions, please
| comment on bug #114944. (this bug is only open to Gentoo developers).
| Its better if you say it yourself in this bug rather than letting
| other people quoting what you say.

I should note that if you are a Gentoo developer who has found my
advice helpful, you should comment on bug #114944 since certain people
are trying to turn Gentoo development into a popularity contest.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
>
> <ramereth@gentoo.org> wrote:
> | I should note that if are a Gentoo Developer and have
> | problems/concerns/issues with Ciaran's attitude/actions, please
> | comment on bug #114944. (this bug is only open to Gentoo developers).
> | Its better if you say it yourself in this bug rather than letting
> | other people quoting what you say.
>
> I should note that if you are a Gentoo developer who has found my
> advice helpful, you should comment on bug #114944 since certain people
> are trying to turn Gentoo development into a popularity contest.

there's a lot more to the issue, but it's sad if that's all you see in the bug
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


1.3.2006, 1:40:53, Mike Frysinger wrote:

> On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote:
>> On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson
>>
>> <ramereth@gentoo.org> wrote:
>> | I should note that if are a Gentoo Developer and have
>> | problems/concerns/issues with Ciaran's attitude/actions, please
>> | comment on bug #114944. (this bug is only open to Gentoo developers).
>> | Its better if you say it yourself in this bug rather than letting
>> | other people quoting what you say.
>>
>> I should note that if you are a Gentoo developer who has found my
>> advice helpful, you should comment on bug #114944 since certain people
>> are trying to turn Gentoo development into a popularity contest.

> there's a lot more to the issue, but it's sad if that's all you see in the bug
> -mike

Indeed. Ciaran, that bug is not about technical competence; it's about your
civil communication skills, that are as lacking as penguins on the Sahara
desert in your case. Technical skills themselves are not useful for a
project the requires you to communicate w/ other people in a civilized
manner.

As someone else noted, certains "skills" might be fit for a car salesmen but
not for developers of a Linux distro. If a company hires a technically
brilliant QA guy only to find out later on that this brilliant guy has
killed the whole team while communicating his finding to others in such
style you have shown on this thread and on many other occasions before,
it'll be the QA guy who gets booted out, not the whole team. If that doesn't
happen soon enough, the rest of the team can leave meanwhile and the whole
business is doomed.

-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Lance Albertson]

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

Lance Albertson wrote:

> I should note that if are a Gentoo Developer and have
> problems/concerns/issues with Ciaran's attitude/actions, please comment
> on bug #114944. (this bug is only open to Gentoo developers). Its better
> if you say it yourself in this bug rather than letting other people
> quoting what you say.

Since some people may read this the wrong way, let me please clarify.

If you have *anything* (good or bad) to add to the bug, please feel free
to (If you're a developer). I'm not trying to single out one developer,
rather I felt that informing developers about it (since there has been a
lot of frustration shown on this list) was a good idea.

Sorry if it seemed more biased one way or the other. It was not my
intention at all. I assumed people would read that and realize that they
could also add good comments if they wanted to.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

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

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 16:14 -0600, Grant Goodyear wrote:
> So, back to the big issue, are there any real complaints about the QA
> team essentially formulating QA policy?  Should new QA policies instead
> follow the same rules as new global USE flags or eclasses--an e-mail to
> -dev asking for comments first?  Does QA trump, or does the maintainer
> trump when it comes to disputes?
I think the QA team is free to classify QA bugs, but any changes should
be pushed to the -dev ML just so that everyone is aware what is
happening. It's a bit, well, annoying if QA decides that we have to use
the Wrong Bracing Style in eclasses and files 50 bugs for cosmetic fixes
while there are ebuilds doing evil things, but if there's a warning
("We'll file bugs on Saturday if there are no objections to removal of
mkdir in global scope") I can live with that. Also QA should not just
decide on something without a documented explanation - it will erode
their credibility as it is seen as a random process unless there is
documentation.

In case of dispute in general QA should be stronger than a single
maintainer, but combined with the fact that QA also creates policy that
would be a bit tricky. Disputes should be escalated along the normal
devrel dispute lines I think, just think of QA as another herd/project
and that mostly makes sense :-)
QA is still new, so the communication channels might not be perfect- I
hope everybody manages to cooperate so that Gentoo is the least buggy
distro of them all when 2006.1 comes out ;-)

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 23:42:34 +0100 Patrick Lauer <patrick@gentoo.org>
wrote:
| ("We'll file bugs on Saturday if there are no objections to removal
| of mkdir in global scope")

Eek no. Have you any idea what happens when someone shoves an mkdir in
global scope? That one is most definitely on the list of "stuff that
gets fixed in any way, up to and including immediate cvs rm even if it
screws up deps for an arch" list.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Patrick Lauer]

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

On Tue, 2006-02-28 at 22:50 +0000, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 23:42:34 +0100 Patrick Lauer <patrick@gentoo.org>
> wrote:
> | ("We'll file bugs on Saturday if there are no objections to removal
> | of mkdir in global scope")
> 
> Eek no. Have you any idea what happens when someone shoves an mkdir in
> global scope? That one is most definitely on the list of "stuff that
> gets fixed in any way, up to and including immediate cvs rm even if it
> screws up deps for an arch" list.
> 
It seems that your sense of humor has gone missing ...
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 200 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Patrick Lauer <patrick@gentoo.org> said:
> On Tue, 2006-02-28 at 16:14 -0600, Grant Goodyear wrote:
> > So, back to the big issue, are there any real complaints about the QA
> > team essentially formulating QA policy?  Should new QA policies instead
> > follow the same rules as new global USE flags or eclasses--an e-mail to
> > -dev asking for comments first?  Does QA trump, or does the maintainer
> > trump when it comes to disputes?
> I think the QA team is free to classify QA bugs, but any changes should
> be pushed to the -dev ML just so that everyone is aware what is
> happening. It's a bit, well, annoying if QA decides that we have to use
> the Wrong Bracing Style in eclasses and files 50 bugs for cosmetic fixes
> while there are ebuilds doing evil things, but if there's a warning
> ("We'll file bugs on Saturday if there are no objections to removal of
> mkdir in global scope") I can live with that. Also QA should not just
> decide on something without a documented explanation - it will erode
> their credibility as it is seen as a random process unless there is
> documentation.

As I said, we plan on documenting everything as we find problems.  I
also don't expect us to be capable of creating completely new policies
off in some corner and just surprise people with them.  Communication
with the rest of Gentoo is going to be needed, but I am not sure of the
best possible way to get things "approved".  I think if something we find
is highly questionable, that we should be able to "fix" it if possible,
until such a time when a decision can be reached.  (more on this below)

> In case of dispute in general QA should be stronger than a single
> maintainer, but combined with the fact that QA also creates policy that
> would be a bit tricky. Disputes should be escalated along the normal
> devrel dispute lines I think, just think of QA as another herd/project
> and that mostly makes sense :-)

Devrel is really for non-technical issues, and for dev->dev problems.
I would like to see enough trust in the QA team to be able to make these
decisions on its own, instead of making one team responsible for
everything (devrel).

> QA is still new, so the communication channels might not be perfect- I
> hope everybody manages to cooperate so that Gentoo is the least buggy
> distro of them all when 2006.1 comes out ;-)

Thanks, hopefully enough people have faith in us to do the right thing
so that we can get everything fixed up that we can.

-- 
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] [RFC] QA Team's role

[Alec Warner]

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

Mike Frysinger wrote:
> On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
> 
>>28.2.2006, 21:39:43, Mike Frysinger wrote:
>>
>>>whats your point ?  if an ebuild author wants to control the SLOT, then
>>>they should be able to without having an invalid warning issued on the
>>>subject
>>>
>>>considering the nature of the warning, it should be trivial to make it
>>>into a proper QA check by having the class see where files were installed
>>>and then warn/abort if certain conditions are met
>>>
>>>there's no reason for the user to see this crap
>>
>>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
>>eclass inherited illegally crap and a couple of others - this isn't going
>>anywhere.
> 
> 
> unrelated ... that is a portage limitation that has deeper work going on 
> around it to resolve the issue properly ... this is an eclass limitation that 
> can be resolved now
> 
> 
>>You are trying to solve something that noone ever complained about. Why not
>>rather solve stuff like ebuilds that depend unconditionally on arts, but
>>because they inherit kde eclass they get bogus arts use flag from the
>>eclass. This is an issue that's truly confusing and that people are filing
>>bugs about. There's the difference between doing something useful and
>>wasting time on an artificially invented issue.
> 
> 
> right, so from now on people shouldnt bother fixing issues until a bug is 
> filed, that way we know someone actually cares enough to have the issue 
> resolved
> 
> today's lesson: proactive QA is frowned upon, it's only a bug when a user 
> files a report at bugs.gentoo.org
> -mike

Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see
bugs filed in almost all circumstances.  If QA and the maintainer can
fix stuff without bugs, thats cool, especially for trivial matters.  If
QA and the developer aren't getting along on a specific issue then there
is no reason NOT to have a bug open.

Otherwise you get circumstances that were also discussed, such as "I
told the maintainer in person over a year ago..." which may in fact be
true, but people forget things and make mistakes and now you have
nothing to point at for proof of inactivity except a vague statement.
Better to cover your rear and be able to point to a year old bug with a
solution attached, and be like "look there is a bug and a fix and no one
did jack squat."  Essentially you have a case for any sane developer to
agree with.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 894 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 16:58, Alec Warner wrote:
> Mike Frysinger wrote:
> > On Tuesday 28 February 2006 16:02, Jakub Moc wrote:
> >>28.2.2006, 21:39:43, Mike Frysinger wrote:
> >>>whats your point ?  if an ebuild author wants to control the SLOT, then
> >>>they should be able to without having an invalid warning issued on the
> >>>subject
> >>>
> >>>considering the nature of the warning, it should be trivial to make it
> >>>into a proper QA check by having the class see where files were
> >>> installed and then warn/abort if certain conditions are met
> >>>
> >>>there's no reason for the user to see this crap
> >>
> >>Yeah, and there's no reason for user to see USE_EXPAND QA notice crap,
> >>eclass inherited illegally crap and a couple of others - this isn't going
> >>anywhere.
> >
> > unrelated ... that is a portage limitation that has deeper work going on
> > around it to resolve the issue properly ... this is an eclass limitation
> > that can be resolved now
> >
> >>You are trying to solve something that noone ever complained about. Why
> >> not rather solve stuff like ebuilds that depend unconditionally on arts,
> >> but because they inherit kde eclass they get bogus arts use flag from
> >> the eclass. This is an issue that's truly confusing and that people are
> >> filing bugs about. There's the difference between doing something useful
> >> and wasting time on an artificially invented issue.
> >
> > right, so from now on people shouldnt bother fixing issues until a bug is
> > filed, that way we know someone actually cares enough to have the issue
> > resolved
> >
> > today's lesson: proactive QA is frowned upon, it's only a bug when a user
> > files a report at bugs.gentoo.org
>
> Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see
> bugs filed in almost all circumstances.  If QA and the maintainer can
> fix stuff without bugs, thats cool, especially for trivial matters.  If
> QA and the developer aren't getting along on a specific issue then there
> is no reason NOT to have a bug open.
>
> Otherwise you get circumstances that were also discussed, such as "I
> told the maintainer in person over a year ago..." which may in fact be
> true, but people forget things and make mistakes and now you have
> nothing to point at for proof of inactivity except a vague statement.
> Better to cover your rear and be able to point to a year old bug with a
> solution attached, and be like "look there is a bug and a fix and no one
> did jack squat."  Essentially you have a case for any sane developer to
> agree with.

dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was 
addressing the incorrect idea that it isnt a valid QA issue unless a user 
experiences it and complains via bugzilla
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Wednesday 01 March 2006 00:08, Mike Frysinger wrote:
>
> dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was
> addressing the incorrect idea that it isnt a valid QA issue unless a user
> experiences it and complains via bugzilla

I agree with this. I would however also like to ask QA to allow exceptions to 
policy for well-discussed reasons. Sometimes ugly hacks are needed, and as 
long as they are understood to be ugly, they must not be banned outright. I 
don't think it is a problem if those issues have LATER bugs on them blocking 
on some feature request bug. I can even agree with it that a feature request 
bug must be written for such a hack to be allowed.

With respect to webapp-config. I know it's ugly, I know it does perform jobs 
that should be performed by portage. Portage however doesn't, and 
webapp-config does provide valuable features for many users. As such, as long 
as portage does not offer the features that webapp-config provides, I am of 
the opinion that the webapp.eclass should be allowed to use "minimal" hacks 
to provide the webapp features. QA's role in this case is to ensure that no 
hacks are added, and to signal it when the hacks break.

Paul

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

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 18:11:57, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 17:02:11 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
> | On Tue, Feb 28, 2006 at 04:35:32PM +0000, Ciaran McCreesh wrote:
| >> Ebuilds can't override this either. Read on in the eclass and you'll
| >> notice that it checks that SLOT hasn't been changed to something
| >> sane.
> | 
> | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to
> | whatever the hell you want. But don't let my facts get in the way of
> | your nonsense.

> And it sticks out a nasty ewarn and says that the ebuild is probably
> broken.

> Again, you're dismissing QA issues as nonsense, and you wonder why I
> don't waste my time doing a full audit.

Ah, so this is the horrible and nasty ewarn?

<snip>
ewarn "This ebuild overrides the default SLOT behaviour for webapps"
ewarn "If this package installs files into the htdocs dir, this is"
ewarn "probably a bug in the ebuild."
</snip>

Sigh... what kind of QA issue is that? Go file bugs about those nasty QA
notices portage spits out every now and then as well, if you are so
concerned about warnings. Indeed, please don't waste your time and first of
all don't waste ours. Go audit whatever you want, but please keep this
off-list. Or maybe don't stare on the screen if ewarns scare you that much.
;)


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mike Frysinger]

On Tuesday 28 February 2006 13:00, Jakub Moc wrote:
> 28.2.2006, 18:11:57, Ciaran McCreesh wrote:
> > On Tue, 28 Feb 2006 17:02:11 +0000 Renat Lumpau <rl03@gentoo.org> wrote:
> > | On Tue, Feb 28, 2006 at 04:35:32PM +0000, Ciaran McCreesh wrote:
> | >> Ebuilds can't override this either. Read on in the eclass and you'll
> | >> notice that it checks that SLOT hasn't been changed to something
> | >> sane.
> > |
> > | Excepting that you can set WEBAPP_MANUAL_SLOT="yes" and set SLOT to
> > | whatever the hell you want. But don't let my facts get in the way of
> > | your nonsense.
> >
> > And it sticks out a nasty ewarn and says that the ebuild is probably
> > broken.
>
> <snip>
> ewarn "This ebuild overrides the default SLOT behaviour for webapps"
> ewarn "If this package installs files into the htdocs dir, this is"
> ewarn "probably a bug in the ebuild."
> </snip>
>
> Sigh... what kind of QA issue is that?

which part dont you understand ?  the user sets a variable and then is told 
that the package probably contains a bug ... seems pretty confusing to me
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 19:39:15, Mike Frysinger wrote:

>> <snip> ewarn "This ebuild overrides the default SLOT behaviour for
>> webapps" ewarn "If this package installs files into the htdocs dir, this
>> is" ewarn "probably a bug in the ebuild." </snip>
>>
>> Sigh... what kind of QA issue is that?

> which part dont you understand ?  the user sets a variable and then is told 
> that the package probably contains a bug ... seems pretty confusing to me
> -mike

rl03 already replied to that. I don't see any QA issues there, and if
someone from QA team does, then he probably has too much time to ponder over
the tree and invent issues where they don't exist. I don't see any point
"fixing" this, at least until FEATURES="mindreader" is implemented. Portage
QA notices may be equally confusing to the users, with this kind of logic,
yet they stay there - and number of people complaining about USE_EXPAND
notices is much higher than the number of people who complained about
confusing ewarn from webapps slot (exactly zero is far as I could find).

Once again, don't invent problems, please.

--

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen Bennett]

On Tue, 28 Feb 2006 20:27:01 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> Once again, don't invent problems, please.

Just because you don't see a problem doesn't mean it's not there.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [RFC] QA Team's role

[Stephen P. Becker]

>> which part dont you understand ?  the user sets a variable and then is told 
>> that the package probably contains a bug ... seems pretty confusing to me
>> -mike
> 
> rl03 already replied to that. I don't see any QA issues there, and if
> someone from QA team does, then he probably has too much time to ponder over
> the tree and invent issues where they don't exist. I don't see any point
> "fixing" this, at least until FEATURES="mindreader" is implemented. Portage
> QA notices may be equally confusing to the users, with this kind of logic,
> yet they stay there - and number of people complaining about USE_EXPAND
> notices is much higher than the number of people who complained about
> confusing ewarn from webapps slot (exactly zero is far as I could find).
> 
> Once again, don't invent problems, please.

Nobody is inventing problems Jakub.  Just because nobody has yet
complained does not mean that there is not a problem.  If you can't see
the QA issues, then you really need to stop commenting in this thread,
because there are a lot of people who know better.

Furthermore, you are playing right into the hands of He Whom I Will Not
Name, thus allowing yourself to be trolled into sounding like an idiot
in public.  You suffered from the same problem in the bbapm thread recently.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 05:11:58PM +0100, Patrick Lauer wrote:
> Ok, sorry for being dumb :-)
> What exactly is the issue there? I don't see the issue in setting SLOT
> depending on ... uhm ... some variable. Looks kinda logical at first
> glance, but I'm not aware of the issues it causes.

One issue here is that security revbumps are no longer effective in that the
vulnerable version remains installed and must be unmerged manually by the
sysadmin. I started a discussion about this very same issue yesterday on
-web-user and we hope to resolve it shortly.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 16:42:46, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc <jakub@gentoo.org> wrote:
> | If you can't do any better, then please apologize for your conduct
> | and false claims and shut up... TIA.

> Sure I can do better. But you didn't originally ask for better, you
> asked for anything. If better's what you're after:

>     SLOT="${PVR}"

Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
gst/gstreamer eclasses? Going to file QA bugs about them as well? And -
what's exactly the QA violation there, if you could enlighten us?

Maybe I could point you to
http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?

> Now, please apologise for insinuating that I don't have any real claims
> to make. I find it extremely offensive that you're questioning my
> technical ability.

No, I won't apologize, I don't see any reason to do it after all the baloney
you've shown here. I have to agree w/ rl03 that your benefits for this whole
project are net negative.


-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature ;)

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 17:22:57 +0100 Jakub Moc <jakub@gentoo.org> wrote:
| Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
| gst/gstreamer eclasses? Going to file QA bugs about them as well? And
| - what's exactly the QA violation there, if you could enlighten us?

You're misunderstanding the issue. See my explanation to Patrick.

I don't see the same kind of mistake in gst-plugins.eclass, assuming
you're referring to SLOT=${PV_MAJ_MIN} . And kernel-2 is a special
case, since it's not installing an actual program -- this one's been
explained in depth in the past on various lists. If you can point out
any genuine SLOT screwups that I've missed then I'll work to get those
fixed.

| Maybe I could point you to
| http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?

Uh... I know how slotting works. I wrote that page, remember?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 16:12:32 +0100 Patrick Lauer <patrick@gentoo.org>
wrote:
| Wow. That is ... impressive. After about two days of asking for any
| real bugs you are able to show a trivial syntax issue?
| 
| Please stop yelling "it si teh b0rk!" if you can't even list any
| serious issues, and stop being rude to other people.

As I already said, repeatedly, doing a full QA audit takes time. That
time can be better spent auditing things that will actually get fixed.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:

> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
> a complete list is something that takes a heck of a lot longer, and I
> have yet to be convinced that my time would not be better spent
> elsewhere.

Where is a coding style problem related to quality of code in general and 
assurance in particular? This is something that repoman might check for, 
and issue a warning. It has nothing to do with end-user quality. It even 
is no problem for developers trying to understand the ebuild. It is only 
a coding style violation, not a QA violation. Coding style is to present 
a uniform view to things, so things look proper. QA is about things being 
proper, not looking proper.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
| > Yes, it's an utterly trivial problem, but it is a QA violation.
| > Getting a complete list is something that takes a heck of a lot
| > longer, and I have yet to be convinced that my time would not be
| > better spent elsewhere.
| 
| Where is a coding style problem related to quality of code in general
| and assurance in particular?

It's more relevant than you might think. Screwing up layout like that
breaks various QA checking tools that assume that things are in the
standard format.

| QA is about things being proper, not looking proper.

Proper coding style is part of being proper.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


28.2.2006, 16:31:26, Ciaran McCreesh wrote:

> On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
| >> Yes, it's an utterly trivial problem, but it is a QA violation.
| >> Getting a complete list is something that takes a heck of a lot
| >> longer, and I have yet to be convinced that my time would not be
| >> better spent elsewhere.
> | 
> | Where is a coding style problem related to quality of code in general
> | and assurance in particular?

> It's more relevant than you might think. Screwing up layout like that
> breaks various QA checking tools that assume that things are in the
> standard format.

A tool that chokes on coding style (like tabs and whitespaces) should be
ifself fixed.


-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Danny van Dyk]

Am Mittwoch, 1. März 2006 08:21 schrieb Jakub Moc:
> 28.2.2006, 16:31:26, Ciaran McCreesh wrote:
> > On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
> > | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
> | >> Yes, it's an utterly trivial problem, but it is a QA violation.
> | >> Getting a complete list is something that takes a heck of a lot
> | >> longer, and I have yet to be convinced that my time would not be
> | >> better spent elsewhere.
> > |
> > | Where is a coding style problem related to quality of code in general
> > | and assurance in particular?
> >
> > It's more relevant than you might think. Screwing up layout like that
> > breaks various QA checking tools that assume that things are in the
> > standard format.
>
> A tool that chokes on coding style (like tabs and whitespaces) should be
> ifself fixed.
Hmm, you never used repoman, right? repoman checks for whitespace and tab 
oddities and warns you, if you want to commit them.

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] [RFC] QA Team's role

[Jakub Moc]

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


1.3.2006, 11:29:47, Danny van Dyk wrote:

>> > | Where is a coding style problem related to quality of code in general
>> > | and assurance in particular? > > It's more relevant than you might
>> think. Screwing up layout like that > breaks various QA checking tools
>> that assume that things are in the > standard format.
>>
>> A tool that chokes on coding style (like tabs and whitespaces) should be
>> ifself fixed.
> Hmm, you never used repoman, right? repoman checks for whitespace and tab 
> oddities and warns you, if you want to commit them.


Sure I did... that's not the breakage of a QA tool ciaranm has been talking
about, though. If some tool stops to work b/c of spacing/indenting issues,
then it's broken. Meanwhile, if you can't bear formating/whitespace issues,
then either fix it yourself or file a bug and wait until someone gets to it
or fixes it when next revbump/another bunch of more important fixes is due.

Expecting that someone will fix a cosmetic issue within five minutes from
the time when a bug is filed and ranting about it on #gentoo-qa and mailing
lists isn't useful but rather plain annoying.

-- 

jakub

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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 16:31, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote:
> | > Yes, it's an utterly trivial problem, but it is a QA violation.
> | > Getting a complete list is something that takes a heck of a lot
> | > longer, and I have yet to be convinced that my time would not be
> | > better spent elsewhere.
> |
> | Where is a coding style problem related to quality of code in general
> | and assurance in particular?
>
> It's more relevant than you might think. Screwing up layout like that
> breaks various QA checking tools that assume that things are in the
> standard format.

Then fix the damn tools. I've had runins with broken tools earlier. If you 
want the ebuild format to be stricter, well, make portage complain. 
Otherwise, fix up your parser.

> Proper coding style is part of being proper.

Coding style issues exist in degrees. White space issues such as these are of 
very low priority. Broken QA tools should not be an excuse to give them 
higher priority.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Renat Lumpau]

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

On Tue, Feb 28, 2006 at 02:52:46PM +0000, Ciaran McCreesh wrote:
> Yes, it's an utterly trivial problem, but it is a QA violation. Getting
> a complete list is something that takes a heck of a lot longer, and I
> have yet to be convinced that my time would not be better spent
> elsewhere.

So let me get this straight. 

You have been claiming that webapp-config is broken, to put it mildly, for quite
some time (at least several months). Yet as of now, you are unable to tell us
what exactly is wrong. When I asked you on IRC for feedback, you referred me to
a private conversation with Stuart, which is just as useless as the rest of your
comments. You have not filed a single bug or sent a single email to the
maintainers. Your only relevant QA point is a trivial style issue. 

Your blathering is insulting to the people who actually spend time trying to
improve webapp-config. No, it's not perfect. But we want to make it better, and
we have asked you for feedback and got none.

You, ciaranm, create measurable deadweight loss. Instead of doing productive
work, I waste my time replying to your nonsense. I am fed up and will be taking
the issue to devrel.

-- 
Renat Lumpau       all things web-apps
C6A838DA           04AF B5EE 17CB 1000 DDA5  D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.

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

Re: [gentoo-dev] [RFC] QA Team's role

[Stuart Herbert]

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

On Mon, 2006-02-27 at 20:37 +0000, Ciaran McCreesh wrote:
> Then please start with bug 120088. Once that one's fixed we'll go from
> there.

That bug has nothing to do with webapp-config.  That bug is for PHP.
Could you file one that is, please?

Many thanks,
Stu
-- 
Stuart Herbert                                         stuart@gentoo.org
Gentoo Developer                                  http://www.gentoo.org/
                                          http://blog.stuartherbert.com/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Monday 27 February 2006 21:37, Ciaran McCreesh wrote:
> | You know where bugzilla is.  You know how to contact any of the
> | webapp-config maintainers via email, or via IRC.  We're ready to
> | listen to your input, and to work with you (or anyone else) on fixing
> | any genuine problems that webapp-config has.  The more feedback we
> | get, the better we can make this package for everyone's enjoyment.
>
> Then please start with bug 120088. Once that one's fixed we'll go from
> there.

While that bug explains your issues with the webapp people in general and 
stuart in particular it is not related to webapp-config at all.

Looking at that bug, and the issues discussed in this thread I do get to 
the point where I feel that instead of buggering people about packages, 
it would perhaps be better to get those features into portage whose 
absense causes the problems. The quality of the distribution would be 
better suited with a portage that supports USE-flag dependencies, 
dependencies between useflags in a package, sourcefile renaming / 
DIST_PREFIX, etc.

Once that is supported, I'm also sure that those people involved will be 
more than happy to fix their ebuilds to use those features. I do agree 
with them though that the distribution should not be held back by missing 
features in portage. Especially since those features have been missing 
(recognized as such) for ages.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Once that is supported, I'm also sure that those people involved will
| be more than happy to fix their ebuilds to use those features. I do
| agree with them though that the distribution should not be held back
| by missing features in portage. Especially since those features have
| been missing (recognized as such) for ages.

So until then, it's perfectly OK to screw over our users and fellow
developers by committing any arbitrary mess to the tree and claiming
that it's alright because Portage doesn't offer a perfect alternative?

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Tuesday 28 February 2006 15:47, Ciaran McCreesh wrote:
> On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | Once that is supported, I'm also sure that those people involved will
> | be more than happy to fix their ebuilds to use those features. I do
> | agree with them though that the distribution should not be held back
> | by missing features in portage. Especially since those features have
> | been missing (recognized as such) for ages.
>
> So until then, it's perfectly OK to screw over our users and fellow
> developers by committing any arbitrary mess to the tree and claiming
> that it's alright because Portage doesn't offer a perfect alternative?

No, not in an arbitrary way. Those fixes should be discussed, and the path 
of least problems chosen. Waiting on portage to catch on however has 
shown to be a dead end. One of the reasons that webapp-config was 
developed is exactly because of the fact that portage does not offer 
certain features (although I don't know whether portage should offer 
these).

What I mean is that if portage is a limiting factor, we should try to find 
a solution that allows incorporation of the package or feature instead of 
not having it. Doing so is only alright when it has been properly 
discussed. It is not alright to just introduce mess. There is indeed no 
strict line between the two. That's where QA comes in. To make the 
judgement.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Grant Goodyear]

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

Mark Loeser wrote:
> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.

My suspicion is that the more common problem is going to be inaccessible
developers, rather than uncooperative ones.  Certainly, if a maintainer
cannot be contacted, then I would prefer that QA fix the problem rather
than let it languish.  So, yes, I do believe that QA needs the ability
to go in and change any package that is broken.  (It's worth noting,
though, that every dev w/ tree access already has that ability, and the
only real issue is the amount of pain that will be inflicted on a dev
who changes packages both without permission and without skill.  Very
few devs will complain about somebody improving packages even without
permission as long as the improvement is done well.)

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

I'm somewhat ambivalent on this one on a couple of points, and the
nxserver case (bug #123926) hits both of them.  The first is that it
seems to me that in a case like this one, where the package involved is
a minor one that (I think) is not a dependency of any other packages,
the most that QA should do is hard mask the package w/ a clear note
pointing to the bug report, until some sort of resolution is achieved.
Removing the package would seem to be a bit much.  The second is the
fact that I don't really like seeing policy bounced to the council
unless absolutely necessary.  Just as was seen here, a discussion on
-dev might well lead to a reasonable compromise.  If it doesn't, then
the council can get involved.

Of course, that leaves the question of who decides on the severity of a
QA violation?  Well, I would suggest that the QA team does, at the risk
of getting publicly smacked down if they choose poorly.

-g2boojum-



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] [RFC] QA Team's role

[Ciaran McCreesh]

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

On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| Of course, that leaves the question of who decides on the severity of
| a QA violation?

All this talk of severity, and no talk of "ease of detection" or "ease
of fixing"...

Allow me to explain. There are certain not particularly high impact
issues that can very easily be detected, and with 100% reliability, by
The Thing About Which We Do Not Talk. Any individual one of these
doesn't look like such a big deal, but when we're talking a couple of
hundred instances, all of which can easily be fixed in less overall
time than it would take to even detect one instance of a particular
severe problem, it's most definitely worth concentrating on the 'easy'
issue.

-- 
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] [RFC] QA Team's role

[Paul de Vrieze]

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

On Monday 27 February 2006 19:19, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear <g2boojum@gentoo.org>
>
> wrote:
> | Of course, that leaves the question of who decides on the severity of
> | a QA violation?
>
> All this talk of severity, and no talk of "ease of detection" or "ease
> of fixing"...
>
> Allow me to explain. There are certain not particularly high impact
> issues that can very easily be detected, and with 100% reliability, by
> The Thing About Which We Do Not Talk. Any individual one of these
> doesn't look like such a big deal, but when we're talking a couple of
> hundred instances, all of which can easily be fixed in less overall
> time than it would take to even detect one instance of a particular
> severe problem, it's most definitely worth concentrating on the 'easy'
> issue.

I understand this point, but by your own admission, they are not 
particularly high impact. In the case at hand, the particular issue does 
however conflict with other goals. What I think would be reasonable is to 
expect that you are not going to be able to solve 100% of the "easilly 
detectable" issues. So, I think that while you continue to run the tests 
on these packages, you maintain a list of exceptions, including the 
reason for them being exceptions. Besides, work on finding solutions to 
the problems behind it. But do not choose the greater evil (removing or 
blocking a package) before the lesser evil (keeping a package with 
well-documented issues).

In this respect I would like to propose that each package that has these 
issues related to missing portage features, ensures that a related bug is 
created for portage requesting that feature/a solution for the 
fundamental problem. This bug should be marked as blocker for the package 
related bugs in this respect. That way we can keep account of which 
features in portage are needed for which packages.

Paul

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

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

Re: [gentoo-dev] [RFC] QA Team's role

[Mark Loeser]

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

Grant Goodyear <g2boojum@gentoo.org> said:
> Mark Loeser wrote:
> > * In case of emergency, or if package maintainers refuse to cooperate,
> >   the QA team may take action themselves to fix the problem.
> 
> My suspicion is that the more common problem is going to be inaccessible
> developers, rather than uncooperative ones.  Certainly, if a maintainer
> cannot be contacted, then I would prefer that QA fix the problem rather
> than let it languish.  So, yes, I do believe that QA needs the ability
> to go in and change any package that is broken.

We hope that it is never the case when someone refuses to cooperate, but
it is a possible situation we may likely have to deal with at some
point.

> > * 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.
> 
> I'm somewhat ambivalent on this one on a couple of points, and the
> nxserver case (bug #123926) hits both of them.  The first is that it
> seems to me that in a case like this one, where the package involved is
> a minor one that (I think) is not a dependency of any other packages,
> the most that QA should do is hard mask the package w/ a clear note
> pointing to the bug report, until some sort of resolution is achieved.
> Removing the package would seem to be a bit much.  The second is the
> fact that I don't really like seeing policy bounced to the council
> unless absolutely necessary.  Just as was seen here, a discussion on
> -dev might well lead to a reasonable compromise.  If it doesn't, then
> the council can get involved.

I agree.  With regards to the nxserver case, we said the package should
be removed if we could not come to a resolution.  We never said that we
were going to outright remove the package immediately.

It is not our goal, nor our intent, to go around and remove people's packages
from the tree.  This entire bullet point is really a worst case scenario when
all else breaks down.  The same with if there is a disagreement within the
majority of the QA team.  I don't foresee this occuring often, if at
all, but I felt it was important enough to address.


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