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

[John Mylchreest]

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

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

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



pgpLXBkh7cAFg.pgp
Description: PGP signature

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

[Stuart Herbert]

Hi Mark,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> So the Portage team will have to agre

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

[John Mylchreest]

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

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

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



pgpgTcm5SZaCd.pgp
Description: PGP signature

[gentoo-dev] Desktop project lead nominations

[Donnie Berkholz]

NOTE: Please post all replies on gentoo-desktop rather than gentoo-dev.


It's about that time again, folks. We're going to have desktop project
lead elections within the next month or so.

Who's interested in running for lead? Feel free to post a bit on why
you'll be the best lead ever, as well, and your philosophy on what a
lead should do.

If you're interested in following the process, join the -desktop list.

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SRC_URI component naming collision

[Paul de Vrieze]

On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
> The issue is whether you have the right to leave broken packages in the
> tree. I don't see any policy document granting you that right.

The general consensus over the years has been that if something cannot be 
fixed due to portage problems, then we do what necessary to warn users 
about it, but keep the package. In this regard also look at various 
dependency cycles, and/or use flag dependencies.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpFryZuNjsC1.pgp
Description: PGP signature

Re: [gentoo-dev] SRC_URI component naming collision

[Paul de Vrieze]

On Sunday 26 February 2006 22:29, Robin H. Johnson wrote:
> On Fri, Feb 24, 2006 at 02:19:40PM +, Ciaran McCreesh wrote:
> > Side note: if the packages in question are fetch restricted, you're
> > screwed, and will not be able to add them to the tree.
>
> Actually, there is a solution for this, and it's reasonable logical.
> Don't use the same name that upstream does for the files.
>
> Simply tell the user to download X and place it in $DISTDIR renaming it
> to X-foo-bar, where's you've chosen X-foo-bar to avoid conflicts.

Is there any valid reason that we can't have portage do this 
automatically. This particular way is very user-un-friendly.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpmOdtLJvmkL.pgp
Description: PGP signature

Re: [gentoo-dev] Re: KDE, metapackages, and monolithic packages

[Paul de Vrieze]

On Monday 27 February 2006 00:05, Mike Myers wrote:
> Duncan wrote
>
> [deleted]
>
> Thanks a lot for the detailed explanation.
>
> Do you know if there's a way or going to be a way to handle the split
> ebuilds so that reemerging or unemerging a split ebuild will reemerge
> or unemerge the corresponding packages?  It seems like the ebuilds are
> only intended to make installing kde easier, which they do, but it
> doesn't make handle uninstalling or reinstalling a split ebuild very
> easy at all.  Like, if I had kde 3.4 installed and upgraded to 3.5 and
> no longer need 3.4, I can't just do 'emerge -C kde-meta-3.4', or
> something similar if it's the installed with the split metapackage. Or
> if I just wanted to remove some split ebuild, like say kdenetwork, but
> leave the rest, I couldn't do 'emerge -c kdenetwork-meta' to uninstall
> the related packages.
>
> Basically, my concern is that how KDE is installed is quite easily
> handled, but uninstalling or reinstalling is not equally as easy, at
> least in some aspects.
>
> I hope I explain myself well enough, and thanks for your response.

It is a problem that has been present in portage since the beginning. The 
problem is that portage does not do reverse dependency tracking. The idea 
should be that when kde-meta-3.4 is deleted, it finds that there is no 
package anymore that requested the kde-3.4 subpackages. And as such 
portage would delete them. Currently we can not fix this. It has to do 
with the reasons that depclean is "broken". One problem is that currently 
portage does not record which particular versions satisfy a dependency. 
As such removing packages that should not be used, may introduce problems 
with packages that have been linked against it.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpA1upjIqAVX.pgp
Description: PGP signature

Re: [gentoo-dev] 2006.0 - me having a bad day?

[Kalin KOZHUHAROV]

