[gentoo-dev] QA Roles v2

[gentoo-dev] QA Roles v2

[Mark Loeser]

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

Here is my updated version after some feedback from people:

* The QA team's purpose is to provide cross-team assistance in keeping
  the tree in a good state. This is done primarily by finding and pointing
  out issues to maintainers and, where necessary, taking direct action.
* In case of emergency, or if package maintainers refuse to cooperate,
  the QA team may take action themselves to fix the problem.
* The QA team 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 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" with
  explanations as to why they are problems, and how to fix the problem.  The
  list is not meant by any means to be a comprehensive document, but rather a
  dynamic document that will be updated as new problems are discovered.  The QA
  team will also do their best to ensure all developer tools are in line with
  the current QA standards.


I guess this won't be reviewed by the council for another month, but I'd
like to get all of the debate out of the way now.
Please lets keep the discussion on topic and constructive.

Thanks,

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

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

Re: [gentoo-dev] QA Roles v2

[Alec Warner]

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

Mark Loeser wrote:
> Here is my updated version after some feedback from people:
> * In the case of disagreement on policy among QA members, the majority
>   of established QA members must agree with the action.

What is an "Established QA member"?

> 
> 
> I guess this won't be reviewed by the council for another month, but I'd
> like to get all of the debate out of the way now.
> Please lets keep the discussion on topic and constructive.
> 
> Thanks,
> 

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

Re: [gentoo-dev] QA Roles v2

[Mark Loeser]

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

Alec Warner <antarus@gentoo.org> said:
> Mark Loeser wrote:
> > Here is my updated version after some feedback from people:
> > * In the case of disagreement on policy among QA members, the majority
> >   of established QA members must agree with the action.
> 
> What is an "Established QA member"?

Listed on the QA website and approved by the current QA lead.

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

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

Re: [gentoo-dev] QA Roles v2

[Daniel Ostrow]

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

Mark Loeser <halcy0n@gentoo.org> said:
> Here is my updated version after some feedback from people:
> 
> * The QA team's purpose is to provide cross-team assistance in keeping
>   the tree in a good state. This is done primarily by finding and pointing
>   out issues to maintainers and, where necessary, taking direct action.
> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.
> * The QA team 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 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" with
>   explanations as to why they are problems, and how to fix the problem.  The
>   list is not meant by any means to be a comprehensive document, but rather a
>   dynamic document that will be updated as new problems are discovered.  The QA
>   team will also do their best to ensure all developer tools are in line with
>   the current QA standards.

I'm happy enough to send the above to the Council. I think the only issue 
will be with bullet point 4. I know that the QA team as a whole like the 
wording this way leaving the onus on the package maintainer to prove the 
merrits of their package rather then having the onus on the QA team to 
prove fault. Personally I also like the wording this way (in most cases).

In the cases where a clear technical solution presents itself to the
problems the package presents that does not change the intended behavior
(unless said behavior is what is broken) and the maintainer still
refuses to apply the neceesary changes I think that the QA team should
be cleared to make them. This is all under the understanding that the
maintainer has the right to appeal in order to revert said changes.

The tougher call comes when the severity of a QA violation comes into
question. If the QA team presents a problem to a maintainer that they
believe is severe enough to warrant a package's removal and no technical
solution has presented itself to either the QA team or the maintainer to
work around the issue I think that the QA team should have the right to
hard mask the package pending an appeal. In such cases I'd almost say
that an appeal should be automatically triggered so that a decision
about the true severity of the QA issue can be ironed out. I certainly 
hope that there will be few enough of these that the council will not end
up bogged down in policy decisions and QA conflict mediation.

The above also has to be done on a case by case basis, if hardmasking a
package would cause wide tree breakage itself then another choice has to
be made.

Concurrent with the above what I'd like to see is the QA team showing a
willingness to help maintainers find workarounds to particualarly sticky
violations. I'm not saying that they should have to learn the packages
inside out or that they should not be allowed to act until a solution is
found just that they should put a certain level of effort into helping
find (or concoct) a solution. This is not to say that they are not doing
this now, however, as has been said in the prior incarnation of this
thread I also believe that the stickier problems are likely to arise
because the maintainer in question did not see a better solution, so
part of QA's roll should be to help educate the developer community.

All in all the one thing I'd like to aviod is QA bugs getting closed as
invalid (one of the events that lead up to this thread). I know there 
is a sense of territory with the ebuilds one maintains, but I'd really 
like to see an effort made to allow the QA team to explain themselves.
If a bug gets opened up on one of your pacakges and it is unclear to you
why something is a QA issue either comment on the bug asking th QA team
to explain (and I consider pointing someone to existing offial documentation
so long as it contains an explanation of what is wrong and how to
generally fix such issues to be a valid explanation) or ping them
online.

I really hope that noone thinks the QA team is out to get them. They are 
here to make the experiance better for all of us as a whole (even if
that sometimes means that the experiance for a particular package or two
needs to be a little worse). Tree QA is something that we have never had
before, at least not really (don't mean to trivialize the work that
Mr_Bones_ does). It is something that I believe we need so lets all help
with the transition instead of fighting it.

Thanks,

-- 
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
dostrow@gentoo.org

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

Re: [gentoo-dev] QA Roles v2

[Mark Loeser]

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

Daniel Ostrow <dostrow@gentoo.org> said:
> The above also has to be done on a case by case basis, if hardmasking a
> package would cause wide tree breakage itself then another choice has to
> be made.

I agree.  We aren't here to make a situation even worse, and we
acknowledge that we won't always get the perfect solution right away and
that flexibility is required.

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

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

Re: [gentoo-dev] QA Roles v2

[Alin Nastac]

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

[deleted]

All seems fair enough, but please fix portage qa issues before this
policy is applied (see bug http://bugs.gentoo.org/show_bug.cgi?id=123733).



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

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

Hi Mark,

This draft seems to be effectively the same as the last one.

On 3/2/06, Mark Loeser <halcy0n@gentoo.org> wrote:
> * The QA team's purpose is to provide cross-team assistance in keeping
>  the tree in a good state. This is done primarily by finding and pointing
>  out issues to maintainers and, where necessary, taking direct action.

Same as original version.

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

Same as original version.

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

Same as original version.

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

Same as original version.

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

Same as original version.

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

Same as original version.

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

Same as original version.

> * The QA team will maintain a list of current "QA Standards" with
>  explanations as to why they are problems, and how to fix the problem.  The
>  list is not meant by any means to be a comprehensive document, but rather a
>  dynamic document that will be updated as new problems are discovered.  The QA
>  team will also do their best to ensure all developer tools are in line with
>  the current QA standards.

The bit about "explanations as to why they are prblems, and how to fix
the problem" is new, as is the statement to ensure that all developer
tools are in line with the current QA standards, but otherwise this is
also the same.

I'm sorry, but personally I don't see how this draft is substantially
different from the one posted originally.  It looks like you've
decided not to address the points I raised about your original draft:

* There's nothing in this policy about end users.  If this QA team is
not *focused* on delivering benefit to end users, then (as has
happened this week) it becomes a self-serving team, focused instead on
what can only be described as a destructive path.  No-one benefits
from that, no-one at all.

* The QA team is asking for more than it needs to perform its role. 
The UNIX principle is that of "least privilege".  Donnie's already
pointed out that FreeBSD is able to conduct effective QA without the
extra power that the QA team is continuing to ask for.

* There is no proposal for a process to formulate, and gain wide
approval for new QA standards.  This week, there's been an example of
the QA team documenting a QA standard *after* a bug was raised about a
QA violation ... and then that document being used as if that
particular QA standard had always been in the document.

Mistakes will always be made by all developers, and good QA is
essential to Gentoo's future.  We need a good QA team for Gentoo.  Not
having a QA team is, in my eyes, not an option at all.

But, as this week has shown, QA members are also developers (and
human), and are just as capable of making mistakes as anyone else.

We need a quality assurance team that conducts all its activities in a
quality manner.  I'm not just talking about personal behaviour, or of
any one individual.  The way *everything* is done must be in a quality
manner.  That should mean a high quality process for creating QA
standards, having them approved, and making sure developers know what
changes are coming and when.  That should mean high quality automated
tools that cope with the real world, not some ivory tower that has no
real pay-off for users.  It should mean an interpretation and
application of QA standards that is focused on how it improves matters
for real users - and not a "tick in a box" QA approach.  It should
mean a team of educators, not a team out to bully with the mandate to
do so.

In twelve years of being a professional software engineer, I've never
seen a successful QA team that didn't match that description above.

Mark, in the discussions about the QA policy, your fallback
justification always seems to be "Trust us".  I think this week's
events have put a big dent in the credibility of that argument, if not
holed it below the water line.  If the QA team followed processes
similar to what I've described above, I believe that this week's
events wouldn't have happened.  What started off as a worthy piece of
QA work, which I'm sure has fixed many real problems for users,
degenerated into something altogether unpleasant and unnecessary for
all involved.  We've all gotten a week older and a week greyer out of
this.  Have we fixed any real problems that stop our users installing
and running Gentoo?  No, we haven't.  I hope we can all (and I include
myself in that) learn something from this to prevent a repeat.

I call for Mark's proposed policy to be rejected as it stands.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 03:53, Mark Loeser wrote:
> Here is my updated version after some feedback from people:
>
> * The QA team's purpose is to provide cross-team assistance in keeping
>   the tree in a good state. This is done primarily by finding and
>   pointing out issues to maintainers and, where necessary, taking direct
>   action.
> * In case of emergency, or if package maintainers refuse to 
>   cooperate, the QA team may take action themselves to fix the problem.
> * The QA team 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 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" with
>   explanations as to why they are problems, and how to fix the problem.
>   The list is not meant by any means to be a comprehensive document, but
>   rather a dynamic document that will be updated as new problems are
>   discovered.  The QA team will also do their best to ensure all
>   developer tools are in line with the current QA standards.
>

I'd like to add the following two points:
* Just because breaking policy breaks a QA tool, but is guaranteed to
  never break itself (formatting policy, like space vs. tab etc.) does not
  increase the severity of the breakage.
