[gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Jeroen Roovers]

     Hi everybody,


I propose the `emerge --info` included in arch testers' comments on
stabilisation bugs should rather be posted as attachments. The AT
comments clog up the bugs and are usually not interesting at all to devs
other than those who are arch devs for the relevant arches. It would
certainly improve my RSI not to have to scroll past them.

On a minor note, I'd also like to see bug reporters use canonical
package names in bug descriptions, including the category (and
preferably the specific version, not some >=foo-3*!!!one, not to
mention specifying no version at all). Including the category means
arch devs won't need to guess/discover which of a few hundred categories
a package is meant to reside in.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Thomas Cort]

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

On Thu, 10 Aug 2006 19:50:55 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> I propose the `emerge --info` included in arch testers' comments on
> stabilisation bugs should rather be posted as attachments. The AT
> comments clog up the bugs and are usually not interesting at all to devs
> other than those who are arch devs for the relevant arches. It would
> certainly improve my RSI not to have to scroll past them.

Why do arch testers need to post `emerge --info` if everything works?
Shouldn't we be able to trust that they have sane CFLAGS, proper
FEATURES, and an up to date system?

> On a minor note, I'd also like to see bug reporters use canonical
> package names in bug descriptions, including the category (and
> preferably the specific version, not some >=foo-3*!!!one, not to
> mention specifying no version at all). Including the category means
> arch devs won't need to guess/discover which of a few hundred categories
> a package is meant to reside in.

I totally agree. An AT or arch team member should know which category,
package, and version to test from the bug summary alone.

-Thomas

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Kevin F. Quinn]

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

On Thu, 10 Aug 2006 14:44:13 -0400
Thomas Cort <tcort@gentoo.org> wrote:

> On Thu, 10 Aug 2006 19:50:55 +0200
> Jeroen Roovers <jer@gentoo.org> wrote:
> 
> > I propose the `emerge --info` included in arch testers' comments on
> > stabilisation bugs should rather be posted as attachments. The AT
> > comments clog up the bugs and are usually not interesting at all to
> > devs other than those who are arch devs for the relevant arches.

The problem with attachments is that processing the report takes longer
- you have to go to the web to read the attachment to find out what
config worked (or failed, if that was the case).  It's best to have it
in-line, I think.

If you're not interested in the AT emerge --info data, why are you
watching the stabilisation bug?

> > It would certainly improve my RSI not to have to scroll past them.
> 
> Why do arch testers need to post `emerge --info` if everything works?

So that you know what configuration worked.  This is useful information.

> Shouldn't we be able to trust that they have sane CFLAGS, proper
> FEATURES, and an up to date system?

It's not about trust, it's about knowing what the CFLAGS/FEATURES
were.  That way if someone else reports a failure, you can compare the
reports and see what differences might be triggering the fault.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Matti Bickel]

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

Thomas Cort <tcort@gentoo.org> wrote:
> Why do arch testers need to post `emerge --info` if everything works?
> Shouldn't we be able to trust that they have sane CFLAGS, proper
> FEATURES, and an up to date system?

Once there was the idea of putting AT testing system specs somewhere, so arch
devs could actually see what we're running. Is this still needed or is the
number of ATs small enough to keep that in head-RAM?

Anyways, I agree that posting emerge --info to a highly frequented stable bug
is annoying and should be abolished.
-- 
MfG, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Thomas Cort]

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

On Thu, 10 Aug 2006 23:58:46 +0200
"Kevin F. Quinn" <kevquinn@gentoo.org> wrote:

> It's not about trust, it's about knowing what the CFLAGS/FEATURES
> were.  That way if someone else reports a failure, you can compare the
> reports and see what differences might be triggering the fault.

I get that posting `emerge --info` provides a "known good" set of
CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at
times. However, we don't require that developers post their emerge
--info when a package works, so why do we require that ATs do it?

-Thomas

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Jeroen Roovers]

On Thu, 10 Aug 2006 23:58:46 +0200
"Kevin F. Quinn" <kevquinn@gentoo.org> wrote:

> The problem with attachments is that processing the report takes
> longer
> - you have to go to the web to read the attachment to find out what
> config worked (or failed, if that was the case).  It's best to have it
> in-line, I think.

The problem with inlining is that processing the info takes longer -
you have to wade through all the AT spam to find out what is being
changed over time. It's best to have it in attachments, I think.

Besides, you're wrong. ATs can add comments to attachments informing
their arch devs of success or failure, and name the `emerge info`
attachment properly so everybody knows what the attachment actually is
(and when to ignore it).

> If you're not interested in the AT emerge --info data, why are you
> watching the stabilisation bug?

Because as an arch dev not on an AT-equipped arch, I still need to find
the interesting-not-your-arch-info between all the your-arch-cruft.

All these `emerge info` comments are completely irrelevant to every
arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs'
preparations have their work cut out for them, it seems, having all
that info in their mailbox, while non-AT arches have to fork through
all the spam, both in their mailboxes and on bugs.g.o, to get to the
good bits (ouch, sparc beat us again, must stabilise before mips!).

Inlining emerge info in comments bloats the e-mail message to roughly
2.5 times the normal size. I could have spoken out to get AT comments
banned altogether or to urge arches with AT teams to find a proper
technical solution to communicate outside of bugs.g.o. I think using
attachments instead of inlining is a pretty good temporary solution to
a communication problem that has for now been solved by making every
stabilisation bug report a dumping ground for a ton of information that
becomes obsolete within a few days.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Chris Gianelloni]

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

On Thu, 2006-08-10 at 18:29 -0400, Thomas Cort wrote:
> On Thu, 10 Aug 2006 23:58:46 +0200
> "Kevin F. Quinn" <kevquinn@gentoo.org> wrote:
> 
> > It's not about trust, it's about knowing what the CFLAGS/FEATURES
> > were.  That way if someone else reports a failure, you can compare the
> > reports and see what differences might be triggering the fault.
> 
> I get that posting `emerge --info` provides a "known good" set of
> CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at
> times. However, we don't require that developers post their emerge
> --info when a package works, so why do we require that ATs do it?

Honestly, it might be sufficient to only post 'emerge --info' when it
*doesn't* work.  If we need corroboration from someone where it did
work, we can ask.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Ferris McCormick]

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

On Thu, 10 Aug 2006, Matti Bickel wrote:

> Thomas Cort <tcort@gentoo.org> wrote:
>> Why do arch testers need to post `emerge --info` if everything works?
>> Shouldn't we be able to trust that they have sane CFLAGS, proper
>> FEATURES, and an up to date system?
>
> Once there was the idea of putting AT testing system specs somewhere, so arch
> devs could actually see what we're running. Is this still needed or is the
> number of ATs small enough to keep that in head-RAM?
>