Jeffrey Forman wrote:
> On Sun, 2006-02-26 at 22:54 -0500, Andrew Muraco wrote:
>> I second that there is a massive confusion of naming, and this needs to 
>> get sorted out (or atleast explained) Because I'm sure the mirrors will 
>> start getting slamed with people downloading 2006.0. Lets not waste 
>> anyone's bandwidth nor the mirrors by leading people to download the 
>> wrong thing.
>>
> 
> Andrew,
> 
> I do not mean to cop an attitude, but please give me some time here to
> figure this out. This is the first time I myself am handling the bouncer
> administration for a release, and I would really appreciate some
> patience on your part.
> 
> I am updating the page as fast as I find an error in it. Thanks.

Thank you for your effort, Jeffrey!

It may turn a good day after all :-)

Have you (or RT) actually thought of providing a pivoted list for downloads?
I feel it is more reasonable to first choose your arch (i.e. on what hardware
you want to install Gentoo) and then see what options you have.

As opposed to the following imaginary n00b:
1. I want a "Universal CD"!

2. Hmm, it is not that universal if I need to choose my arch (I've read
the link on arches!)!

3. Hey, wait a minute! What is that 64bit - 32bit userland ??? What is 64bit? 
What is userland? (wasn't coverd under arches)

4. Lets do some research... ok, I got it there is difference between kernel 
that is 64bit and userland, cool! They should have stated: 64bit kernel + 32bit 
userland (and a plus is better than a minus, even if it is a hyphen)

5. Hmm, but I am using P4 after all, so I need x86!

6. Oops, where is the x86 Universal CD?

7. OK, there is a lonely x86 link under "Gentoo 2006.0 LiveCD", probably that 
is what I need. But why did the change the name???

8. Oh cool they have torrents here! Let me get that x86 Live CD with my torrent 
tool! Should probably be faster... (click on the torrent link)

9. Hmm, that x86-livecd-2006.0 should probably do. It is a CD image, so 
probably is an ISO file... Click!

10. Lets get some coffee, I am tired. But wait, what are these stages bla-bla 
(reading the handbook) OK, great, I might need them (didn't read that 
thoroughly after all, kind of tired). The torrents are not that fast after all 
and there are not enough seeds for stage3-x86-2006.0... (click back)

11. And where is the x86 package CD after all!!! Oh, it might be "part"
of the LiveCD? I wonder, but is there any documentation (looking around
the page...) Anywhere I can see the contents of the ISO files [1] (looking
and clicking around...) no.

12. Sip from a big mug of coffee - Gentoo is not that hard after all, lets
wait and see what am I downloading...


[1] It might be a good idea to implement that.


So sometiing like:

Select your download according to your hardware architecture. (see ...
for info on architectures or ... for the explanaiton of different CD
types )

x86 (486, PentiumIII, Celeron... define it better)
minimal livecd

amd64 (AMD Athlon64 ...)
minimal install packages
.


This will be easier not only for n00bs, I guess and is inspired by the
"Don't MAKE me think" book on web design/usability.

Kalin.

-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2006.0 - me having a bad day?

[Kalin KOZHUHAROV]

Tuan Van wrote:
> Kalin KOZHUHAROV wrote:
>> yes, I figured out that x86-installcd-2006.0 is the "Gentoo 2006.0
>> Minimal install CD" for x86 or is it... will any n00b figure it out?
>>
>>   
> If a n00b can't figure it out, I would suggest him start  from Read The
> Fine  Handbook http://www.gentoo.org/doc/en/handbook/index.xml. For
> example http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2

Good point! The docs are really getting better since I read them from
beginning to end four years ago.

However, the only problem is that some X% (my estimate is 50%) of the
n00bs will never go back and ask or search. Might be wrong of course.

May be a specific link from the download page? Jeffrey?
e.g.:

For more information on the Gentoo CDs, see http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=1&chap=2#doc_chap2";>the
 information in Chapter 2 of the http://www.gentoo.org/doc/en/handbook/";>Gentoo Handbook.

(mind HanbookS vs. Handbook)


BTW, here:
http://www.gentoo.org/doc/en/handbook/2006.0/index.xml
One can find a bunch of cryptic (for a n00b) links to the archs... I am
sure most n00bs tunning x86 don't know that fact, while most on alpha
should not be n00bs anyway.

Add a cross-ref explaining what is an arch?
In the bottom table, better to s/Links/Architectures/ ?
Shall I file a bug report for that, or somebody will pick it up from
here?

Kalin.
-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 2006.0 - me having a bad day?

[Kalin KOZHUHAROV]

Kalin KOZHUHAROV wrote:
> Jeffrey Forman wrote:
>> On Sun, 2006-02-26 at 22:54 -0500, Andrew Muraco wrote:
>>> I second that there is a massive confusion of naming, and this needs to 
>>> get sorted out (or atleast explained) Because I'm sure the mirrors will 
>>> start getting slamed with people downloading 2006.0. Lets not waste 
>>> anyone's bandwidth nor the mirrors by leading people to download the 
>>> wrong thing.
>>>
>> Andrew,
>>
>> I do not mean to cop an attitude, but please give me some time here to
>> figure this out. This is the first time I myself am handling the bouncer
>> administration for a release, and I would really appreciate some
>> patience on your part.
>>
>> I am updating the page as fast as I find an error in it. Thanks.
> 
> Thank you for your effort, Jeffrey!
> 
> It may turn a good day after all :-)
> 
> Have you (or RT) actually thought of providing a pivoted list for downloads?
> I feel it is more reasonable to first choose your arch (i.e. on what hardware
> you want to install Gentoo) and then see what options you have.
> 
> As opposed to the following imaginary n00b:
> 1. I want a "Universal CD"!
> 
> 2. Hmm, it is not that universal if I need to choose my arch (I've read
> the link on arches!)!
> 
> 3. Hey, wait a minute! What is that 64bit - 32bit userland ??? What is 64bit? 
> What is userland? (wasn't coverd under arches)
> 
> 4. Lets do some research... ok, I got it there is difference between kernel 
> that is 64bit and userland, cool! They should have stated: 64bit kernel + 
> 32bit userland (and a plus is better than a minus, even if it is a hyphen)
> 
> 5. Hmm, but I am using P4 after all, so I need x86!
> 
> 6. Oops, where is the x86 Universal CD?
> 
> 7. OK, there is a lonely x86 link under "Gentoo 2006.0 LiveCD", probably that 
> is what I need. But why did the change the name???
> 
> 8. Oh cool they have torrents here! Let me get that x86 Live CD with my 
> torrent tool! Should probably be faster... (click on the torrent link)
> 
> 9. Hmm, that x86-livecd-2006.0 should probably do. It is a CD image, so 
> probably is an ISO file... Click!
> 
> 10. Lets get some coffee, I am tired. But wait, what are these stages bla-bla 
> (reading the handbook) OK, great, I might need them (didn't read that 
> thoroughly after all, kind of tired). The torrents are not that fast after 
> all and there are not enough seeds for stage3-x86-2006.0... (click back)
> 
> 11. And where is the x86 package CD after all!!! Oh, it might be "part"
> of the LiveCD? I wonder, but is there any documentation (looking around
> the page...) Anywhere I can see the contents of the ISO files [1] (looking
> and clicking around...) no.
> 
> 12. Sip from a big mug of coffee - Gentoo is not that hard after all, lets
> wait and see what am I downloading...
> 
> 
> [1] It might be a good idea to implement that.
> 
> 
> So sometiing like:
> 
> Select your download according to your hardware architecture. (see ...
> for info on architectures or ... for the explanaiton of different CD
> types )
> 
> x86 (486, PentiumIII, Celeron... define it better)
> minimal   livecd
> 
> amd64 (AMD Athlon64 ...)
> minimal install packages
> .
> 
> 
> This will be easier not only for n00bs, I guess and is inspired by the
> "Don't MAKE me think" book on web design/usability.

On a second note, the design of our packages.gentoo.org is not bad at all!
Why not use it? For example see:
http://packages.gentoo.org/packages/?category=net-misc;name=curl

Replace PV with the different CDs (use ),
add the speacial "arches" like 64-32ul with acronym as well.

Dunnow about colors, but use them consistently (with a legend).


Kalin.

-- 
|[ ~~ ]|
+-> http://ThinRope.net/ <-+
|[ __ ]|

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] SRC_URI component naming collision