* Before any enforcement is possible, QA must establish a well supported
  (debated on dev-) exception policy. While it were nice if exceptions are
  not needed, reality is that they can not be avoided. Therefore there
  must be an exception policy.

  An exception does not mean there is no violation (so appeal is
  pointless). An exception means that the violation is needed because it
  offers important features for the user, and the benefits outweigh the
  costs. At the same time that an exception is allowed, steps should be
  undertaken to get a structural solution to the problem. QA is
  responsible for ensuring that the maintainer(s) of the package in
  question keep on doing so.

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] QA Roles v2

[Patrick Lauer]

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

On Thu, 2006-03-02 at 09:01 +0000, Stuart Herbert wrote:
[snip]
> * There's nothing in this policy about end users.  If this QA team is
> not *focused* on delivering benefit to end users, then (as has
> happened this week) it becomes a self-serving team, focused instead on
> what can only be described as a destructive path.  No-one benefits
> from that, no-one at all.
> 
> * The QA team is asking for more than it needs to perform its role. 
> The UNIX principle is that of "least privilege".  Donnie's already
> pointed out that FreeBSD is able to conduct effective QA without the
> extra power that the QA team is continuing to ask for.
So I see two scenarios for that:
- A QA team with a purely advisory function, helping with communication.
pro: no big policy changes etc.
con: teethless QA may get ignored

- A QA team with limited executive power, fixing bugs as they are found
pro: fast turnaround times on bugs
con: resistance from developers

The second approach needs to be carefully implemented, people need to
have trust in the QA team to empower them.

> * There is no proposal for a process to formulate, and gain wide
> approval for new QA standards.  This week, there's been an example of
> the QA team documenting a QA standard *after* a bug was raised about a
> QA violation ... and then that document being used as if that
> particular QA standard had always been in the document.
Communications issue. This thread should help fix the policies for that I hope.

> Mistakes will always be made by all developers, and good QA is
> essential to Gentoo's future.  We need a good QA team for Gentoo.  Not
> having a QA team is, in my eyes, not an option at all.
Fully agreed.
> But, as this week has shown, QA members are also developers (and
> human), and are just as capable of making mistakes as anyone else.
Obviously :-)
> We need a quality assurance team that conducts all its activities in a
> quality manner.  I'm not just talking about personal behaviour, or of
> any one individual.  The way *everything* is done must be in a quality
> manner.  That should mean a high quality process for creating QA
> standards, having them approved, and making sure developers know what
> changes are coming and when.  That should mean high quality automated
> tools that cope with the real world, not some ivory tower that has no
> real pay-off for users.  It should mean an interpretation and
> application of QA standards that is focused on how it improves matters
> for real users - and not a "tick in a box" QA approach.  It should
> mean a team of educators, not a team out to bully with the mandate to
> do so.
That sounds like a mission statement and should be part of QA policy

> In twelve years of being a professional software engineer, I've never
> seen a successful QA team that didn't match that description above.
> 
> Mark, in the discussions about the QA policy, your fallback
> justification always seems to be "Trust us".  I think this week's
> events have put a big dent in the credibility of that argument, if not
> holed it below the water line.  If the QA team followed processes
> similar to what I've described above, I believe that this week's
> events wouldn't have happened.  What started off as a worthy piece of
> QA work, which I'm sure has fixed many real problems for users,
> degenerated into something altogether unpleasant and unnecessary for
> all involved.  We've all gotten a week older and a week greyer out of
> this.  Have we fixed any real problems that stop our users installing
> and running Gentoo?  No, we haven't.  I hope we can all (and I include
> myself in that) learn something from this to prevent a repeat.
> 
> I call for Mark's proposed policy to be rejected as it stands.
I'd like to see it extended with the ideas shown in this thread. Also
the QA team should consider ways of getting higher acceptance - I
suggest that a general vote should be done, that's about as democratic
as we can get and noone can weasel put after that (although I'm open for
other processes to give the QA team support)

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] QA Roles v2

[Mark Loeser]

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

Paul de Vrieze <pauldv@gentoo.org> said:
> * Just because breaking policy breaks a QA tool, but is guaranteed to
>   never break itself (formatting policy, like space vs. tab etc.) does not
>   increase the severity of the breakage.

I had hoped something like this would have just been understood to not
be too severe, since it doesn't really break anything but coding standards.

> * Before any enforcement is possible, QA must establish a well supported
>   (debated on dev-) exception policy. While it were nice if exceptions are
>   not needed, reality is that they can not be avoided. Therefore there
>   must be an exception policy.

I'm not sure what you mean here.  You mean for each instance?  In
general?  In general can be difficult since it leaves a lot of things up
for interpretation.  For each instance, 99% of the time an acceptable
interim solution should be able to be achieved between the QA team and
the maintainer.  In situations where we can't figure out how to best
address the situation, opening the discussion up to -dev may help, but
in the end it should come down to an agreement between the maintainer
and the team.

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

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

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 14:09, Mark Loeser wrote:
> Paul de Vrieze <pauldv@gentoo.org> said:
> > * Just because breaking policy breaks a QA tool, but is guaranteed to
> >   never break itself (formatting policy, like space vs. tab etc.)
> > does not increase the severity of the breakage.
>
> I had hoped something like this would have just been understood to not
> be too severe, since it doesn't really break anything but coding
> standards.
>
> > * Before any enforcement is possible, QA must establish a well
> > supported (debated on dev-) exception policy. While it were nice if
> > exceptions are not needed, reality is that they can not be avoided.
> > Therefore there must be an exception policy.
>
> I'm not sure what you mean here.  You mean for each instance?  In
> general?  In general can be difficult since it leaves a lot of things
> up for interpretation.  For each instance, 99% of the time an
> acceptable interim solution should be able to be achieved between the
> QA team and the maintainer.  In situations where we can't figure out
> how to best address the situation, opening the discussion up to -dev
> may help, but in the end it should come down to an agreement between
> the maintainer and the team.

The policy should be general. It could be something like "Developer and QA 
discuss the exception and the solution to be used. If they do not agree 
the council.... . In any case when an exception is made, appropriate bugs 
are created, including a bug to request a feature that makes the 
exception unneeded. When the requested feature is available and stable, 
the exception becomes invalid and the feature must be used instead."

My idea is that QA can not enforce controversial things before such a 
policy exists. Otherwise exceptions stay only a theoretical possibility, 
and arguments continue.

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] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| * Just because breaking policy breaks a QA tool, but is guaranteed to
|   never break itself (formatting policy, like space vs. tab etc.)
| does not increase the severity of the breakage.

I'd argue against this one. See, it's possible to deliberately
circumvent some of repoman's checks by doing weird whitespace and syntax
trickery. There's also no way to fix repoman short of writing a fully
functional bash parsing tool -- which is complicated enough that even
bash doesn't have one that works in some releases...

-- 
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] QA Roles v2

[Lance Albertson]

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

Ciaran McCreesh wrote:
> On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | * Just because breaking policy breaks a QA tool, but is guaranteed to
> |   never break itself (formatting policy, like space vs. tab etc.)
> | does not increase the severity of the breakage.
> 
> I'd argue against this one. See, it's possible to deliberately
> circumvent some of repoman's checks by doing weird whitespace and syntax
> trickery. There's also no way to fix repoman short of writing a fully
> functional bash parsing tool -- which is complicated enough that even
> bash doesn't have one that works in some releases...

QA shouldn't have to depend on the tools you use. The final say should
be the human interaction. If doing weird white spaces breaks the tool,
but really isn't a QA issue outside of neatness, it shouldn't be waving
red flags. Yes, its probably something that should be fixed, but it
shouldn't be a critical one just because the tool is broken and can't
handle the weirdness.

-- 
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] QA Roles v2

[Mark Loeser]

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

Lance Albertson <ramereth@gentoo.org> said:
> Ciaran McCreesh wrote:
> > I'd argue against this one. See, it's possible to deliberately
> > circumvent some of repoman's checks by doing weird whitespace and syntax
> > trickery. There's also no way to fix repoman short of writing a fully
> > functional bash parsing tool -- which is complicated enough that even
> > bash doesn't have one that works in some releases...
> 
> QA shouldn't have to depend on the tools you use. The final say should
> be the human interaction. If doing weird white spaces breaks the tool,
> but really isn't a QA issue outside of neatness, it shouldn't be waving
> red flags. Yes, its probably something that should be fixed, but it
> shouldn't be a critical one just because the tool is broken and can't
> handle the weirdness.

I agree.  Coding standards, while they may qualify as violations, are
not as severe, but are definitely things we would like to see fixed.
They are there to make readability across ebuilds easier since
everything will be formatted the same way for a developer to see.

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

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

Re: [gentoo-dev] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| QA shouldn't have to depend on the tools you use.

Sure. However, the tree is far too large to check manually for many
things. If we were to do the Sekrit Tool's IUSE check manually, for
example, we'd still be in app-something, and would have missed many of
the screwups.

| The final say should
| be the human interaction. If doing weird white spaces breaks the tool,
| but really isn't a QA issue outside of neatness, it shouldn't be
| waving red flags.

The problem is, without fixing the syntax weirdness it's not possible
to tell whether red flags should be being waved for something else.

| Yes, its probably something that should be fixed,
| but it shouldn't be a critical one just because the tool is broken
| and can't handle the weirdness.

That's the thing... Doing static analysis on bash code is ludicrously
difficult. If you don't believe me, try writing a tool that will figure
out all ebuilds that have a redundant src_compile.

It's a heck of a lot easier to do if you assume that developers will
use sane syntax. Where developers don't use sane syntax, the only way
to deal with it is to check it by hand. We don't have enough developers
to do that.

-- 
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] QA Roles v2

[Simon Stelling]

Ciaran McCreesh wrote:
> On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
> <ramereth@gentoo.org> wrote:
> | QA shouldn't have to depend on the tools you use.
> 
> Sure. However, the tree is far too large to check manually for many
> things. If we were to do the Sekrit Tool's IUSE check manually, for
> example, we'd still be in app-something, and would have missed many of
> the screwups.