Unless this causes problems for people, I'd like to be able to find it. 
As you see from my signature, I'm extrapolating from sparc here, but on 
sparc, at least, the specs and configuration of a failing system (or of a 
system which cannot be made to fail) is sometimes highly relevant.

Having this sort of information can't hurt and might help, so I'd ask 
please provide it someplace if convenient.

> Anyways, I agree that posting emerge --info to a highly frequented stable bug
> is annoying and should be abolished.

Yes.  Well, if you say everything is good, I just don't read it.  I 
sometimes compromise on bugs and give a two or three line indication of 
just which system(s) I am reporting on.  If people want more information, 
they can ask me or go to a summary page sparc maintains --- all my systems 
are described there.

> -- 
> MfG, Matti Bickel
> Homepage: http://www.rateu.de
> Encrypted/Signed Email preferred
>

Regards,
Ferris

- --
Ferris McCormick (P44646, MI) <fmccor@gentoo.org>
Developer, Gentoo Linux (Devrel, Sparc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux)

iD8DBQFE28DyQa6M3+I///cRAqWRAKCSzbmYM8G16DzXuqdUHbYgVnivsQCgyVqS
mO5HEmm6oc3yrqfX0IfrMug=
=T6kP
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Christian 'Opfer' Faulhammer]

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

Tach Matti,                                  0x2B859DE3 (PGP-PK-ID)

Matti Bickel schrieb:
> Once there was the idea of putting AT testing system specs somewhere, so
> arch devs could actually see what we're running. Is this still needed or
> is the number of ATs small enough to keep that in head-RAM?

 The problem is that at least USE flags change relatively fast overtime  
and there are slight differences.  When you compare a bug from July 06 and  
have a look at the emerge --info that has been updated August 06, it can  
be somewhat misleading.

> Anyways, I agree that posting emerge --info to a highly frequented
> stable bug is annoying and should be abolished.

 Do you have a proposition how to provide the same "functionality"?

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/

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

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Christian 'Opfer' Faulhammer]

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

Tach Jeroen,                                  0x2B859DE3 (PGP-PK-ID)

Jeroen Roovers schrieb:
> Inlining emerge info in comments bloats the e-mail message to roughly
> 2.5 times the normal size. I could have spoken out to get AT comments
> banned altogether or to urge arches with AT teams to find a proper
> technical solution to communicate outside of bugs.g.o. I think using
> attachments instead of inlining is a pretty good temporary solution to a
> communication problem that has for now been solved by making every
> stabilisation bug report a dumping ground for a ton of information that
> becomes obsolete within a few days.

 Basically you are right about "cruft", but the information the ATs submit  
should be accessible to everyone so the actual solution without  
attachments (because of more work) is the bestTM.  What other ways of  
communication between ATs and devs do you propose?  Some kind of arch  
Bugzilla? IMO it should be permanent with a link from the stabilisation  
bug so that everyone (devs, users, ATs) can follow the path of  
stabilisation.



V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/

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

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Christian 'Opfer' Faulhammer]

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

Tach Jeroen,                                  0x2B859DE3 (PGP-PK-ID)

Jeroen Roovers schrieb:
> I propose the `emerge --info` included in arch testers' comments on
> stabilisation bugs should rather be posted as attachments. The AT
> comments clog up the bugs and are usually not interesting at all to devs
> other than those who are arch devs for the relevant arches. It would
> certainly improve my RSI not to have to scroll past them.

 And when there is a problem, attachments have to be opened...some more  
steps, especially when there have been a dozen testers and their info has  
to be filtered out of the attachment list.

> On a minor note, I'd also like to see bug reporters use canonical
> package names in bug descriptions, including the category (and
> preferably the specific version, not some >=foo-3*!!!one, not to mention
> specifying no version at all). Including the category means arch devs
> won't need to guess/discover which of a few hundred categories a package
> is meant to reside in.

 Seconded.

V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/

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

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Christian 'Opfer' Faulhammer]

Tach Jeroen,                                  0x2B859DE3 (PGP-PK-ID)

Jeroen Roovers schrieb:
> One solution might be to open your own AT bug, make the stabilisation
> bug depend on it, and use the AT bug to have ATs post their `emerge
> info`. Then, when testing and stabilisation is finished for your arch,
> close the AT bug and remove your alias from the stabilisation bug's CC
> list. I for one could live with this solution to the problem, which I
> hope you understand by now.

 This sounds quite interesting...maybe some arch devs should comment on  
that.  The only problem I see is when two ATs test at the same time and  
open two separate bugs for the same arch.  And another problem: Other  
arches don't see the problems in the depending bug and are unlikely to  
comment on it.



V-Li

-- 
Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3
http://www.gnupg.org/
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Duncan]

Matti Bickel <kabel@cat0.de> posted 20060810215951.GA8456@pluto.athome,
excerpted below, on  Thu, 10 Aug 2006 23:59:51 +0200:

> Thomas Cort <tcort@gentoo.org> wrote:
>> Why do arch testers need to post `emerge --info` if everything works?
>> Shouldn't we be able to trust that they have sane CFLAGS, proper
>> FEATURES, and an up to date system?
> 
> Once there was the idea of putting AT testing system specs somewhere, so arch
> devs could actually see what we're running. Is this still needed or is the
> number of ATs small enough to keep that in head-RAM?
> 
> Anyways, I agree that posting emerge --info to a highly frequented stable bug
> is annoying and should be abolished.

Even back before it became the "in" thing, I was posting emerge --info as
attachments, because it simply fit the bill -- bugzy /says/ to put long
stuff as attachments.  I never did quite understand why all that
admittedly often useful high-volume spew was tolerated in the bug comments
themselves.

I like the idea above, tho.  For ATs especially, having some place where
emerge --info could be posted just once, with a link to it instead of the
duplicated inline /or/ attachment, makes even more sense.  Presumably,
where it's posted could have dated versions, too, allowing for updated
flags without invalidating the info pointed to for older links.  If
variation off the norm was needed or used for an individual package, that
could be noted in the comments along with the link to the standard info.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Kevin F. Quinn]

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

On Fri, 11 Aug 2006 04:56:18 +0000 (UTC)
"Duncan" <1i5t5.duncan@cox.net> wrote:

> Even back before it became the "in" thing, I was posting emerge
> --info as attachments, because it simply fit the bill -- bugzy /says/
> to put long stuff as attachments.  I never did quite understand why
> all that admittedly often useful high-volume spew was tolerated in
> the bug comments themselves.

Personally I find it a lot easier to read a bug when the emerge --info
data from people is inline.  Frequently, the trigger for a bug becomes
apparent when you compare the emerge --info of the various people who
see a bug, and it's a moment's effort to scroll up and down the bug to
compare data.  This process takes longer if the info is in a bunch of
attachments.

