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
signature.asc
Description: This is a digitally signed message part