Then fix the tool. I find it somehow ironic that a member of the QA team is
trying to force a 'work-around' just to avoid fixing the source of the problem.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Member
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling <blubb@gentoo.org>
wrote:
| Ciaran McCreesh wrote:
| > On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
| > <ramereth@gentoo.org> wrote:
| > | QA shouldn't have to depend on the tools you use.
| > 
| > Sure. However, the tree is far too large to check manually for many
| > things. If we were to do the Sekrit Tool's IUSE check manually, for
| > example, we'd still be in app-something, and would have missed many
| > of the screwups.
| 
| Then fix the tool. I find it somehow ironic that a member of the QA
| team is trying to force a 'work-around' just to avoid fixing the
| source of the problem.

How? Writing a full bash parser is extremely difficult and would be a
complete waste of time. It's far saner to assume sane syntax, and just
bail out when crazy stuff is encountered. Sane syntax is not a work
around -- it's a basic thing that should be expected from any source
file that has to be worked on by more than one person, or even one
person over a long period of time.

Syntax is already, at least to a certain extent, mandated by policy.
The question at hand is whether violations of this policy should be
effectively ignored, or whether they should be treated as potentially
severe simply because they mask other problems.

-- 
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] QA Roles v2

[Mark Loeser]

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

Ciaran McCreesh <ciaranm@gentoo.org> said:
> It's a heck of a lot easier to do if you assume that developers will
> use sane syntax. Where developers don't use sane syntax, the only way
> to deal with it is to check it by hand. We don't have enough developers
> to do that.

I don't see where anyone is saying that we shouldn't fix things to
adhere to coding standards.  We are just saying it is not a, "OMG you
broke it!" problem.  It is about appropriate responses to the problems
we encounter.

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

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

Re: [gentoo-dev] QA Roles v2

[Lance Albertson]

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

Ciaran McCreesh wrote:
> On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling <blubb@gentoo.org>
> wrote:
> | Ciaran McCreesh wrote:
> | > On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson
> | > <ramereth@gentoo.org> wrote:
> | > | QA shouldn't have to depend on the tools you use.
> | > 
> | > Sure. However, the tree is far too large to check manually for many
> | > things. If we were to do the Sekrit Tool's IUSE check manually, for
> | > example, we'd still be in app-something, and would have missed many
> | > of the screwups.
> | 
> | Then fix the tool. I find it somehow ironic that a member of the QA
> | team is trying to force a 'work-around' just to avoid fixing the
> | source of the problem.
> 
> How? Writing a full bash parser is extremely difficult and would be a
> complete waste of time. It's far saner to assume sane syntax, and just
> bail out when crazy stuff is encountered. Sane syntax is not a work
> around -- it's a basic thing that should be expected from any source
> file that has to be worked on by more than one person, or even one
> person over a long period of time.

It should be a basic thing to expect the QA tool knows how to bail out
correctly and resume looking for more important critical issues. QA
should not revolve around the tools you use. Technical difficulties in
the QA tool dealing with weird syntax's should not provoke a red flag on
a particular package. Yes, those weirdness issues should be fixed, but
the tool should not hinder the overall outcome of the QA process.

So what if it takes too much time to fix it, then just have it ignore
that package (and mark it to be viewed later by hand) and move on to the
next package.

-- 
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] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 02 Mar 2006 13:15:48 -0600 Lance Albertson
<ramereth@gentoo.org> wrote:
| It should be a basic thing to expect the QA tool knows how to bail out
| correctly and resume looking for more important critical issues.

Sure. But what if more important critical issues are being masked by
weird syntax?

| QA should not revolve around the tools you use.

There are not enough people to check the entire tree by hand. Even if
there were, manual checks are extremely tricky to do properly. Humans
are extremely bad at picking out errors like transposed letters or a
missed captial in a package name.

The tools are extremely important. Without them most QA mistakes will
go unnoticed until they cause breakage.

| Technical difficulties in the QA tool dealing with weird syntax's
| should not provoke a red flag on a particular package.

Not flagging a weird package can lead to breakage being missed.

| So what if it takes too much time to fix it, then just have it ignore
| that package (and mark it to be viewed later by hand) and move on to
| the next package.

Doable, but not reliably, only for so long as it's a very small number
of affected packages.

Here's why manual checks don't scale. Some of the following *DEPEND
specifications are broken. Some are not. Without using a tool, pick out
which ones are broken. Then say how long it took you to do it. For
comparison, at least one QA tool can do these in well under a hundredth
of a second.

RDEPEND="|| ( ( x11-libs/libXext x11-libs/libX11 x11-libs/libXau x11-libs/libXdmcp x11-libs/libXkbui ) virtual/x11 )"

DEPEND="~app-editors/vim-core-7.0_alpha20060228 || ( x11-libs/libXext
virtual/x11 ) !aqua? ( gtk? ( >=x11-libs/gtk+-2.6 virtual/xft gnome?
( >=gnome-base/libgnomeui-2.6* ) ) !gtk? ( motif?
( x11-libs/openmotif ) !motif? ( nextaw? ( x11-libs/neXtaw ) !nextaw?
( || ( x11-libs/libXaw virtual/x11 ) ) ) ) ) !bootstrap?
( sys-devel/patch ) cscope? ( dev-util/cscope ) gpm?
( >=sys-libs/gpm-1.19.3 ) perl? ( dev-lang/perl ) python?
( dev-lang/python ) acl? ( sys-apps/acl ) ruby? ( virtual/ruby )
mzscheme? ( dev-lisp/mzscheme ) netbeans? ( dev-util/netbeans )
=sys-apps/sed-4 sys-devel/autoconf dev-util/ctags 
>=sys-libs/ncurses-5.2-r2"

RDEPEND=" ( !gnome-base/gnome-core >=dev-libs/glib-2.8.6
>=x11-libs/gtk+-2.8.11 >=dev-libs/atk-1.10.3 >=x11-libs/pango-1.10.3 >=dev-libs/libxml2-2.6.23 >=dev-libs/libxslt-1.1.15 >=media-libs/audiofile-0.2.6-r1 >=media-sound/esound-0.2.36 >=x11-libs/libxklavier-2 >=media-libs/libart_lgpl-2.3.17 >=dev-libs/libIDL-0.8.6 >=gnome-base/orbit-2.12.5 >=x11-libs/libwnck-2.12.3 >=x11-wm/metacity-2.12.3 >=gnome-base/gnome-keyring-0.4.6 >=gnome-extra/gnome-keyring-manager-2.12 >=gnome-base/gnome-vfs-2.12.2 >=gnome-base/gnome-mime-data-2.4.2 >=gnome-base/gconf-2.12.1 >=net-libs/libsoup-2.2.7 >=gnome-base/libbonobo-2.10.1 >=gnome-base/libbonoboui-2.10.1 >=gnome-base/libgnome-2.12.0.1 >=gnome-base/libgnomeui-2.12 >=gnome-base/libgnomecanvas-2.12 >=gnome-base/libglade-2.5.1 >=gnome-extra/bug-buddy-2.12.1 >=gnome-base/control-center-2.12.3 >=gnome-base/eel-2.12.2 >=gnome-base/nautilus-2.12.2 =media-libs/gstreamer-0.8* =media-libs/gst-plugins-0.8* >=gnome-extra/gnome-media-2.12 >=media-sound/sound-juicer-2.12.3 >=media-video/totem-1.2.1 >=media-gfx/eog-2.12.3 >=www-client/epiphany-1.8.4.1 >=app-arch/file-roller-2.12.3 >=gnome-extra/gcalctool-5.6.31 >=gnome-extra/gconf-editor-2.12.1 >=gnome-base/gdm-2.8.0.7 >=x11-libs/gtksourceview-1.4.2 >=app-editors/gedit-2.12.1 >=app-text/evince-0.4.0 >=gnome-base/gnome-desktop-2.12.3 >=gnome-base/gnome-session-2.12.0 >=gnome-base/gnome-applets-2.12.3 >=gnome-base/gnome-panel-2.12.3 >=gnome-base/gnome-menus-2.12.0 >=x11-themes/gnome-icon-theme-2.12.1 >=x11-themes/gnome-themes-2.12.3 >=x11-themes/gtk-engines-2.6.7 >=x11-themes/gnome-backgrounds-2.12.3.1 >=x11-libs/vte-0.11.17 >=x11-terms/gnome-terminal-2.12.0 >=gnome-extra/gucharmap-1.4.4 >=gnome-base/libgnomeprint-2.12.1 >=gnome-base/libgnomeprintui-2.12.1 >=gnome-extra/gnome-utils-2.12.2 >=gnome-extra/gnome-games-2.12.3 >=gnome-base/librsvg-2.12.7 >=gnome-extra/gnome-system-monitor-2.12.2 >=gnome-base/libgtop-2.12.2 >=x11-libs/startup-notification-0.8 >=gnome-extra/gnome2-user-docs-2.8.1 >=gnome-extra/yelp-2.12.2 >=gnome-extra/zenity-2.12.1 >=net-analyzer/gnome-netstatus-2.12.0 >=net-analyzer/gnome-nettool-1.4.1 cdr? ( >=gnome-extra/nautilus-cd-burner-2.12.3 ) dvdr? ( >=gnome-extra/nautilus-cd-burner-2.12.3 ) hal? ( >=gnome-base/gnome-volume-manager-1.5.4 ) >=gnome-extra/gtkhtml-3.8.2 >=mail-client/evolution-2.4.2.1 >=gnome-extra/evolution-data-server-1.4.2.1 >=gnome-extra/evolution-webcal-2.4.1 >=net-misc/vino-2.12.0 >=app-admin/gnome-system-tools-1.4.1 >=app-admin/system-tools-backends-1.4.2 accessibility? ( >=gnome-extra/libgail-gnome-1.1.3 >=gnome-base/gail-1.8.8 >=gnome-extra/at-spi-1.6.6 >=app-accessibility/dasher-3.2.18 >=app-accessibility/gnome-mag-0.12.3 >=app-accessibility/gnome-speech-0.3.9 >=app-accessibility/gok-1.0.5 >=app-accessibility/gnopernicus-0.11.8 ) )"

-- 
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] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 17:45, Ciaran McCreesh wrote:
> On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | * Just because breaking policy breaks a QA tool, but is guaranteed to
> |   never break itself (formatting policy, like space vs. tab etc.)
> | does not increase the severity of the breakage.
>
> I'd argue against this one. See, it's possible to deliberately
> circumvent some of repoman's checks by doing weird whitespace and syntax
> trickery. There's also no way to fix repoman short of writing a fully
> functional bash parsing tool -- which is complicated enough that even
> bash doesn't have one that works in some releases...