[re. posting AT configs somewhere]
> I like the idea above, tho.  For ATs especially, having some place
> where emerge --info could be posted just once, with a link to it
> instead of the duplicated inline /or/ attachment, makes even more
> sense.  Presumably, where it's posted could have dated versions, too,
> allowing for updated flags without invalidating the info pointed to
> for older links.  If variation off the norm was needed or used for an
> individual package, that could be noted in the comments along with
> the link to the standard info.

I think the info changes frequently enough that it's easier, and more
likely to be correct, if it's posted to the bug at the time the report
is made.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Kevin F. Quinn]

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

On Fri, 11 Aug 2006 00:51:56 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Thu, 10 Aug 2006 23:58:46 +0200
> "Kevin F. Quinn" <kevquinn@gentoo.org> wrote:
> 
> > The problem with attachments is that processing the report takes
> > longer
> > - you have to go to the web to read the attachment to find out what
> > config worked (or failed, if that was the case).  It's best to have
> > it in-line, I think.
> 
> The problem with inlining is that processing the info takes longer -

In general it depends what you're doing.  Personally I find inline
emerge --info quicker to process, as I tend to do that by scrolling up
and down a bug when trying to determine what triggers a bug.  However
that's for "normal" bugs - I don't spend much time on stabilisation
bugs.

> you have to wade through all the AT spam to find out what is being
> changed over time. It's best to have it in attachments, I think.
> 
> Besides, you're wrong. ATs can add comments to attachments informing
> their arch devs of success or failure, and name the `emerge info`
> attachment properly so everybody knows what the attachment actually is
> (and when to ignore it).

In what way am I wrong?  I never said AT's can't add comments.

Effectively what you're saying is transcribe the emerge info into the
attachment name and attachment comment - which effectively makes it
in-line again.  Obviously only a tiny part of that can actually be put
in the attachment name, and there's little point to putting stuff in
the attachment comment unless it's highly redacted - how is the AT
going to decide what information is significant?

Rule 1 in problem reporting - report your exact configuration and
exactly what you see, in the first instance, do not attempt to
interpret until you have that data recorded.

> > If you're not interested in the AT emerge --info data, why are you
> > watching the stabilisation bug?
> 
> Because as an arch dev not on an AT-equipped arch, I still need to
> find the interesting-not-your-arch-info between all the
> your-arch-cruft.

Not sure I understand.  Stabilisation bugs shouldn't be doing problem
resolution; if a bug is found during stabilisation testing it should be
raised as a normal bug and set as a dependency of the stabilisation bug.
If people are using stabilisation bugs for development/bug fixing then
they should stop doing so.

> All these `emerge info` comments are completely irrelevant to every
> arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs'
> preparations have their work cut out for them, it seems, having all
> that info in their mailbox, while non-AT arches have to fork through
> all the spam, both in their mailboxes and on bugs.g.o, to get to the
> good bits (ouch, sparc beat us again, must stabilise before mips!).
> 
> Inlining emerge info in comments bloats the e-mail message to roughly
> 2.5 times the normal size.

Well, it adds around 40 lines - I don't see that as a problem.  It's a
good idea if the emerge info output is placed after whatever comment is
being made, so that if you don't care about it you can just skip to
the next message.

> I could have spoken out to get AT comments
> banned altogether or to urge arches with AT teams to find a proper
> technical solution to communicate outside of bugs.g.o. I think using
> attachments instead of inlining is a pretty good temporary solution to
> a communication problem that has for now been solved by making every
> stabilisation bug report a dumping ground for a ton of information
> that becomes obsolete within a few days.

Stabilisation bugs by their very nature are temporary - they are
active for the time it takes to decide a package can be marked stable.
Once the package version is marked stable, the bug should be closed.  I
don't see what the communication problem is.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Jeroen Roovers]

On Fri, 11 Aug 2006 12:52:30 +0200
"Kevin F. Quinn" <kevquinn@gentoo.org> wrote:

> In general it depends what you're doing.  Personally I find inline
> emerge --info quicker to process, as I tend to do that by scrolling up
> and down a bug when trying to determine what triggers a bug.  However
> that's for "normal" bugs - I don't spend much time on stabilisation
> bugs.

"Personally" is meaningless in this context. The inline `emerge info`
is quicker to process for you, not for other-arch devs out there. For
them the info is useless. Stabilisation bugs in this context are bugs
CC'd to many arch aliases (see below for a possible solution).

> > you have to wade through all the AT spam to find out what is being
> > changed over time. It's best to have it in attachments, I think.
> > 
> > Besides, you're wrong. ATs can add comments to attachments informing
> > their arch devs of success or failure, and name the `emerge info`
> > attachment properly so everybody knows what the attachment actually
> > is (and when to ignore it).
> 
> In what way am I wrong?  I never said AT's can't add comments.

ATs can inform you whether something works in the comment to an
attachment, which, unlike the attachment, will end up in my mailbox. I
have no problems with short comments like:


  ------- Comment #5 from jer@gentoo.org  2006-08-01 02:47 PST -------
  Created an attachment (id=93193)
   --> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
  emerge info

  Works Great!!!1omg


> Effectively what you're saying is transcribe the emerge info into the
> attachment name and attachment comment - which effectively makes it
> in-line again.

No, I meant put the `emerge info` in the attachment, describe the
attachment properly ("emerge info" would do) and comment on the
attachment submission with a statement pertaining to the success or
failure of the test run. This can all be achieved in a single submit
and it doesn't burden arch devs and bugzilla with lengthy comments.

> Rule 1 in problem reporting - report your exact configuration and
> exactly what you see, in the first instance, do not attempt to
> interpret until you have that data recorded.

Could you consider having ATs report the exact configuration
elsewhere? In normal bugs, encouraging users to post their emerge info
is a good thing. In stabilisation bugs, with well-instructed ATs
posting comments, there's no need to do all that.

> Not sure I understand.  Stabilisation bugs shouldn't be doing problem
> resolution; if a bug is found during stabilisation testing it should
> be raised as a normal bug and set as a dependency of the
> stabilisation bug. If people are using stabilisation bugs for
> development/bug fixing then they should stop doing so.

N/A

Stabilisation bugs should be short and simple. If the stabilisation
target changes half way through (a revision bump perhaps, which
happens quite often, or an extra dep, which happens quite often as
well), arch devs need to be able to find that information quickly.

> Well, it adds around 40 lines - I don't see that as a problem.  It's a
> good idea if the emerge info output is placed after whatever comment
> is being made, so that if you don't care about it you can just skip to
> the next message.

Erm. It is a problem - I've explained why. It adds bloat and it clogs
many arch devs' mailboxen with tons of useless info. Merrily skipping
past it is impossible when a bug spans 5 instead of 2 pages because
of 3 AT comments, interspersed with possibly useful comments. I guess
you would feel the same way if I started inlining `emerge info` for all
my HPPA systems. You'd have to parse each one of them just to find your
own ATs' `emerge info` among mine.