[Ciaran McCreesh]

On Mon, 27 Feb 2006 11:02:57 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
| > The issue is whether you have the right to leave broken packages in
| > the tree. I don't see any policy document granting you that right.
| 
| The general consensus over the years has been that if something
| cannot be fixed due to portage problems, then we do what necessary to
| warn users about it, but keep the package. In this regard also look
| at various dependency cycles, and/or use flag dependencies.

The general consensus has been to implement the best available
workaround, if one is doable, and just remove the thing where it's not.

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



signature.asc
Description: PGP signature

Re: [gentoo-dev] SRC_URI component naming collision

[Ciaran McCreesh]

On Mon, 27 Feb 2006 11:05:00 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| Is there any valid reason that we can't have portage do this 
| automatically. This particular way is very user-un-friendly.

There's exactly one set of packages affected, and they're closed source
and non-repackagable. I doubt it's high priority...

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

Re: [gentoo-dev] SRC_URI component naming collision

[Lance Albertson]

Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 11:02:57 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> wrote:
> | On Sunday 26 February 2006 22:40, Ciaran McCreesh wrote:
> | > The issue is whether you have the right to leave broken packages in
> | > the tree. I don't see any policy document granting you that right.
> | 
> | The general consensus over the years has been that if something
> | cannot be fixed due to portage problems, then we do what necessary to
> | warn users about it, but keep the package. In this regard also look
> | at various dependency cycles, and/or use flag dependencies.
> 
> The general consensus has been to implement the best available
> workaround, if one is doable, and just remove the thing where it's not.