I'm also convinced that deliberate circumvention is easy to detect. QA should 
be able to fix these issues on itself anyway. If people deliberately subvert 
QA in these kinds of way, In my opinion, they are in need of a serious talk 
with devrel.

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] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| I'm also convinced that deliberate circumvention is easy to detect.

In that case, please provide a list of cases where !arch? flags are
being used to circumvent repoman warnings, where the correct solution
would be to use use.mask. My reasonably educated guess is that this is
the most common kind of deliberate circumvention to avoid a repoman
error.

Unfortunately, detecting "foo? ( !arch? ( somepackage ) )" gets a whole
load of false positives. I already tried that one without success...

-- 
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] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 19:28, Mark Loeser wrote:
> Ciaran McCreesh <ciaranm@gentoo.org> said:
> > It's a heck of a lot easier to do if you assume that developers will
> > use sane syntax. Where developers don't use sane syntax, the only way
> > to deal with it is to check it by hand. We don't have enough developers
> > to do that.
>
> I don't see where anyone is saying that we shouldn't fix things to
> adhere to coding standards.  We are just saying it is not a, "OMG you
> broke it!" problem.  It is about appropriate responses to the problems
> we encounter.

That is my point exactly. I do encourage QA though to make available a list of 
those syntax issues that break their tools. Take it for a positive spin, 
developers will then be prepared to accomodate QA. We all want quality.

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] QA Roles v2

[Grobian]

On 02-03-2006 20:19:19 +0000, Ciaran McCreesh wrote:
> On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze <pauldv@gentoo.org>
> wrote:
> | I'm also convinced that deliberate circumvention is easy to detect.
> 
> In that case, please provide a list of cases where !arch? flags are
> being used to circumvent repoman warnings, where the correct solution

Circumvent?  Can you elaborate on that?  repoman does have a problem
with this, while portage does not.


-- 
Fabian Groffen
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 21:19, Ciaran McCreesh wrote:
> On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | I'm also convinced that deliberate circumvention is easy to detect.
>
> In that case, please provide a list of cases where !arch? flags are
> being used to circumvent repoman warnings, where the correct solution
> would be to use use.mask. My reasonably educated guess is that this is
> the most common kind of deliberate circumvention to avoid a repoman
> error.

Then explain people that doing this is not the way. I would suspect that 
people think that this is the actual solution. It's also not really like 
people would do this to hide the fact that they have hidden a global rm -rf 
somewhere around.And is it really a quality issue? In all cases? There must 
be cases where the problem is package + arch + useflag specific, and this 
solution "solves" it.

What I mean with deliberate, is circumventing when knowing it is wrong. If 
people know it's wrong, and still do it, they are clearly malvolent.

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] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 2 Mar 2006 21:29:30 +0100 Grobian <grobian@gentoo.org> wrote:
| On 02-03-2006 20:19:19 +0000, Ciaran McCreesh wrote:
| > On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze <pauldv@gentoo.org>
| > wrote:
| > | I'm also convinced that deliberate circumvention is easy to
| > | detect.
| > 
| > In that case, please provide a list of cases where !arch? flags are
| > being used to circumvent repoman warnings, where the correct
| > solution
| 
| Circumvent?  Can you elaborate on that?  repoman does have a problem
| with this, while portage does not.

Okay. This is a rather hypothetical example, since alsa is masked on
relevant profiles, but it's a nice, easy to understand case that's on a
worryingly common theme.

Say you create a new package, which we'll call mysoundthing. You add
mysoundthing 1.1 to the tree, and it picks up a ~sparc keyword. Along
comes mysoundthing 1.2, complete with optional ALSA support. You add in
a dep of alsa? ( whatever the alsa libraries are these days ), and try
to commit it. Repoman complains that the alsa libraries are unkeyworded
on sparc.

Now, you've heard that dropping keywords is bad. But you have a clever
idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets
past repoman just fine.

Along comes 2006 (or late 2005), and some sparc profiles get working
ALSA support. So, the ALSA libraries are keyworded / profile masked as
appropriate. Along comes joeuser, who installs mysoundthing. He wants
ALSA support, so he turns on the alsa USE flag. Sure enough, emerge -pv
indicates that ALSA will be enabled.

However... Because of the nasty !arch? hack, he won't get alsa support
until the arch team goes through and fixes this ebuild (and probably
several others too...).

The correct solution is to get the alsa USE flag use.masked on various
profiles (as, in the alsa case, it is). However, there are a whooole
load of ebuilds in the tree that don't do this properly.

Scary sidenote: a similar hack has lead to some forums users suggesting
that the way to avoid getting mozilla as part of gnome was to use
USE="mips".

This issue has been a major pain in the ass for some of the arch teams,
and it will very likely be another major pain in the ass in the future,
again and again.

-- 
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] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze <pauldv@gentoo.org>
wrote:
| Then explain people that doing this is not the way.

Have done, repeatedly, as have many others.

| And is it really a qualityissue? In all cases? There must be cases
| where the problem is package + arch + useflag specific, and this
| solution "solves" it.

This is most definitely a quality issue in cases where it is misused.
See my reply to Grobian for why it's a huge problem. And yes, there are
legit cases of using !arch? inside DEPEND, which is what makes it even
harder to detect deliberate repoman circumvention.

-- 
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] QA Roles v2

[Mark Loeser]

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

Stuart Herbert <stuart.herbert@gmail.com> said:
> Hi Mark,
> 
> This draft seems to be effectively the same as the last one.


> I'm sorry, but personally I don't see how this draft is substantially
> different from the one posted originally.  It looks like you've
> decided not to address the points I raised about your original draft:


I never said it was different.  I said I added some things based on
feedback I got.  As I said in the last thread, I disagree with many of
the things you have come up with.  You are free to try and convince me
otherwise.

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

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

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Thursday 02 March 2006 21:51, Ciaran McCreesh wrote:
> On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze <pauldv@gentoo.org>
>
> wrote:
> | Then explain people that doing this is not the way.
>
> Have done, repeatedly, as have many others.
>
> | And is it really a qualityissue? In all cases? There must be cases
> | where the problem is package + arch + useflag specific, and this
> | solution "solves" it.
>
> This is most definitely a quality issue in cases where it is misused.
> See my reply to Grobian for why it's a huge problem. And yes, there are
> legit cases of using !arch? inside DEPEND, which is what makes it even
> harder to detect deliberate repoman circumvention.

I've read your explanation in the other reply. I agree with you that it is 
indeed an issue.

Paul

ps. The explanation was clear to me.

-- 
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] QA Roles v2

[Michael Cummings]

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

On Thu, 2006-03-02 at 20:49 +0000, Ciaran McCreesh wrote:
> Now, you've heard that dropping keywords is bad. But you have a clever
> idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets
> past repoman just fine.
> 

<STOP> As any arch can tell you, that's never stopped me - *IF* you do
it correctly, ie comment out the existing keywords, add the keywords
that the package can support, and file a bug against the arch's that you
had to drop explaining the need for re-keywording because of a new dep
that they don't yet support. AFAIK that's the correct way to do it - and
I believe that pretty strongly since at this point there isn't a single
arch that wouldn't have filed a grievance against me otherwise. Sure,
those bugs may stay open for months and months and months because ia64
doesn't have the resources to devote (which is understood), but at that
point you have 2 references for users, the ebuild with the commented out
line, the ChangeLog, and the bug.

Is this not how its supposed to be done? Because if it is, maybe those
insistant on the !arch method should be pointed to that and leave it up
to the arch's to make the decision of whether to keyword or disable
specific support. Devs acting on behalf of a herd shouldn't be making
these kind of arch decisions, but instead leaving it up to devs acting
with their arch hats on. Maybe the two meet under the same roof
sometimes, but more times than not they don't. Yep, that's a lot more
work and effort and pain - but afaik it follows good qa methods.

And despite the length of this message, I haven't spoken on one side of
the fence or the other I think...sweet :)

~mcummings

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

Re: [gentoo-dev] QA Roles v2

[Ciaran McCreesh]

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

On Thu, 02 Mar 2006 16:19:58 -0500 Michael Cummings
<mcummings@gentoo.org> wrote:

| On Thu, 2006-03-02 at 20:49 +0000, Ciaran McCreesh wrote:
| > Now, you've heard that dropping keywords is bad. But you have a
| > clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ).
| > This gets past repoman just fine.
| 
| <STOP> As any arch can tell you, that's never stopped me - *IF* you do
| it correctly, ie comment out the existing keywords, add the keywords
| that the package can support, and file a bug against the arch's that
| you had to drop explaining the need for re-keywording because of a
| new dep that they don't yet support. AFAIK that's the correct way to
| do it

Yup. I probably should've mentioned that as part of the explanation...
The correct way to proceed, in the general case, is to contact the arch
team and ask them to use.mask or keyword deps as appropriate. Keywords
can be dropped if and only if a bug is filed.

-- 
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] QA Roles v2

[Mike Frysinger]

On Thursday 02 March 2006 16:19, Michael Cummings wrote:
> On Thu, 2006-03-02 at 20:49 +0000, Ciaran McCreesh wrote:
> > Now, you've heard that dropping keywords is bad. But you have a clever
> > idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets
> > past repoman just fine.
>
> <STOP> As any arch can tell you, that's never stopped me

yes, but you do not represent every single dev :)

we still have occurrences in the tree where people wrongly utilize the 
aforementioned syntax ...
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mike Frysinger]

On Thursday 02 March 2006 04:01, Stuart Herbert wrote:
> * There is no proposal for a process to formulate, and gain wide
> approval for new QA standards.  This week, there's been an example of
> the QA team documenting a QA standard *after* a bug was raised about a
> QA violation ... and then that document being used as if that
> particular QA standard had always been in the document.

i chatted on irc with a few peeps about this and here's what has been rolling 
around in my noggin ...

we're going to have two documents of sorts ... the balls-to-the-wall 
happy-to-be-hardcore nothing-more-official-than-this devrel document ... and 
then we're going to have the stop-cant-stop-my-feet QA guidelines which is 
quite dynamic and meant to outline what the QA team is looking for at any 
particular point in time