> Stabilisation bugs by their very nature are temporary - they are
> active for the time it takes to decide a package can be marked stable.
> Once the package version is marked stable, the bug should be closed.
> I don't see what the communication problem is.

Your communication problem used to be that you want the AT's info
ready to use. Your solution was to have ATs inline `emerge info` in bug
comments. This solution benefits only you, not other arches's devs, and
in fact, it annoys them. Please find a better solution.

One solution might be to open your own AT bug, make the stabilisation
bug depend on it, and use the AT bug to have ATs post their `emerge
info`. Then, when testing and stabilisation is finished for your arch,
close the AT bug and remove your alias from the stabilisation bug's CC
list. I for one could live with this solution to the problem, which I
hope you understand by now.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Kevin F. Quinn]

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

On Fri, 11 Aug 2006 13:40:23 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> On Fri, 11 Aug 2006 12:52:30 +0200
> "Kevin F. Quinn" <kevquinn@gentoo.org> wrote:
> 
> > In general it depends what you're doing.  Personally I find inline
> > emerge --info quicker to process, as I tend to do that by scrolling
> > up and down a bug when trying to determine what triggers a bug.
> > However that's for "normal" bugs - I don't spend much time on
> > stabilisation bugs.
> 
> "Personally" is meaningless in this context.

"Personally" is critical.  Part of my point was that whatever way it's
done, it will be better for some and worse for others.  In other words,
what is "better" is subjective.  In order to decide to change how
things are currently done, you need to show that it is better for a
majority of the people affected.

> The inline `emerge info`
> is quicker to process for you, not for other-arch devs out there. For
> them the info is useless.  Stabilisation bugs in this context are
> bugs CC'd to many arch aliases (see below for a possible solution).
> 
> > > you have to wade through all the AT spam to find out what is being
> > > changed over time. It's best to have it in attachments, I think.
> > > 
> > > Besides, you're wrong. ATs can add comments to attachments
> > > informing their arch devs of success or failure, and name the
> > > `emerge info` attachment properly so everybody knows what the
> > > attachment actually is (and when to ignore it).
> > 
> > In what way am I wrong?  I never said AT's can't add comments.
> 
> ATs can inform you whether something works in the comment to an
> attachment, which, unlike the attachment, will end up in my mailbox. I
> have no problems with short comments like:
> 
> 
>   ------- Comment #5 from jer@gentoo.org  2006-08-01 02:47 PST -------
>   Created an attachment (id=93193)
>    --> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
>   emerge info
> 
>   Works Great!!!1omg

ok; that makes better sense.

> > Effectively what you're saying is transcribe the emerge info into
> > the attachment name and attachment comment - which effectively
> > makes it in-line again.
> 
> No, I meant put the `emerge info` in the attachment, describe the
> attachment properly ("emerge info" would do) and comment on the
> attachment submission with a statement pertaining to the success or
> failure of the test run. This can all be achieved in a single submit
> and it doesn't burden arch devs and bugzilla with lengthy comments.

Doesn't make the slightest difference to the burden on bugzilla,
whether they're inline or attachments.

Whether it's a burden on arch devs or not, you'd have to poll. 

If you do go this route, I suggest the attachment title be "PASS
(emerge info)" or "FAIL (emerge info)"; easier to parse the attachment
list.  Also allows you to process email by just the subject header.

> > Rule 1 in problem reporting - report your exact configuration and
> > exactly what you see, in the first instance, do not attempt to
> > interpret until you have that data recorded.
> 
> Could you consider having ATs report the exact configuration
> elsewhere? In normal bugs, encouraging users to post their emerge info
> is a good thing. In stabilisation bugs, with well-instructed ATs
> posting comments, there's no need to do all that.

Well, I do think the report of the configuration the AT had at the time
of the test should be held as close as possible to the place where it
has relevance.  As far as this point is concerned, having it as an
attachment is fine.  Having it posted on some website somewhere else as
others have suggested is a bad idea, I think.

> > Not sure I understand.  Stabilisation bugs shouldn't be doing
> > problem resolution; if a bug is found during stabilisation testing
> > it should be raised as a normal bug and set as a dependency of the
> > stabilisation bug. If people are using stabilisation bugs for
> > development/bug fixing then they should stop doing so.
> 
> N/A
> 
> Stabilisation bugs should be short and simple. If the stabilisation
> target changes half way through (a revision bump perhaps, which
> happens quite often, or an extra dep, which happens quite often as
> well), arch devs need to be able to find that information quickly.
> 
> > Well, it adds around 40 lines - I don't see that as a problem.
> > It's a good idea if the emerge info output is placed after whatever
> > comment is being made, so that if you don't care about it you can
> > just skip to the next message.
> 
> Erm. It is a problem - I've explained why. It adds bloat and it clogs
> many arch devs' mailboxen with tons of useless info. Merrily skipping
> past it is impossible when a bug spans 5 instead of 2 pages because
> of 3 AT comments, interspersed with possibly useful comments. I guess
> you would feel the same way if I started inlining `emerge info` for
> all my HPPA systems. You'd have to parse each one of them just to
> find your own ATs' `emerge info` among mine.

I don't understand how you're getting many pages in one email - surely
each report by an AT is a separate comment and hence a separate
email, looking like:

----
From: Mr Test
Subject: Stabilisation of <CPV>

Works Great!!!1omg

emerge info:
<40 lines>
----

and that's all.  If it's of no interest to you, surely you just use
"delete and next" rather than "mark read and next", whatever they are
in your email reader.

> > Stabilisation bugs by their very nature are temporary - they are
> > active for the time it takes to decide a package can be marked
> > stable. Once the package version is marked stable, the bug should
> > be closed. I don't see what the communication problem is.
> 
> Your communication problem used to be that you want the AT's info
> ready to use. Your solution was to have ATs inline `emerge info` in
> bug comments. This solution benefits only you, not other arches's
> devs, and in fact, it annoys them. Please find a better solution.

I'll take "you" to mean "arch team members of arches with ATs" (rubbish
language, English).  I don't have a problem as things stand now.  I
might have a problem if all emerge info ends up in attachments (not
just for stabilisation bugs). To be honest, what goes on for
stabilisation bugs isn't of any direct concern to me as I don't involve
myself in stabilisation, but if you change the rule there it's likely
to be the rule across all of bugzilla and then it does concern me.

> One solution might be to open your own AT bug, make the stabilisation
> bug depend on it, and use the AT bug to have ATs post their `emerge
> info`. Then, when testing and stabilisation is finished for your arch,
> close the AT bug and remove your alias from the stabilisation bug's CC
> list. I for one could live with this solution to the problem, which I
> hope you understand by now.

Another idea is for ATs to attach emerge info if the package passes for
them, but in-line it if it fails.  If the package fails on one arch for
a given set of USE/FEATURES, other arches may well be interested to
check if the failure also affects them.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Thomas Cort]

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