Where is this general consensus documented (other than an email sent out
a few days ago). I'd have to go with Paul on this assumption. I don't
see the problem with keeping a package such as stu's in portage as long
as it doesn't affect other users. Do you honesty expect that we will get
a sterile tree out of this? Please focus your QA efforts are more
important and visible issues. Going on a witch hunt to fix one problem
compared to the bigger issues we know we have is simply silly. This is
really starting to look like a power issue rather than a QA issue.

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

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

[Lance Albertson]

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

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

-- 
Lance Albertson <[EMAIL PROTECTED]>
Gentoo Infrastructure | Operations Manager

---
GPG Public Key:  
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net



signature.asc
Description: OpenPGP digital signature

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

[Ciaran McCreesh]

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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



signature.asc
Description: PGP signature

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

[John Mylchreest]

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

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

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



pgpe2CwZZJnYv.pgp
Description: PGP signature

Re: [gentoo-dev] SRC_URI component naming collision

[Ciaran McCreesh]

On Mon, 27 Feb 2006 10:46:23 -0600 Lance Albertson
<[EMAIL PROTECTED]> wrote:
| Where is this general consensus documented (other than an email sent
| out a few days ago). I'd have to go with Paul on this assumption. I
| don't see the problem with keeping a package such as stu's in portage
| as long as it doesn't affect other users. Do you honesty expect that
| we will get a sterile tree out of this? Please focus your QA efforts
| are more important and visible issues. Going on a witch hunt to fix
| one problem compared to the bigger issues we know we have is simply
| silly. This is really starting to look like a power issue rather than
| a QA issue.

You know, funnily enough, QA has filed a whole heap of bugs on the
conflicting digest issue. With every other maintainer for bugs we've
filed, the developer in question has worked with us to fix the issue,
and thanked us for pointing out the problem. The only reason this one
has gone so far is because of Stuart repeatedly closing the bug off and
refusing to discuss alternatives.

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



signature.asc
Description: PGP signature

[gentoo-dev] bug #20201 and bbapm

[Alec Warner]

bbapm has been masked due to no one responding with anything useful to
last rites e-mail.  It will be punted in 30 days.