to get into the QA guidelines, you go through the QA team ... to get into the 
devrel document, you go through the devrel doc maintainers.  to increase 
visibility here, i think that all significant changes to policy that are 
Incorporated into the devrel handbook should have a notice sent to the gentoo 
dev mailing list first.  thus if people strongly object, we can resolve those 
differences without having people upset when something they disagree with and 
have never heard of is thrown in their FACE.  as for the QA document, there 
is a QA list where notifications/changes can be sent.  then over time we can 
move relevant pieces of the QA document into the devrel document.
-mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mike Frysinger]

On Wednesday 01 March 2006 21:53, Mark Loeser wrote:
> Here is my updated version after some feedback from people:
>
> * In case of emergency, or if package maintainers refuse to cooperate,
>   the QA team may take action themselves to fix the problem.
> * The QA team 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 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.

one thing i dont think we give enough emphasis to is that our tools arent 
perfect ... sometimes we utilize QA violations to work around portage 
limitations ... if you want to see some really sweet hacks, review any of the 
toolchain related ebuilds and the hacks ive had to add to get cross-compiling 
to the usuable state that it is today.  a handful of them would fall under 
the 'severe' category i'm sure.  and if we want to use the lovely php 
example, personally i think that given portage's current limitations, the 
latest dev-lang/php ebuild is probably one of the best solutions that could 
have been developed, thanks Stuart for all the flak you've had to take over 
this.  also, many games ebuilds break the 'non-interactive' policy by 
displaying licensing and making the user hit "Y" because portage lacks checks 
where the user explicitly states what licenses they accept.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mark Loeser]

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

Mike Frysinger <vapier@gentoo.org> said:
> one thing i dont think we give enough emphasis to is that our tools arent 
> perfect ... sometimes we utilize QA violations to work around portage 
> limitations ... if you want to see some really sweet hacks, review any of the 
> toolchain related ebuilds and the hacks ive had to add to get cross-compiling 
> to the usuable state that it is today.  a handful of them would fall under 
> the 'severe' category i'm sure.  and if we want to use the lovely php 
> example, personally i think that given portage's current limitations, the 
> latest dev-lang/php ebuild is probably one of the best solutions that could 
> have been developed, thanks Stuart for all the flak you've had to take over 
> this.  also, many games ebuilds break the 'non-interactive' policy by 
> displaying licensing and making the user hit "Y" because portage lacks checks 
> where the user explicitly states what licenses they accept.

This somewhat touchs on what pauldv mentioned earlier, that we will
acknowledge when no better possible solution is available, and some
"workaround" is needed.  As he also suggested, we should keep a list of
these in the form of open bugs so that we can get a better solution
somewhere in the long-term.

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

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

Re: [gentoo-dev] QA Roles v2

[Thierry Carrez]

Stuart Herbert wrote:

> [...]
> Mark, in the discussions about the QA policy, your fallback
> justification always seems to be "Trust us".  I think this week's
> events have put a big dent in the credibility of that argument, if not
> holed it below the water line.  If the QA team followed processes
> similar to what I've described above, I believe that this week's
> events wouldn't have happened.  What started off as a worthy piece of
> QA work, which I'm sure has fixed many real problems for users,
> degenerated into something altogether unpleasant and unnecessary for
> all involved.  We've all gotten a week older and a week greyer out of
> this.  Have we fixed any real problems that stop our users installing
> and running Gentoo?  No, we haven't.  I hope we can all (and I include
> myself in that) learn something from this to prevent a repeat.
> 
> I call for Mark's proposed policy to be rejected as it stands.

"Trust us" sounds like a good justification to me. If the council grants
the QA team the right to preempt maintainers for major QA violations,
they will indeed have power and may abuse it. But if their use of this
power is obviously abusive, the council can revert its decision and cut
the balls from that QA team. So I'm for trusting them and see. We need
more QA and they can't do their job properly the way it's working now.

-- 
Thierry Carrez (Koon)
Gentoo Linux Security && Council Member
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 6:31:17, Mark Loeser wrote:

> Mike Frysinger <vapier@gentoo.org> said:
>> one thing i dont think we give enough emphasis to is that our tools arent 
>> perfect ... sometimes we utilize QA violations to work around portage 
>> limitations ... if you want to see some really sweet hacks, review any of the 
>> toolchain related ebuilds and the hacks ive had to add to get cross-compiling 
>> to the usuable state that it is today.  a handful of them would fall under 
>> the 'severe' category i'm sure.  and if we want to use the lovely php 
>> example, personally i think that given portage's current limitations, the 
>> latest dev-lang/php ebuild is probably one of the best solutions that could 
>> have been developed, thanks Stuart for all the flak you've had to take over 
>> this.  also, many games ebuilds break the 'non-interactive' policy by 
>> displaying licensing and making the user hit "Y" because portage lacks checks 
>> where the user explicitly states what licenses they accept.

> This somewhat touchs on what pauldv mentioned earlier, that we will
> acknowledge when no better possible solution is available, and some
> "workaround" is needed.  As he also suggested, we should keep a list of
> these in the form of open bugs so that we can get a better solution
> somewhere in the long-term.


Please, until something is clarified/some consent reached, avoid changing
the docs w/ funny stuff like "just flip a coin"...

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

What's the above again? QA policy? How does user benefit from flipping a
coin wrt choosing a functionality? Sigh...  :/


-- 
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] QA Roles v2

[Stephen Bennett]

On Fri, 3 Mar 2006 21:47:22 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> Please, until something is clarified/some consent reached, avoid
> changing the docs w/ funny stuff like "just flip a coin"...
> 
> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
> 
> What's the above again? QA policy? How does user benefit from
> flipping a coin wrt choosing a functionality? Sigh...  :/

It gets the point across effectively. I don't see your problem.
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 22:19:33, Stephen Bennett wrote:

> On Fri, 3 Mar 2006 21:47:22 +0100
> Jakub Moc <jakub@gentoo.org> wrote:

>> Please, until something is clarified/some consent reached, avoid
>> changing the docs w/ funny stuff like "just flip a coin"...
>> 
>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
>> 
>> What's the above again? QA policy? How does user benefit from
>> flipping a coin wrt choosing a functionality? Sigh...  :/

> It gets the point across effectively. I don't see your problem.

What kind of point does it get across, exactly? That flipping a coin or
forcing your personal preference is a better solution than letting users
decide what kind of functionality they prefer? Don't you think users do know
better? What's the point of such policy? You call forcing random feature on
users instead of letting them decide QA? I don't.


-- 
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: Re[2]: [gentoo-dev] QA Roles v2

[Stuart Herbert]

On 3/3/06, Jakub Moc <jakub@gentoo.org> wrote:
> > It gets the point across effectively. I don't see your problem.
>
> What kind of point does it get across, exactly? That flipping a coin or
> forcing your personal preference is a better solution than letting users
> decide what kind of functionality they prefer? Don't you think users do know
> better? What's the point of such policy? You call forcing random feature on
> users instead of letting them decide QA? I don't.

I agree.  Adopting a policy like this is a low quality solution for
servers.  I've no opinion on how this affects desktops, but packages
for servers need to be precise.    A policy that says "if two USE
flags deliver the same benefits, but conflict, pick one" is fine.  But
saying "flip a coin" ... how on earth is that "quality"?

And how the heck is it going to work w/ USE-based defaults?  This
creates a situation where package (b) cannot trust that a feature is
enabled in package (a), even if package (a) was built with the
required USE flags.

I'll go as far as saying that right now I'm embarrased that it looks
like this is going to become a Gentoo policy in its current form. 
You're absolutely *not* creating a better user experience.  You're
brushing a problem under the carpet ... and making it the users'
problem when they wonder why the built a package with a USE flag and
the package still doesn't work as they expect.

Until Portage supports resolving conflicting USE flags when the
deptree is built, the practical thing to do is for ebuilds w/
conflicting USE flags to bail.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mike Frysinger]

On Friday 03 March 2006 15:47, Jakub Moc wrote:
> Please, until something is clarified/some consent reached, avoid changing
> the docs w/ funny stuff like "just flip a coin"...

please, get a sense of humor, kthxbye
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Grant Goodyear]

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

Sending this from the right address this time....

-g2boojum-

Grant Goodyear wrote:
> Jakub Moc wrote:
>> Please, until something is clarified/some consent reached, avoid changing
>> the docs w/ funny stuff like "just flip a coin"...
> 
> I don't believe the text is meant to be funny.  It's meant (I think) to
> suggest that if all else is equal, meaning that there is no obvious
> "best choice", then just choose a flag, by whatever means, to support as
> the default.  Even if it is not what the user might have chosen, at
> least the build will complete.  Moreover, the results will then be
> deterministic.
> 
>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
>>
>> What's the above again? QA policy? How does user benefit from flipping a
>> coin wrt choosing a functionality? Sigh...  :/
> 
> It prevents emerge from crashing out in the middle of what could be a
> quite extensive build.  Personally, I would rather rebuild one package
> to get desired functionality _after_ the emerge completes than have to
> fix the flags for that one package to be able to build everything else.
> 
> -g2boojum-
> 



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

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 22:51:39, Mike Frysinger wrote:

> On Friday 03 March 2006 15:47, Jakub Moc wrote:
>> Please, until something is clarified/some consent reached, avoid changing
>> the docs w/ funny stuff like "just flip a coin"...

> please, get a sense of humor, kthxbye
> -mike

Sorry, I don't find anything particularly humorous w/ such suggestions
finding their path into documents that you are trying to enforce as a QA
policy.

-- 

jakub

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

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 22:54:25, Grant Goodyear wrote:

>>> http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoo&r1=1.31&r2=1.32
>>>
>>> What's the above again? QA policy? How does user benefit from flipping a
>>> coin wrt choosing a functionality? Sigh...  :/
>> 
>> It prevents emerge from crashing out in the middle of what could be a
>> quite extensive build.  Personally, I would rather rebuild one package
>> to get desired functionality _after_ the emerge completes than have to
>> fix the flags for that one package to be able to build everything else.

Erm, how exactly will you find out that you need to recompile that package
after such extensive build? You'll spend a couple of hours debugging when
your server app stops working? Yay! :P

Oh please, stop making up artificial policies doing no good to users just to
hack around lacking features in portage.


