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

[Chris Gianelloni]

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