-Alec Warner


signature.asc
Description: OpenPGP digital signature

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

[Ciaran McCreesh]

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

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

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

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

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

[Mike Frysinger]

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

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

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

Re: [gentoo-dev] bug #20201 and bbapm

[Ciaran McCreesh]

On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
wrote:
| bbapm has been masked due to no one responding with anything useful to
| last rites e-mail.  It will be punted in 30 days.

No no no. Do this properly. Clean up *all* the broken blackbox applets,
not just the one that has someone whining on a bug report. There are at
least two in the tree that're more broken than this.

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



signature.asc
Description: PGP signature

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

[Stephen Bennett]

On Mon, 27 Feb 2006 10:47:58 -0600
Lance Albertson <[EMAIL PROTECTED]> wrote:

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

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

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

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

[Renat Lumpau]

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

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


pgp8koU359mKC.pgp
Description: PGP signature

Re[2]: [gentoo-dev] bug #20201 and bbapm

[Jakub Moc]

27.2.2006, 18:23:09, Ciaran McCreesh wrote:

> On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | bbapm has been masked due to no one responding with anything useful to
> | last rites e-mail.  It will be punted in 30 days.

> No no no. Do this properly. Clean up *all* the broken blackbox applets,
> not just the one that has someone whining on a bug report. There are at
> least two in the tree that're more broken than this.

*Please*, be so kind and look at metadata.xml for those ebuild, then just
either do it *yourself* or ask someone from your fellow-devs in commonbox
herd to do it for the other ebuilds that you failed to mention above...
Don't move broken stuff on other people's shoulders, as you've already done
once.

I fail to see why are you claiming here that there's even more broken stuff
in the tree, yet as a member of maintainer herd haven't dealt with that
properly for quite an extensive period of time - and then you are asking
*other* people to do something "properly".

The fact that there are other ebuilds broken as well isn't any valid reason
for keeping this particular broken thing on portage. That way, nothing would
be punted from portage, ever.

TIA.


-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 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 ;)

pgpJ6oWCjQowX.pgp
Description: PGP signature

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

[Grant Goodyear]

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

My suspicion is that the more common problem is going to be inaccessible
developers, rather than uncooperative ones.  Certainly, if a maintainer
cannot be contacted, then I would prefer that QA fix the problem rather
than let it languish.  So, yes, I do believe that QA needs the ability
to go in and change any package that is broken.  (It's worth noting,
though, that every dev w/ tree access already has that ability, and the
only real issue is the amount of pain that will be inflicted on a dev
who changes packages both without permission and without skill.  Very
few devs will complain about somebody improving packages even without
permission as long as the improvement is done well.)

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