-- 

jakub

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

Re: [gentoo-dev] QA Roles v2

[Stephen Bennett]

On Fri, 3 Mar 2006 22:27:45 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> What kind of point does it get across, exactly? 

That you must choose one flag, or set of flags, to take precedence in
such situations, but that how you choose is quite immaterial. If there
is an obvious choice then use it, else pick one some other way.
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 23:25:13, Stephen Bennett wrote:

> On Fri, 3 Mar 2006 22:27:45 +0100
> Jakub Moc <jakub@gentoo.org> wrote:

>> What kind of point does it get across, exactly? 

> That you must choose one flag, or set of flags, to take precedence in such
> situations, but that how you choose is quite immaterial. If there is an
> obvious choice then use it, else pick one some other way.

Yeah, that's a wonderful message. Let users choose, they are not idiots and
such policy does more harm than good. Period.


-- 

jakub

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

Re: [gentoo-dev] QA Roles v2

[Grant Goodyear]

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

Stuart Herbert wrote:
> I agree.  Adopting a policy like this is a low quality solution for
> servers.  I've no opinion on how this affects desktops, but packages
> for servers need to be precise.    A policy that says "if two USE
> flags deliver the same benefits, but conflict, pick one" is fine.  But
> saying "flip a coin" ... how on earth is that "quality"?

See my previous post.

> And how the heck is it going to work w/ USE-based defaults?  This
> creates a situation where package (b) cannot trust that a feature is
> enabled in package (a), even if package (a) was built with the
> required USE flags.

Yep.  Having a USE flag enabled turns out not to be a guarantee.  That
said, package builds do become deterministic, so (for example) if one
needs to know if msmtp was built with openssl or gnutls it is easy
enough to pull the logic from the msmtp ebuild.  I'm sure that there is
a more elegant solution, but I'm not convinced that having the user
randomly throw USE flags at a package until some combination works is
necessarily it.  I could be wrong, however.  *Shrug*

> I'll go as far as saying that right now I'm embarrased that it looks
> like this is going to become a Gentoo policy in its current form. 

With an apology for singling you out (when yours is certainly not the
only, or even the most appropriate, example), that sort of emotional
response is how these threads begin to degenerate.  There appears to be
an implicit assumption there that your view is clearly correct, and any
other is embarrassingly silly.  Instead, I suggest that perhaps people
on both (all?) sides of the issue are rational, intelligent people who
simply differ on what happens to be the greatest evil.

> You're absolutely *not* creating a better user experience.  You're
> brushing a problem under the carpet ... and making it the users'
> problem when they wonder why the built a package with a USE flag and
> the package still doesn't work as they expect.

I would argue that the user tends to get unexpected results in either
case, it's just a matter of whether the build crashes, or the resulting
package is somewhat unexpected.  Given that fact, I'm arguing that
having a potentially-lengthy emerge crash out is the bigger evil.

> Until Portage supports resolving conflicting USE flags when the
> deptree is built, the practical thing to do is for ebuilds w/
> conflicting USE flags to bail.

I, quite respectfully, disagree.

-g2boojum-


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

Re: [gentoo-dev] QA Roles v2

[Grant Goodyear]

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

Jakub Moc wrote:
> Erm, how exactly will you find out that you need to recompile that package
> after such extensive build? You'll spend a couple of hours debugging when
> your server app stops working? Yay! :P

I had assumed that in such a case the ebuild would output a
scary-looking ewarn that notified the user of such a problem.

> Oh please, stop making up artificial policies doing no good to users just to
> hack around lacking features in portage.

Was I so impolite that you felt the need to be rude in turn?  If so, I
certainly apologize, as it was not my intention.

I don't believe that I made up this policy, although it's been around as
an unofficial policy for so long that I couldn't really say one way or
the other.  In any event, I certainly agree that fixing portage would be
preferable to policies that work around portage's warts.  On the other
hand, until those warts get fixed it seems useful to have a set of "best
practices" in the meantime.  I'm arguing that sudden, difficult to
predict package build breakages are a bigger sin than having a package
build deterministic functionality that may be unexpected by the user.
You (I think) believe the opposite.  Fair enough.

-g2boojum-


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

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

> > It prevents emerge from crashing out in the middle of what could be a
> > quite extensive build.  Personally, I would rather rebuild one package
> > to get desired functionality _after_ the emerge completes than have to
> > fix the flags for that one package to be able to build everything else.

This is why Ciaran and I opened a bug for the Portage team to get this
handled up-front.  Alas, I can't find the bug any more to reference it
here :(

You're assuming that a user can figure out how to fix the one package
when they realise it's broken.  Unless a user looks inside the ebuild,
they're not going to understand why the USE flags they've selected has
resulted in a package that doesn't actually have those features. 
Chances are, the user will never look.

This is going to *create* more support, not reduce it.  That's hardly
a worthy outcome.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Stephen Bennett]

On Fri, 3 Mar 2006 23:31:49 +0100
Jakub Moc <jakub@gentoo.org> wrote:

> Yeah, that's a wonderful message. Let users choose, they are not
> idiots and such policy does more harm than good. Period.

You're completely missing the point here. The user has a choice, but if
his set of choices doesn't make sense for whatever reason, you have
to decide on some sane way to configure the package. How you come to
that decision is irrelevant, hence the 'flip a coin'.
-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


3.3.2006, 23:32:36, Grant Goodyear wrote:

> Jakub Moc wrote:
>> Erm, how exactly will you find out that you need to recompile that package
>> after such extensive build? You'll spend a couple of hours debugging when
>> your server app stops working? Yay! :P

> I had assumed that in such a case the ebuild would output a
> scary-looking ewarn that notified the user of such a problem.

The whole argument here is that bailing out with conflicting use flags
breaks some extensive compiles. So you suppose users will be sitting in
front of their monitor and stare on the screen waiting for a scary warning?
No, they won't. And even if they were, how exactly is that warning better
than bailing out and asking them to change the use flags?

The only thing that can happen here is that users will get unexpected
results and will be debugging their broken apps once that extensive compile
that must not be interrupted under any circumstances is finished.

>> Oh please, stop making up artificial policies doing no good to users just to
>> hack around lacking features in portage.

> Was I so impolite that you felt the need to be rude in turn?  If so, I
> certainly apologize, as it was not my intention.

No, sorry. That comment was aimed generally at whomever is making up such
policies. I'm really getting tired of this debate. Lets drop the damned
paragraph that has been added recently and lets do some more important job.
This simply cannot be fixed now in a reasonable way that would improve user
experience, so why don't we focus on something that is doable?

> I don't believe that I made up this policy, although it's been around as
> an unofficial policy for so long that I couldn't really say one way or
> the other.  In any event, I certainly agree that fixing portage would be
> preferable to policies that work around portage's warts.  On the other
> hand, until those warts get fixed it seems useful to have a set of "best
> practices" in the meantime.  I'm arguing that sudden, difficult to
> predict package build breakages are a bigger sin than having a package
> build deterministic functionality that may be unexpected by the user.
> You (I think) believe the opposite.  Fair enough.

Well, selecting features randomly is not what I believe could be a "best
practice".

-- 

jakub

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

Re: [gentoo-dev] QA Roles v2

[Simon Stelling]

Stuart Herbert wrote:
>>>It prevents emerge from crashing out in the middle of what could be a
>>>quite extensive build.  Personally, I would rather rebuild one package
>>>to get desired functionality _after_ the emerge completes than have to
>>>fix the flags for that one package to be able to build everything else.
> 
> 
> This is why Ciaran and I opened a bug for the Portage team to get this
> handled up-front.  Alas, I can't find the bug any more to reference it
> here :(

bug 75936

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Member
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

Hi Grant,

On 3/3/06, Grant Goodyear <g2boojum@gentoo.org> wrote:
> Yep.  Having a USE flag enabled turns out not to be a guarantee.  That
> said, package builds do become deterministic, so (for example) if one
> needs to know if msmtp was built with openssl or gnutls it is easy
> enough to pull the logic from the msmtp ebuild.

If a build process has errors, it should stop.  That's still
deterministic.  I'd respectfully argue that it's far more
deterministic than having each single package implement separate
policy for handling conflicting USE flags.

Policy belongs with the user, not in Portage.  It's exactly the same
as the kernel pushing policy into userspace.

I believe that it's bad engineering to force (using your example)
packages that depend on msmtp to have to copy the logic from the msmtp
ebuild to understand how to correctly depend on that package.  It
violates the principle of Don't Repeat Yourself.

If we're going to do this, then at least we should be implementing a
consistent standard across all ebuilds.  F.ex, when SSL and TLS
conflict, we should have a standard saying that all ebuilds will
consistenly favour one over the other.  That's much more deterministic
than having some ebuilds prefer SSL, and others prefer TLS (for
example).

> I'm sure that there is
> a more elegant solution, but I'm not convinced that having the user
> randomly throw USE flags at a package until some combination works is
> necessarily it.  I could be wrong, however.  *Shrug*

Why would the user be randomly throwing USE flags at a package?  With
the PHP ebuilds and the confutils eclass, we've already proved that
you can tell the user exactly why the ebuild has bailed, and what they
can do to fix it.

> With an apology for singling you out (when yours is certainly not the
> only, or even the most appropriate, example), that sort of emotional
> response is how these threads begin to degenerate.  There appears to be
> an implicit assumption there that your view is clearly correct, and any
> other is embarrassingly silly.  Instead, I suggest that perhaps people
> on both (all?) sides of the issue are rational, intelligent people who
> simply differ on what happens to be the greatest evil.

I accept the point, but, well, I *am* embarrassed.  I guess I'm just
willing to admit it when others would rather not be open and honest
about how this makes them feel.  I think it's fair to raise that as
part of the debate.  I don't think we talk enough about how we feel
about what's happening to Gentoo these days.  I think it's reasonable
that issues like this are delt with both on an emotional intelligence
level as well as an intellectual one.

> I would argue that the user tends to get unexpected results in either
> case, it's just a matter of whether the build crashes, or the resulting
> package is somewhat unexpected.  Given that fact, I'm arguing that
> having a potentially-lengthy emerge crash out is the bigger evil.

I can understand how that matters to first-time installs, or users
running old hardware.  My environment and concern are servers, where
dual-Xeon or dual-Opterons are the norm.  The time it takes to install
a package is trivial against the time it takes to diagnose why it
isn't working the way you would expect.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Ciaran McCreesh]

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

On Fri, 3 Mar 2006 23:14:41 +0000 "Stuart Herbert"
<stuart.herbert@gmail.com> wrote:
| If we're going to do this, then at least we should be implementing a
| consistent standard across all ebuilds.  F.ex, when SSL and TLS
| conflict, we should have a standard saying that all ebuilds will
| consistenly favour one over the other.  That's much more deterministic
| than having some ebuilds prefer SSL, and others prefer TLS (for
| example).

And what of gtk vs qt, where for many packages one is clearly the
preferred choice, but which one this is varies between packages? Do
*you* know which GUI is the best option for gvim and why?

Heck, it's hard enough figuring out a usable set of USE flags for PHP.
If we started dieing for the three zillion or so mutually independent
GUI options in gvim7 users would never actually be able to figure out
how to install the thing...

-- 
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] QA Roles v2

