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@g.o> 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@g.o mailing list