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 <CPV>
>
> 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