[Alec Warner]

> The whole argument here is that bailing out with conflicting use flags
> breaks some extensive compiles. So you suppose users will be sitting in
> front of their monitor and stare on the screen waiting for a scary warning?
> No, they won't. And even if they were, how exactly is that warning better

No they won't, but elog in portage-2.1 will gladly send them a message 
via whatever configuration they have about the warning that the ebuild 
produced.

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mike Frysinger]

On Friday 03 March 2006 18:14, Stuart Herbert wrote:
> If we're going to do this, then at least we should be implementing a
> consistent standard across all ebuilds.  F.ex, when SSL and TLS
> conflict, we should have a standard saying that all ebuilds will
> consistenly favour one over the other.  That's much more deterministic
> than having some ebuilds prefer SSL, and others prefer TLS (for
> example).

bad idea ... choosing a default is a per-package issue.  say we take this path 
and we declare that if a package supports both tls and ssl, you must utilize 
tls over ssl regardless.  then you come to a package has really shitty tls 
support but it has wonderful ssl support.  you're saying that defaulting to 
tls is a better idea than ssl ?  a global decision like this just wont cut 
it.
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[b12 a.k.a. Fabrice Bellamy]

Alec Warner wrote:
>> The whole argument here is that bailing out with conflicting use flags
>> breaks some extensive compiles. So you suppose users will be sitting in
>> front of their monitor and stare on the screen waiting for a scary
>> warning?
>> No, they won't. And even if they were, how exactly is that warning
>> better
>
> No they won't, but elog in portage-2.1 will gladly send them a message
> via whatever configuration they have about the warning that the ebuild
> produced.
>
> -Alec Warner
Greetings dear Gentoo developers.

I would like to give you my humble point of view on this subject as a
simple gentoo user.

A few days after an emerge that took 7 hours to complete I used the
portlog-info script to extract the warnings from the portage log (I'm
using portage 2.0.54 on that computer so no elog there). While reading
these warnings I came to this one:

 === 2006-02-12 01:01 =========== php-4.4.0-r4 ===
 = /var/log/portage/2729-php-4.4.0-r4.log (4.0K) =
...
 * If you have both freetds and mssql in your USE flags, parts of PHP
 * may not behave correctly, or may give strange warnings. You have
 * been warned! It's recommended that you pick ONE of them. For sybase
 * support, chose 'freetds'. For mssql support choose 'mssql'.
 * If you have additional third party PHP extensions (such as
 * dev-php/eaccelerator) you may need to recompile them now.
...

So now, even if I have no knowledge about PHP, I know that if something
is going wrong with it I will have to check these use flags.  And if I
was not so lazy  I would have a look at them right now to be sure
nothing bad will happen.

I feel more comfortable with this behavior than with a long emerge that
would have stopped in the middle because of potentially conflicting use
flags.

(sorry for my bad English and thank you all for your good work. I just
love Gentoo)

Fabrice Bellamy



	

	
		
___________________________________________________________________________ 
Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international.
Téléchargez sur http://fr.messenger.yahoo.com
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Curtis Napier]

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

Mike Frysinger wrote:
> On Wednesday 01 March 2006 21:53, Mark Loeser wrote:
>> Here is my updated version after some feedback from people:
>>
>> * In case of emergency, or if package maintainers refuse to cooperate,
>>   the QA team may take action themselves to fix the problem.
>> * The QA team 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 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.
> 
> one thing i dont think we give enough emphasis to is that our tools arent 
> perfect ... sometimes we utilize QA violations to work around portage 
> limitations ... if you want to see some really sweet hacks, review any of the 
> toolchain related ebuilds and the hacks ive had to add to get cross-compiling 
> to the usuable state that it is today.  a handful of them would fall under 
> the 'severe' category i'm sure.  and if we want to use the lovely php 
> example, personally i think that given portage's current limitations, the 
> latest dev-lang/php ebuild is probably one of the best solutions that could 
> have been developed, thanks Stuart for all the flak you've had to take over 
> this.  also, many games ebuilds break the 'non-interactive' policy by 
> displaying licensing and making the user hit "Y" because portage lacks checks 
> where the user explicitly states what licenses they accept.
> -mike


I installed dev-lang/php on a server in my house to test
torrents.gentoo.org and ramereth also installed it on the torrents.g.o
server. I have to say that it was a painless and normal operation with
no errors. Thanks for the hard work on this ebuild, it's appreciated.


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

Re: [gentoo-dev] QA Roles v2

[Thomas de Grenier de Latour]

On Fri, 3 Mar 2006 22:44:22 +0000,
"Stuart Herbert" <stuart.herbert@gmail.com> wrote:

> Unless a user looks inside the ebuild, they're not going to
> understand why the USE flags they've selected has resulted in a
> package that doesn't actually have those features.
...
> This is going to *create* more support, not reduce it.

The problem here, from a user point of view, is the USE flag usage not
matching its description (that's what makes "unexpected" the ebuild
behavior).  For instance, description says "foo - Enable libfoo",
whereas actually the ebuild will only use libfoo if some other "bar" is
unset.

One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die.  Imho,
it makes sense, but if such a strict policy was applied to every
ebuilds which atm are abusing flags this way, it would become really
hard to put anything in the make.conf USE variable without breaking
"emerge -uD world".
Just take the default flags from x86 profile for instance: both "motif"
("Adds motif support") and "gtk" ("Adds support for x11-libs/gtk+") are
enabled, whereas the logic in several packages supporting both is to 
build the GTK interface when "gtk" is on, and to build a Motif one 
otherwise, if "motif" is on.  Do you think such ebuilds should rather 
die at compile time, asking the user to make an unconflicting choice?
I don't. My package.use is already ~200 lines long for various other 
reasons, and i really don't want to double its size again just to 
make my "emerge -uD world" successfully terminating.

Now, an alternative point of view is that what is wrong is rather the
USE flag descriptions.  That's exactly what the "package specific USE
flag descriptions" proposal, which popups on this list from time to 
time, is about (sorry, no URL because GMane seems down, but i can post 
some later if you're interested).
The idea (or at least my pov on this idea, but others had different 
views iirc) is that emerge could display some package-specific flags 
descriptions in such cases.  Using the emerge patch from bug #84884, 
and with a "use.local.desc" entry for "app-editors/gvim:motif", the 
user would be warned about what the "motif" flag actualy does (or does
not) on this package:

---------------
% emerge -pv --use-desc-special gvim
...
[ebuild   R   ] app-editors/gvim-6.4  USE="-acl bash-completion cscope
gnome gpm gtk motif nls -perl python ruby" 0kB
...
The following USE flags have package-specific descriptions:
app-editors/gvim
    motif - Include support for the Motif GUI, but if "gtk" or "gnome" 
flags are turned on too, in which case they are prefered.
---------------

This way, nothing unexpected for users, and no complain for devs.

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

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Friday 03 March 2006 23:32, Grant Goodyear wrote:
> Stuart Herbert wrote:
> > I agree.  Adopting a policy like this is a low quality solution for
> > servers.  I've no opinion on how this affects desktops, but packages
> > for servers need to be precise.    A policy that says "if two USE
> > flags deliver the same benefits, but conflict, pick one" is fine.  But
> > saying "flip a coin" ... how on earth is that "quality"?
>
> See my previous post.
>
> > And how the heck is it going to work w/ USE-based defaults?  This
> > creates a situation where package (b) cannot trust that a feature is
> > enabled in package (a), even if package (a) was built with the
> > required USE flags.
>
> Yep.  Having a USE flag enabled turns out not to be a guarantee.  That
> said, package builds do become deterministic, so (for example) if one
> needs to know if msmtp was built with openssl or gnutls it is easy
> enough to pull the logic from the msmtp ebuild.  I'm sure that there is
> a more elegant solution, but I'm not convinced that having the user
> randomly throw USE flags at a package until some combination works is
> necessarily it.  I could be wrong, however.  *Shrug*

You mean the logic should be replicated between msmtp and all packages that 
need to know how it was built. I see this as a bigger source of bugs (msmtp 
changes, some of the dependants forget to change too) than verifying at setup 
time that the package has sane use flags. I'd prefer that a stage were 
introduced that runs at pretend time exactly for these things. I would say it 
is a bug if a useflag was specified for a package, including dependencies, 
and the package does not actually depend on it because the useflag was not 
actually applied. But even if the dependencies are proper, it is a bug from a 
HCI point of view. A package should deliver what it promisses. If it can't it 
should fail, not silently ignore the request.

>
> > Until Portage supports resolving conflicting USE flags when the
> > deptree is built, the practical thing to do is for ebuilds w/
> > conflicting USE flags to bail.
>
> I, quite respectfully, disagree.

As explained above, when an ebuild can not deliver, it should fail, not 
silently downgrade its features. Especially when other packages may depend on 
those features being present.

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] QA Roles v2

[Paul de Vrieze]

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

On Saturday 04 March 2006 00:29, Ciaran McCreesh wrote:
> On Fri, 3 Mar 2006 23:14:41 +0000 "Stuart Herbert"
>
> <stuart.herbert@gmail.com> wrote:
> | If we're going to do this, then at least we should be implementing a
> | consistent standard across all ebuilds.  F.ex, when SSL and TLS
> | conflict, we should have a standard saying that all ebuilds will
> | consistenly favour one over the other.  That's much more deterministic
> | than having some ebuilds prefer SSL, and others prefer TLS (for
> | example).
>
> And what of gtk vs qt, where for many packages one is clearly the
> preferred choice, but which one this is varies between packages? Do
> *you* know which GUI is the best option for gvim and why?