I'm somewhat ambivalent on this one on a couple of points, and the
nxserver case (bug #123926) hits both of them.  The first is that it
seems to me that in a case like this one, where the package involved is
a minor one that (I think) is not a dependency of any other packages,
the most that QA should do is hard mask the package w/ a clear note
pointing to the bug report, until some sort of resolution is achieved.
Removing the package would seem to be a bit much.  The second is the
fact that I don't really like seeing policy bounced to the council
unless absolutely necessary.  Just as was seen here, a discussion on
-dev might well lead to a reasonable compromise.  If it doesn't, then
the council can get involved.

Of course, that leaves the question of who decides on the severity of a
QA violation?  Well, I would suggest that the QA team does, at the risk
of getting publicly smacked down if they choose poorly.

-g2boojum-




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug #20201 and bbapm

[Stephen Bennett]

On Mon, 27 Feb 2006 18:54:13 +0100
Jakub Moc <[EMAIL PROTECTED]> wrote:

> yet as a member of maintainer herd haven't dealt with that 
> properly for quite an extensive period of time

Sounds like someone still needs to read herds.xml.
-- 
gentoo-dev@gentoo.org mailing list

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

Re: [gentoo-dev] bug #20201 and bbapm

[Ciaran McCreesh]

On Mon, 27 Feb 2006 18:54:13 +0100 Jakub Moc <[EMAIL PROTECTED]> wrote:
| *Please*, be so kind and look at metadata.xml for those ebuild, then
| just either do it *yourself* or ask someone from your fellow-devs in
| commonbox herd to do it for the other ebuilds that you failed to
| mention above... Don't move broken stuff on other people's shoulders,
| as you've already done once.
| 
| I fail to see why are you claiming here that there's even more broken
| stuff in the tree, yet as a member of maintainer herd haven't dealt
| with that properly for quite an extensive period of time - and then
| you are asking *other* people to do something "properly".

Did you read herds.xml yet?

Allow me to explain the root of the problem. You're so obsessed with
getting that one bug closed that you're not addressing the actual
issue, which is that the original bb* demo code was hideously wrong in
several places and thus there are a whole load of broken packages in
the tree.

Closing this one bug off will not, in the grand scheme of things, fix
anything. All it will do is give you a false sense of achievement and
make me or someone else file yet another "bb* is broken" bug. If you're
really looking to help here, solve the problem properly. There is more
to it than getting one bug closed.

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear <[EMAIL PROTECTED]>
wrote:
| Of course, that leaves the question of who decides on the severity of
| a QA violation?

All this talk of severity, and no talk of "ease of detection" or "ease
of fixing"...

Allow me to explain. There are certain not particularly high impact
issues that can very easily be detected, and with 100% reliability, by
The Thing About Which We Do Not Talk. Any individual one of these
doesn't look like such a big deal, but when we're talking a couple of
hundred instances, all of which can easily be fixed in less overall
time than it would take to even detect one instance of a particular
severe problem, it's most definitely worth concentrating on the 'easy'
issue.

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



signature.asc
Description: PGP signature

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

[Mark Loeser]

Grant Goodyear <[EMAIL PROTECTED]> said:
> Mark Loeser wrote:
> > * In case of emergency, or if package maintainers refuse to cooperate,
> >   the QA team may take action themselves to fix the problem.
> 
> My suspicion is that the more common problem is going to be inaccessible
> developers, rather than uncooperative ones.  Certainly, if a maintainer
> cannot be contacted, then I would prefer that QA fix the problem rather
> than let it languish.  So, yes, I do believe that QA needs the ability
> to go in and change any package that is broken.

We hope that it is never the case when someone refuses to cooperate, but
it is a possible situation we may likely have to deal with at some
point.

> > * In the event that a developer still insists that a package does not
> >   break QA standards, an appeal can be made at the next council meeting. The
> >   package should be dealt with per QA's request until such a time that a
> >   decision is made by the council.
> 
> I'm somewhat ambivalent on this one on a couple of points, and the
> nxserver case (bug #123926) hits both of them.  The first is that it
> seems to me that in a case like this one, where the package involved is
> a minor one that (I think) is not a dependency of any other packages,
> the most that QA should do is hard mask the package w/ a clear note
> pointing to the bug report, until some sort of resolution is achieved.
> Removing the package would seem to be a bit much.  The second is the
> fact that I don't really like seeing policy bounced to the council
> unless absolutely necessary.  Just as was seen here, a discussion on
> -dev might well lead to a reasonable compromise.  If it doesn't, then
> the council can get involved.

I agree.  With regards to the nxserver case, we said the package should
be removed if we could not come to a resolution.  We never said that we
were going to outright remove the package immediately.

It is not our goal, nor our intent, to go around and remove people's packages
from the tree.  This entire bullet point is really a worst case scenario when
all else breaks down.  The same with if there is a disagreement within the
majority of the QA team.  I don't foresee this occuring often, if at
all, but I felt it was important enough to address.


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


pgpBVWM0NwbfO.pgp
Description: PGP signature

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

[Donnie Berkholz]

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

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

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

Thanks,
Donnie



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] bug #20201 and bbapm

[Alec Warner]

Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
> wrote:
> | bbapm has been masked due to no one responding with anything useful to
> | last rites e-mail.  It will be punted in 30 days.
> 
> No no no. Do this properly. Clean up *all* the broken blackbox applets,
> not just the one that has someone whining on a bug report. There are at
> least two in the tree that're more broken than this.
> 

I am not the blackbox maintainer, nor do I wish to be.  In this
particular case I'm just tired of hearing Jakub and you go at it, and
since no one else acted, I chose to act.  Sorry if you thought otherwise.

-Alec Warner



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] SRC_URI component naming collision