On 11 Aug 2006 00:00:00 +0000
gentoo@faulhammer.org (Christian 'Opfer' Faulhammer) wrote:

> Tach Jeroen,                                  0x2B859DE3 (PGP-PK-ID)
> 
> Jeroen Roovers schrieb:
> > One solution might be to open your own AT bug, make the stabilisation
> > bug depend on it, and use the AT bug to have ATs post their `emerge
> > info`. Then, when testing and stabilisation is finished for your arch,
> > close the AT bug and remove your alias from the stabilisation bug's CC
> > list. I for one could live with this solution to the problem, which I
> > hope you understand by now.
> 
>  This sounds quite interesting...maybe some arch devs should comment on  
> that.  The only problem I see is when two ATs test at the same time and  
> open two separate bugs for the same arch.  And another problem: Other  
> arches don't see the problems in the depending bug and are unlikely to  
> comment on it.

Besides the points you mentioned, it would create a lot of bug
spam. There would be the "a new bug depends on this bug" e-mail when
the AT files the bug, then there would be the "a bug that depends on this
bug has changed state" e-mail when the arch dev closes the AT's
bug, and then there would be the e-mail from the arch dev when he/she
comments on the original bug saying "arch-xyz stable"

-Thomas

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Matti Bickel]

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

Jeroen Roovers <jer@gentoo.org> wrote:
> ATs can inform you whether something works in the comment to an
> attachment, which, unlike the attachment, will end up in my mailbox.

Ok, so i sample my emerge --info > myconfig.txt and attach that. This is ok
with me. However, i propose that this functionality is included into pybugz,
which already offers inlining emerge --info. That would speed up the process
tremendously (thanks liquidx!).

> One solution might be to open your own AT bug, make the stabilisation
> bug depend on it, and use the AT bug to have ATs post their `emerge
> info`.

I disagree. That adds complexity and thus increases time spent on bugzi w/o
actual benefit for the overall dev-community. I'd rather go w/ posting emerge
--info as a attachment.
-- 
MfG, Matti Bickel
Homepage: http://www.rateu.de
Encrypted/Signed Email preferred

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Jeroen Roovers]

On Fri, 11 Aug 2006 15:25:11 +0200
"Kevin F. Quinn" <kevquinn@gentoo.org> wrote:

> In order to decide to change how things are currently done, you need
> to show that it is better for a majority of the people affected.

(N minus 1 of N arches) times (the number of arch devs minus the number
of $ARCH devs) are affected.

The difference in comfort versus annoyance is even greater when you
consider that only one arch dev per AT-equipped arch is likely to look
at it and make the stabilisation judgment and then take action. That's
N -1 arch dev's comfort against N arch devs' annoyance[1].

> > No, I meant put the `emerge info` in the attachment, describe the
> > attachment properly ("emerge info" would do) and comment on the
> > attachment submission with a statement pertaining to the success or
> > failure of the test run. This can all be achieved in a single submit
> > and it doesn't burden arch devs and bugzilla with lengthy comments.
> 
> Doesn't make the slightest difference to the burden on bugzilla,
> whether they're inline or attachments.

Note that I specifically said "with lengthy comments".

> Whether it's a burden on arch devs or not, you'd have to poll. 

Mailing 2.4kB instead 5kB to many dozens of people sure constitutes a
smaller burden on bugzilla and on dev.gentoo.org, wrt the
attachment solution, and on all the arch devs to whom the information is
useless.

Alternatively, wrt the AT bug solution, mailing 5kB to $ARCH@g.o (arch
devs and ATs for one arch) instead of mailing same to $ARCHES@g.o (all
arch devs and ATs for all arches) makes a pretty big difference.

> If you do go this route, I suggest the attachment title be "PASS
> (emerge info)" or "FAIL (emerge info)"; easier to parse the attachment
> list.  Also allows you to process email by just the subject header.

Suits me.

> Well, I do think the report of the configuration the AT had at the
> time of the test should be held as close as possible to the place
> where it has relevance.  As far as this point is concerned, having it
> as an attachment is fine.  Having it posted on some website somewhere
> else as others have suggested is a bad idea, I think.

Back to the attachments solution, then.

> I don't understand how you're getting many pages in one email - surely
> each report by an AT is a separate comment and hence a separate
> email, looking like:
> 
> ----
> From: Mr Test
> Subject: Stabilisation of <CPV>
> 
> Works Great!!!1omg
> 
> emerge info:
> <40 lines>
> ----
> 
> and that's all.  If it's of no interest to you, surely you just use
> "delete and next" rather than "mark read and next", whatever they are
> in your email reader.

It's 40 lines too many. That's the problem, both on bugs.g.o and in my
mailbox.

> To be honest, what goes on for stabilisation bugs isn't of any direct
> concern to me as I don't involve myself in stabilisation, but if you
> change the rule there it's likely to be the rule across all of
> bugzilla and then it does concern me.

I explained from the outset that this change pertains to stabilisation
bugs. If you are not an arch dev, then why are you taking the opposite
side in a discussion of stabilisation bugs which by their very nature
only pertain to arch devs? I sure hope you didn't just knee jerk when
you read the message subject. Here is the original first sentence of
the first message in this thread:

  I propose the `emerge --info` included in arch testers' comments on
  stabilisation bugs should rather be posted as attachments.

Any more questions? :-/

> Another idea is for ATs to attach emerge info if the package passes
> for them, but in-line it if it fails.  If the package fails on one
> arch for a given set of USE/FEATURES, other arches may well be
> interested to check if the failure also affects them.

If it fails, the AT should open a separate bug and make the
stabilisation bug depend on it. You said so yourself:

"Stabilisation bugs shouldn't be doing problem resolution; if a bug is
found during stabilisation testing it should be raised as a normal bug
and set as a dependency of the stabilisation bug."

I absolutely agree with this. I assume now that you agree with me that
debugging info, including `emerge info`, should *never* be inlined in,
or even attached to, stabilisation bugs.


Kind regards,
     JeR


[1] Note that I am aware that not all other-arch devs might experience
inline `emerge info` for other arches as annoying.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Chris Gianelloni]

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

On Fri, 2006-08-11 at 16:46 +0200, Jeroen Roovers wrote:
> N -1 arch dev's comfort against N arch devs' annoyance[1].

<big snip>

> [1] Note that I am aware that not all other-arch devs might experience
> inline `emerge info` for other arches as annoying.

I am on the alpha, amd64, and x86 arch teams.  I have found that even
emails from architectures I'm not currently looking at tend to have a
great significance.  It seems to me that most of the failures are
USE-flag related more than architecture specific.  As I said, the best
solution that I can see to do *both* reducing junk and still keeping the
information inline is to have the ATs only add emerge --info on
failures, and to just mention the architecture and *relevant" USE on
success.

ex.

gcc 4.1.1 works on x86 with the following:

