Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Sat, 12 Aug 2006 13:08:50 +0200 Simon Stelling <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
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 to [STABLE] bugs
-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
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
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
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
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Fri, 2006-08-11 at 16:46 +0200, Jeroen Roovers wrote: > N -1 arch dev's comfort against N arch devs' annoyance[1]. > [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 signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Fri, 11 Aug 2006 16:46:33 +0200 Jeroen Roovers <[EMAIL PROTECTED]> 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 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments to [STABLE] bugs
On Fri, 11 Aug 2006 15:25:11 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] (arch devs and ATs for one arch) instead of mailing same to [EMAIL PROTECTED] (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 > > 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