On Fri, 11 Aug 2006 11:27:29 -0400
Chris Gianelloni <[EMAIL PROTECTED]> 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