Than say in the policy "For the choice TLS vs SSL choose SSL. For the choice 
GTK vs QT choose the upstream preferred; if there is none, choose QT" (Don't 
pin me on the choices in this example)

> Heck, it's hard enough figuring out a usable set of USE flags for PHP.
> If we started dieing for the three zillion or so mutually independent
> GUI options in gvim7 users would never actually be able to figure out
> how to install the thing...

The problem is that these flags are dependent. Bailing out on independent 
useflags is not needed.

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] QA Roles v2

[Danny van Dyk]

Hi Thomas,

Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
> One point of view on this issues is that the ebuilds are wrong, because
> they are abusing the said USE flags, and they should rather die.  Imho,
> it makes sense, but if such a strict policy was applied to every
> ebuilds which atm are abusing flags this way, it would become really
> hard to put anything in the make.conf USE variable without breaking
> "emerge -uD world".

Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update 
process would be the best solution at hand. I'd like to propose the addition 
of a dedicated USE conflict detection to ebuilds which need it.

This detection function (for example pkg_prepare()) must be executed for every 
package in the depgraph right after the depgraph has been built and has only 
the possibility to either mark the package as 'go' or 'no-go'. In case that 
any package has been marked as 'no-go', the whole process stops.

A possible implementation from the build side could look like this:

# the next two functions would be candidates for eutils.eclass
emutexuse() {
	eerror "The following USE flags are mutually exclusive:"
	eerror "${@}"
	eerror "Please choose only one of the above and disable the remaining"
	eerror "USE flags. For additional information about this problem, see"
	eerror "http://www.gentoo.org/<some place to store add. info about this>"
	echo
}

emissinguse() {
	eerror "In order to enable the ${2} USE flag you need also to enable"
	eerror "the ${1} USE flag. For additional information ...."
	echo
}

pkg_prepare() {
	local ret=0
	if use foo && use bar ; then
		emutexuse foo bar
		ret=1
	fi
	if use fnord2 && ! use fnord ; then
		emissinguse fnord fnord2
		ret=1
	fi

	return ${ret}
}

Comments?

Danny
-- 
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project

-- 
gentoo-dev@gentoo.org mailing list

Re[2]: [gentoo-dev] QA Roles v2

[Jakub Moc]

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


4.3.2006, 2:57:51, Alec Warner wrote:

>> The whole argument here is that bailing out with conflicting use flags
>> breaks some extensive compiles. So you suppose users will be sitting in
>> front of their monitor and stare on the screen waiting for a scary warning?
>> No, they won't. And even if they were, how exactly is that warning better

> No they won't, but elog in portage-2.1 will gladly send them a message 
> via whatever configuration they have about the warning that the ebuild 
> produced.

Along with messages from another 127 or so ebuilds from that "extensive"
compile (let alone the fact that portage 2.1 isn't stable).

I'm done here, this isn't going anywhere. Feel free to join us on
#gentoo-php to provide support for the resulting miscompiled code and
related issues...

Ktnxbye.

-- 

jakub

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

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

Hi Ciaran,

On 3/3/06, Ciaran McCreesh <ciaranm@gentoo.org> wrote:
> And what of gtk vs qt, where for many packages one is clearly the
> preferred choice, but which one this is varies between packages? Do
> *you* know which GUI is the best option for gvim and why?

No, I don't.  But that doesn't mean the user shouldn't make the
choice.  Even if it is the wrong one from your point of view with your
additional knowledge.

We're a metadistribution, not a distribution.  We're supposed to be
all about allowing the user to tailor each and every package to
his/her exact specification.

I think the policy of 'never die' would be understandable for a
distribution, but I don't feel it's appropriate for a
metadistribution.

> Heck, it's hard enough figuring out a usable set of USE flags for PHP.

How so?  We've worked very hard to ensure that's not the case.  What
have we missed?

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

Hi Mike,

On 3/4/06, Mike Frysinger <vapier@gentoo.org> wrote:
> bad idea ...

Yes it is a bad idea; policy belongs with users.  It shouldn't be
hardcoded into ebuilds, whether across the whole tree or per package.

But ... I realise I'm flogging a dead horse here.

We'll come up with a new revision of the PHP packages which builds
*something* no matter how broken the combination of USE flags are. 
We'll test it first in our overlay, and then when we're happy we'll
add them to the tree for testing and eventual stabilisation.

We'll also provide a replacement for 'built_with_use', which works
with what the package was actually compiled with, rather than what USE
flags the user originally specified.  This will be needed for all the
web-based apps that are written in PHP.  That might take a bit longer,
and might have to follow in a later revision.

As already pointed out, all this will have to be revisited when
Portage supports USE-based deps.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Jason Stubbs]

On Saturday 04 March 2006 23:45, Danny van Dyk wrote:
> Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
> > One point of view on this issues is that the ebuilds are wrong, because
> > they are abusing the said USE flags, and they should rather die.  Imho,
> > it makes sense, but if such a strict policy was applied to every
> > ebuilds which atm are abusing flags this way, it would become really
> > hard to put anything in the make.conf USE variable without breaking
> > "emerge -uD world".
> 
> Just to throw in my 2 cents into this discussion: I'm all against die-ing
> during the update process. However, i think that stopping before the update 
> process would be the best solution at hand. I'd like to propose the addition 
> of a dedicated USE conflict detection to ebuilds which need it.

This sounds the most reasonable. I can't see portage ever supporting "the 'foo'
and 'bar' flags can be used together except when 'baz' is also used" type flag
interdepency complexity. As Mike pointed out, check_license also needs to be
accounted for as well as possible others.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Stuart Herbert]

Hi Danny,

On 3/4/06, Danny van Dyk <kugelfang@gentoo.org> wrote:
> Just to throw in my 2 cents into this discussion: I'm all against die-ing
> during the update process. However, i think that stopping before the update
> process would be the best solution at hand. I'd like to propose the addition
> of a dedicated USE conflict detection to ebuilds which need it.

This is the sort of thing we're asking for in bug #75936.

Best regards,
Stu

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] QA Roles v2

[Mark Loeser]

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

Danny van Dyk <kugelfang@gentoo.org> said:
> Just to throw in my 2 cents into this discussion: I'm all against die-ing
> during the update process. However, i think that stopping before the update 
> process would be the best solution at hand. I'd like to propose the addition 
> of a dedicated USE conflict detection to ebuilds which need it.
> 
> This detection function (for example pkg_prepare()) must be executed for every 
> package in the depgraph right after the depgraph has been built and has only 
> the possibility to either mark the package as 'go' or 'no-go'. In case that 
> any package has been marked as 'no-go', the whole process stops.

I'd rather see the ebuild marked with some flag to show there are
conflicting use flags that have been resolved, and by adding "--verbose"
or some other flag, you can see what flags are overridden so the user
knows exactly what is going on, and can decide if they like the defaults
the ebuild developer has chosen.  I think we should give users the
choice/information to make an informed decision, but I don't think we
should shove a failure into their lap when we can make choices for them
which we believe to be sane.

I'd like less errors/dies during the build/deptree phase and more
warnings/information to be presented so the user could look at it and
make changes, or just accept what we have done for them.

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

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

Re: [gentoo-dev] QA Roles v2

[Paul de Vrieze]

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

On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
> Just to throw in my 2 cents into this discussion: I'm all against
> die-ing during the update process. However, i think that stopping
> before the update process would be the best solution at hand. I'd like
> to propose the addition of a dedicated USE conflict detection to
> ebuilds which need it.
>
Perhaps it would be possible to tell portage to have a 
"build-what-you-can" mode, where it tries to build as much as possible 
after a compilation failure. At the end it then can report on the 
packages that were not compiled.

> This detection function (for example pkg_prepare()) must be executed
> for every package in the depgraph right after the depgraph has been
> built and has only the possibility to either mark the package as 'go'
> or 'no-go'. In case that any package has been marked as 'no-go', the
> whole process stops.

And this indeed.

>
> A possible implementation from the build side could look like this:
>
> # the next two functions would be candidates for eutils.eclass
> emutexuse() {
> 	eerror "The following USE flags are mutually exclusive:"
> 	eerror "${@}"
> 	eerror "Please choose only one of the above and disable the remaining"
> 	eerror "USE flags. For additional information about this problem, see"
> 	eerror "http://www.gentoo.org/<some place to store add. info about
> this>" echo
> }
>

Add some reference to the package for which they are mutually exclusive.

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] QA Roles v2

[Alec Warner]

Paul de Vrieze wrote:
> On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
> 
>>Just to throw in my 2 cents into this discussion: I'm all against
>>die-ing during the update process. However, i think that stopping
>>before the update process would be the best solution at hand. I'd like
>>to propose the addition of a dedicated USE conflict detection to
>>ebuilds which need it.
>>
> 
> Perhaps it would be possible to tell portage to have a 
> "build-what-you-can" mode, where it tries to build as much as possible 
> after a compilation failure. At the end it then can report on the 
> packages that were not compiled.
> 

We've had a bug for this for years, no one has implemented it.

Most of the Portage developers would prefer USE-deps to anything else, 
as this is what that is really trying to cover.  The only alternative 
I'm willing to support at this time is moving the death ( per 
Kugelfang's suggestion ) to right after depgraph building.  Thus a user 
will find out right away that their USE flags conflict and need to be 
changed.  Even with USE deps, there cases that just aren't resolvable, 
they are "unsolveable" and I think coming up with some sort of structure 
to inform the user of this is a good idea.

However we have talked about this and the DEPEND syntax doesn't seem to 
cut it for showing USE conflicts and dependencies.  Certainly right now 
the resolver has no metadata whatsoever to work with, so it can't even 
tell if a specific set of USE flags conflict or not, if we provide it 
with that information it can at least die during depgraph creation 
stating what the problem is with the depgraph ( getting closer to having 
actaul buildplans... ).

-Alec Warner
-- 
gentoo-dev@gentoo.org mailing list