USE="gtk nls -bootstrap -build -doc -fortran -gcj -hardened -ip28
-ip32r10k -mudflap -multislot -nocxx -objc -objc++ -objc-gc -test
-vanilla"

This still gives us most of the pertinent information without the rest
of the "spam" of emerge --info.  It makes the emails from bugzilla still
usable for those of us that don't waste the time to open up bugzilla for
every bug.  I do most of my bug management via email.  I open the bug
*only* when I need to comment, or after I've performed the work
requested.  Having to open the bug every time would be a complete waste
of time for me.  Much more so than simply *deleting* an email that
doesn't pertain to me, or scrolling past unimportant information.

I would find that this change would be disruptive to my ability to work
on these architecture teams.  As stated before, sometimes another
architecture's problem can point you at something to test.  If a certain
USE combination doesn't work on x86, wouldn't you want to test it on
hppa specifically to make sure that it isn't a global issue?  I know
that I sure test any combinations from $other_arches when testing for a
given $arch, if they've reported a failure.

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Kevin F. Quinn]

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

On Fri, 11 Aug 2006 16:46:33 +0200
Jeroen Roovers <jer@gentoo.org> wrote:

> I explained from the outset that this change pertains to stabilisation
> bugs. If you are not an arch dev, then why are you taking the opposite
> side in a discussion of stabilisation bugs which by their very nature
> only pertain to arch devs?

Well, first off you asked for comments; "RFC".  If I have something to
say, I'll say it, even if I'm not immediately affected.  You don't have
to agree, or even pay attention ;)  That said, as I described in my
previous email, my concern was that if it becomes policy to attach
`emerge --info` instead of inline for stabilisation bugs, that policy
might expand to all bugs which would have a negative impact for me.
However if the rule is only for "pass" `emerge --info` data then I
don't object.

> > Another idea is for ATs to attach emerge info if the package passes
> > for them, but in-line it if it fails.  If the package fails on one
> > arch for a given set of USE/FEATURES, other arches may well be
> > interested to check if the failure also affects them.
> 
> If it fails, the AT should open a separate bug and make the
> stabilisation bug depend on it.

Good point.  

> You said so yourself:
> 
> "Stabilisation bugs shouldn't be doing problem resolution; if a bug is
> found during stabilisation testing it should be raised as a normal bug
> and set as a dependency of the stabilisation bug."
> 
> I absolutely agree with this. I assume now that you agree with me that
> debugging info, including `emerge info`, should *never* be inlined in,
> or even attached to, stabilisation bugs.

Yes.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Jeroen Roovers]

On Fri, 11 Aug 2006 11:27:29 -0400
Chris Gianelloni <wolf31o2@gentoo.org> wrote:

> I am on the alpha, amd64, and x86 arch teams.  I have found that even
> emails from architectures I'm not currently looking at tend to have a
> great significance.  It seems to me that most of the failures are
> USE-flag related more than architecture specific.  As I said, the best
> solution that I can see to do *both* reducing junk and still keeping
> the information inline is to have the ATs only add emerge --info on
> failures, and to just mention the architecture and *relevant" USE on
> success.

And do you propose ATs still attach `emerge info` in this solution?

> ex.
> 
> gcc 4.1.1 works on x86 with the following:
> 
> USE="gtk nls -bootstrap -build -doc -fortran -gcj -hardened -ip28
> -ip32r10k -mudflap -multislot -nocxx -objc -objc++ -objc-gc -test
> -vanilla"

Looks OK to me. But hey, aren't arch devs and testers alike supposed to
test (almost) all flags? And also, wouldn't you also want to know about
FEATURES, specifically FEATURES='{test,collision-detect}'? How about
KEYWORDS? You would still need to be able to find the full `emerge info`
in an attachment, I guess.

> This still gives us most of the pertinent information without the rest
> of the "spam" of emerge --info.  It makes the emails from bugzilla
> still usable for those of us that don't waste the time to open up
> bugzilla for every bug.  I do most of my bug management via email.  I
> open the bug *only* when I need to comment, or after I've performed
> the work requested.  Having to open the bug every time would be a
> complete waste of time for me.  Much more so than simply *deleting*
> an email that doesn't pertain to me, or scrolling past unimportant
> information.

So we are still looking for a compromise that will place the burden on
the $arch ADs and ATs, not the $other_arch devs, right? Currently it's
basically a mindless integral copy/paste action which benefits only a
few.

> I would find that this change would be disruptive to my ability to
> work on these architecture teams.  As stated before, sometimes another
> architecture's problem can point you at something to test.  If a
> certain USE combination doesn't work on x86, wouldn't you want to
> test it on hppa specifically to make sure that it isn't a global
> issue?  I know that I sure test any combinations from $other_arches
> when testing for a given $arch, if they've reported a failure.

I still think failures should be reported in separate bugs, as they are
likely to cause lots more information to be passed.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Joshua Jackson]

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


>> ex.
>>
>> gcc 4.1.1 works on x86 with the following:
>>
>> USE="gtk nls -bootstrap -build -doc -fortran -gcj -hardened -ip28
>> -ip32r10k -mudflap -multislot -nocxx -objc -objc++ -objc-gc -test
>> -vanilla"
>
> Looks OK to me. But hey, aren't arch devs and testers alike supposed to
> test (almost) all flags? And also, wouldn't you also want to know about
> FEATURES, specifically FEATURES='{test,collision-detect}'? How about
> KEYWORDS? You would still need to be able to find the full `emerge info`
> in an attachment, I guess.
Heck no, I'd spend a few weeks just testing for example php. That's
deranged at its best and insane at the worst. The request as put out
to the arch testers is to use the system like they use any system,
just that they only run x86, amd64 other packages except for what they
are going to be testing. As far as features go we ask that they run
the same as a developer should, test collision-protect on top of what
is already added by default. Keywords is not useful for the arch teams
as we know that the AT's run $arch and not ~$arch. However at least
saying x86 okie with me here would be a requirement
>
> I still think failures should be reported in separate bugs, as they are
> likely to cause lots more information to be passed.
>
>
> Kind regards,
>      JeR


Actually, one thing that you might not know is that quite a few of the
archtesters are capable programmers, they've tested a build that
failed and went about submitting a patch that would fix the issue
right there on the stabilization bug. Now you might want to say why
are they not developers yet. Part of that is probably, because they
haven't been approached by a developer yet, the second is that some
can't dedicate more time then what they are doing currently to help
the project, and that is alright. They are helping the arch teams
immensely and I'm thankful for them taking their own time to be doing
what they are doing. I might not always say thank you on the bugs,
however I feel it everyday.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE3K8uSENan+PfizARAlacAJ4mb/pTvX119A+41a0qVG8SE3IrcQCfaOSn
iMxOOBGJCXGxZfU+4BeB3Zg=
=fbsi
-----END PGP SIGNATURE-----

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Chris Gianelloni]

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