[Robin H. Johnson]

On Mon, Feb 27, 2006 at 04:34:00PM +, Ciaran McCreesh wrote:
> On Mon, 27 Feb 2006 11:05:00 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> wrote:
> | Is there any valid reason that we can't have portage do this 
> | automatically. This particular way is very user-un-friendly.
> There's exactly one set of packages affected, and they're closed source
> and non-repackagable. I doubt it's high priority...
There's more than one set of packages with this.

There is only one set in the tree that don't use a workaround of some
sort (the NX stuff).

A quick hacked up grepping indicates that the following packages use the
trick of having the user rename the file after downloading it.
dev-java/ibm-jdk-bin 
dev-java/ibm-jre-bin
dev-java/jdbc2-oracle
dev-java/jdbc3-oracle
sci-chemistry/platon
There might be others, but I'm not looking too hard at the moment.

And I know I've used it in the past when upstream has been unreliable in
naming distfiles (eg they did thank me and add the major version portion
to the filename, but not the minor version, and still changed the
download once a week).

-- 
Robin Hugh Johnson
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpA3FYM8b1am.pgp
Description: PGP signature

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

[Stuart Herbert]

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

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

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

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

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

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

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

Best regards,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://blog.stuartherbert.com/

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



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] bug #20201 and bbapm

[Ciaran McCreesh]

On Mon, 27 Feb 2006 15:23:07 -0500 Alec Warner <[EMAIL PROTECTED]>
wrote:
| Ciaran McCreesh wrote:
| > On Mon, 27 Feb 2006 12:15:13 -0500 Alec Warner <[EMAIL PROTECTED]>
| > wrote:
| > | bbapm has been masked due to no one responding with anything
| > | useful to last rites e-mail.  It will be punted in 30 days.
| > 
| > No no no. Do this properly. Clean up *all* the broken blackbox
| > applets, not just the one that has someone whining on a bug report.
| > There are at least two in the tree that're more broken than this.
| 
| I am not the blackbox maintainer, nor do I wish to be.  In this
| particular case I'm just tired of hearing Jakub and you go at it, and
| since no one else acted, I chose to act.  Sorry if you thought
| otherwise.

Yeah, see, if it were as simple as just nuking the one app I'd've done
it a long time ago. Just killing one package is ignoring the real
problem here.

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



signature.asc
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

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

[Renat Lumpau]

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

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

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


pgpjUdTXxxgx0.pgp
Description: PGP signature

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

[Jakub Moc]

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

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

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


May I ask how is that related to webapp-config?


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

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:[EMAIL PROTECTED]
 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 ;)

pgpm1h2ln0Bno.pgp
Description: PGP signature

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

[Ciaran McCreesh]

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

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

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



signature.asc
Description: PGP signature

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

[Stuart Herbert]

On Mon, 2006-02-27 at 20:37 +, Ciaran McCreesh wrote:
> Then please start with bug 120088. Once that one's fixed we'll go from
> there.

That bug has nothing to do with webapp-config.  That bug is for PHP.
Could you file one that is, please?

Many thanks,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://blog.stuartherbert.com/

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



signature.asc
Description: This is a digitally signed message part

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

[Renat Lumpau]

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

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

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

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


pgp4PIRPm5jxH.pgp
Description: PGP signature

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

[Grant Goodyear]

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

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

-g2boojum-



signature.asc
Description: OpenPGP digital signature

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

[Stuart Herbert]

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

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

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

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

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

Best regards,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://blog.stuartherbert.com/

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



signature.asc
Description: This is a digitally signed message part

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

[Stephen P. Becker]

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

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

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