On Fri, 2006-08-11 at 18:00 +0200, Jeroen Roovers wrote:
> And do you propose ATs still attach `emerge info` in this solution?

No.  It really should be inline.  I'm sorry if you think that 5K seems
like a lot of "spam" but having to open a browser just to look at
"emerge --info" is a complete waste of time.  Especially as I have
already said that I've used information from *other arches* to help me
pinpoint problems on the architecture that I am currently testing.

> gcc 4.1.1 works on x86 with the following:
> > 
> > USE="gtk nls -bootstrap -build -doc -fortran -gcj -hardened -ip28
> > -ip32r10k -mudflap -multislot -nocxx -objc -objc++ -objc-gc -test
> > -vanilla"
> 
> Looks OK to me. But hey, aren't arch devs and testers alike supposed to
> test (almost) all flags? And also, wouldn't you also want to know about
> FEATURES, specifically FEATURES='{test,collision-detect}'? How about
> KEYWORDS? You would still need to be able to find the full `emerge info`
> in an attachment, I guess.

Umm... Arch Testers are required to use FEATURES="test
collision-protect" as well as stable KEYWORDS, so that really is
somewhat irrelevant, especially on a success.  While it's all warm and
fuzzy to say that every iteration of a package must be tested, I'd like
to see you try with things like PHP.

> > This still gives us most of the pertinent information without the rest
> > of the "spam" of emerge --info.  It makes the emails from bugzilla
> > still usable for those of us that don't waste the time to open up
> > bugzilla for every bug.  I do most of my bug management via email.  I
> > open the bug *only* when I need to comment, or after I've performed
> > the work requested.  Having to open the bug every time would be a
> > complete waste of time for me.  Much more so than simply *deleting*
> > an email that doesn't pertain to me, or scrolling past unimportant
> > information.
> 
> So we are still looking for a compromise that will place the burden on
> the $arch ADs and ATs, not the $other_arch devs, right? Currently it's
> basically a mindless integral copy/paste action which benefits only a
> few.

What burden?  Having to delete a message?  Scroll past a hundred lines
of text?  Seriously, the impact on the people that *rely* on this to get
their work done would seem to outweigh the minor inconvenience of having
to scroll/hit the delete key.

> > I would find that this change would be disruptive to my ability to
> > work on these architecture teams.  As stated before, sometimes another
> > architecture's problem can point you at something to test.  If a
> > certain USE combination doesn't work on x86, wouldn't you want to
> > test it on hppa specifically to make sure that it isn't a global
> > issue?  I know that I sure test any combinations from $other_arches
> > when testing for a given $arch, if they've reported a failure.
> 
> I still think failures should be reported in separate bugs, as they are
> likely to cause lots more information to be passed.

They still need to be mentioned in the stabilization bug, no matter
what.  The problem that I see with your proposal is it removes
information from the bug in question by spreading it out all over
bugzilla, as well as reduces transparency.  As I have said, I have found
other architecture's information to be *invaluable* in my own
architecture developer work.  Perhaps you have found this to not be the
case for you, but trying to force everyone to switch to a process that
is only slightly more convenient for you and causes others to spend a
proportionally much greater amount of time to get the same information
sounds like a bad idea to me.

You asked for some comments.  I've commented.  I don't find information
to be "cruft" and my vote would be "no" on forcing attachments for
"emerge --info"...

-- 
Chris Gianelloni
Release Engineering - Strategic Lead
x86 Architecture Team
Games - Developer
Gentoo Linux

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

[gentoo-dev] Re: Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Duncan]

"Kevin F. Quinn" <kevquinn@gentoo.org> posted
20060811123635.062b5fc2@c1358217.kevquinn.com, excerpted below, on  Fri,
11 Aug 2006 12:36:35 +0200:

> On Fri, 11 Aug 2006 04:56:18 +0000 (UTC)
> "Duncan" <1i5t5.duncan@cox.net> wrote:

> [re. posting AT configs somewhere]
>> I like the idea above, tho.  For ATs especially, having some place
>> where emerge --info could be posted just once, with a link to it
>> instead of the duplicated inline /or/ attachment[]
> 
> I think the info changes frequently enough that it's easier, and more
> likely to be correct, if it's posted to the bug at the time the report
> is made.

I was thinking CFLAGS and the like.  You mentioned in a different post
CFLAGS changing fairly often.  I wasn't thinking of those, but with that
in mind, I see your point and have changed my mind.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Ryan Hill]

Chris Gianelloni wrote:

> No.  It really should be inline.  I'm sorry if you think that 5K seems
> like a lot of "spam" but having to open a browser just to look at
> "emerge --info" is a complete waste of time.

*ding*

it's also nice to have that information actually _in_ my mailbox and not 
of at the end of some attachment URL, considering i'm offline 5 days of 
the week.  i've been in this situation a few times now, where i've 
needed an attachment from a bug i'm working on and had to wait half a 
week to do anything with it.

yeah i'm a corner case, and needing an AT's emerge --info isn't that 
common, but why cut these corners when we don't have to?  especially 
since the reason for doing so is to save someone from having to actually 
scroll a mouse wheel or hit delete, or be bothered with getting an email 
when a AT posts their info in a comment (which you'll still get if they 
do it as an attachment anyways).

--de.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Ryan Hill]

Duncan wrote:
> Matti Bickel <kabel@cat0.de> posted 20060810215951.GA8456@pluto.athome,
> excerpted below, on  Thu, 10 Aug 2006 23:59:51 +0200:
> 
>> Thomas Cort <tcort@gentoo.org> wrote:
>>> Why do arch testers need to post `emerge --info` if everything works?
>>> Shouldn't we be able to trust that they have sane CFLAGS, proper
>>> FEATURES, and an up to date system?
>> Once there was the idea of putting AT testing system specs somewhere, so arch
>> devs could actually see what we're running. Is this still needed or is the
>> number of ATs small enough to keep that in head-RAM?
>>
>> Anyways, I agree that posting emerge --info to a highly frequented stable bug
>> is annoying and should be abolished.
> 
> Even back before it became the "in" thing, I was posting emerge --info as
> attachments, because it simply fit the bill -- bugzy /says/ to put long
> stuff as attachments.  I never did quite understand why all that
> admittedly often useful high-volume spew was tolerated in the bug comments
> themselves.

bugzy also says "('emerge --info' goes here)" above Description and 
"(this is where you put 'emerge --info') above Comments. ;)  you're 
right, it does say make it an attachment if it's too long, but how long 
is too long?

--de.

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Ryan Hill]

Jeroen Roovers wrote:
> On a minor note, I'd also like to see bug reporters use canonical
> package names in bug descriptions, including the category (and
> preferably the specific version, not some >=foo-3*!!!one, not to
> mention specifying no version at all). Including the category means
> arch devs won't need to guess/discover which of a few hundred categories
> a package is meant to reside in.

Yeah, this should be standard.  I like to also put the current stable in 
the comment (when there's not a pantload of arches at different stable 
versions at least).  Doubt it matters but, meh..

--de.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: RFC: AT emerge info cruft > attachments on bugs.g.o

[Jakub Moc]

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

> it does say make it an attachment if it's too long, but how long
> is too long?

8K characters (and bugzilla will actually send you to places where the
sun doesn't shine if you try to post something that exceeds this limit).


-- 
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: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Simon Stelling]

Being an amd64 dev, I want to basically add a 'me too!' here. I think
it's not necessary to add the --info output when all worked well,
though, if instead the output of -pv $PN was given. Except when there
was a failure reported before, because then we need it to compare the two.

Regarding the inline vs. attachment issue, I'd vote for inline too.

Just my 0.05 CHF,

-- 
Kind Regards,

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Simon Stelling]

Jeroen Roovers wrote:
> On a minor note, I'd also like to see bug reporters use canonical
> package names in bug descriptions, including the category (and
> preferably the specific version, not some >=foo-3*!!!one, not to
> mention specifying no version at all). Including the category means
> arch devs won't need to guess/discover which of a few hundred categories
> a package is meant to reside in.

First off, I second that. Second, here's how you still get where you
want without looking up the category:

$ cd gentoo-x86/*/foo

This of course doesn't work if there are multiple packages with the same
name in different categories, but if a package maintainer doesn't
specify the category in such a case, he should be hit anyway ;P

-- 
Kind Regards,

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Harald van Dijk]

On Sat, Aug 12, 2006 at 01:13:48PM +0200, Simon Stelling wrote:
> Jeroen Roovers wrote:
> > On a minor note, I'd also like to see bug reporters use canonical
> > package names in bug descriptions, including the category (and
> > preferably the specific version, not some >=foo-3*!!!one, not to
> > mention specifying no version at all). Including the category means
> > arch devs won't need to guess/discover which of a few hundred categories
> > a package is meant to reside in.
> 
> First off, I second that. Second, here's how you still get where you
> want without looking up the category:
> 
> $ cd gentoo-x86/*/foo

This works better:

$ cd gentoo-x86/*/foo/

This avoids the case where a file by the same name exists (for
example, in licenses/).

> This of course doesn't work if there are multiple packages with the same
> name in different categories, but if a package maintainer doesn't
> specify the category in such a case, he should be hit anyway ;P
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Jeroen Roovers]

On Sat, 12 Aug 2006 13:13:48 +0200
Simon Stelling <blubb@gentoo.org> wrote:

> Jeroen Roovers wrote:
> > On a minor note, I'd also like to see bug reporters use canonical
> > package names in bug descriptions, including the category (and
> > preferably the specific version, not some >=foo-3*!!!one, not to
> > mention specifying no version at all). Including the category means
> > arch devs won't need to guess/discover which of a few hundred
> > categories a package is meant to reside in.
> 
> First off, I second that. Second, here's how you still get where you
> want without looking up the category:
> 
> $ cd gentoo-x86/*/foo

That's why I explicitly mentioned "discover". It would have been
impossible to get ebuilds marked in response to stabilisation bugs
since November 2005 if I couldn't discover canonical package names on
my own... :)


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Francesco Riosa]

[...]
>>
>> $ cd gentoo-x86/*/foo
> 
> This works better:
> 
> $ cd gentoo-x86/*/foo/
> 
> This avoids the case where a file by the same name exists (for
> example, in licenses/).

may be
$ cd gentoo-x86/*-*/foo/
?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs

[Kevin F. Quinn]

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

On Sat, 12 Aug 2006 13:08:50 +0200
Simon Stelling <blubb@gentoo.org> wrote:

> Being an amd64 dev, I want to basically add a 'me too!' here. I think
> it's not necessary to add the --info output when all worked well,
> though, if instead the output of -pv $PN was given. Except when there
> was a failure reported before, because then we need it to compare the
> two.

Thing is, an AT who reports success before someone else reports a
failure won't know whether that will happen, and may have moved on
since the test was performed.  So always reporting `emerge info` at
the time of the report makes sense even for successful tests.

-- 
Kevin F. Quinn

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

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Harald van Dijk]

On Sat, Aug 12, 2006 at 02:42:32PM +0000, Francesco Riosa wrote:
> [...]
> >>
> >> $ cd gentoo-x86/*/foo
> > 
> > This works better:
> > 
> > $ cd gentoo-x86/*/foo/
> > 
> > This avoids the case where a file by the same name exists (for
> > example, in licenses/).
> 
> may be
> $ cd gentoo-x86/*-*/foo/
> ?

Maybe. That avoids virtual/*, which may or may not be a good thing,
depending on your needs. (The only other case where it helps is
uclibc, which is probably already a special enough case that it can
be mostly ignored for this thread.)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Ned Ludd]

On Sat, 2006-08-12 at 17:17 +0200, Harald van Dijk wrote:
> On Sat, Aug 12, 2006 at 02:42:32PM +0000, Francesco Riosa wrote:
> > [...]
> > >>
> > >> $ cd gentoo-x86/*/foo
> > > 
> > > This works better:
> > > 
> > > $ cd gentoo-x86/*/foo/
> > > 
> > > This avoids the case where a file by the same name exists (for
> > > example, in licenses/).
> > 
> > may be
> > $ cd gentoo-x86/*-*/foo/
> > ?
> 
> Maybe. That avoids virtual/*, which may or may not be a good thing,
> depending on your needs. (The only other case where it helps is
> uclibc, which is probably already a special enough case that it can
> be mostly ignored for this thread.)

/me lands in the profiles dir when he really wants the *-* dir all the
time.


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

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o

[Lars Strojny]

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

Hi,

Am Donnerstag, den 10.08.2006, 19:50 +0200 schrieb Jeroen Roovers:
[...]
> On a minor note, I'd also like to see bug reporters use canonical
> package names in bug descriptions, including the category (and
> preferably the specific version, not some >=foo-3*!!!one, not to
> mention specifying no version at all). Including the category means
> arch devs won't need to guess/discover which of a few hundred categories
> a package is meant to reside in.

Maybe it would make sense to provide an interface for specifying
category, package and version. Something similiar to
http://new.usrportage.de/ would be maybe the way to go.

Greetings, Lars Strojny
-- 
      "Kriterium des Wahren ist nicht seine unmittelbare
          Kommunizierbarkeit an jedermann"
         -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik«

name: Lars H. Strojny      web: http://strojny.net 
street: Engelsstraße 23    blog: http://usrportage.de
city: D-51103 Köln         mail/jabber: lars@strojny.net
f-print: 1FD5 D8EE D996 8E3E 1417  328A 240F 17EB 0263 AC07

[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 827 bytes --]