Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Hi, Am Donnerstag, den 10.08.2006, 19:50 +0200 schrieb Jeroen Roovers: [...] > On a minor note, I'd also like to see bug reporters use canonical > package names in bug descriptions, including the category (and > preferably the specific version, not some >=foo-3*!!!one, not to > mention specifying no version at all). Including the category means > arch devs won't need to guess/discover which of a few hundred categories > a package is meant to reside in. Maybe it would make sense to provide an interface for specifying category, package and version. Something similiar to http://new.usrportage.de/ would be maybe the way to go. Greetings, Lars Strojny -- "Kriterium des Wahren ist nicht seine unmittelbare Kommunizierbarkeit an jedermann" -- Theodor Wiesengrund Adorno, aus: »Negative Dialektik« name: Lars H. Strojny web: http://strojny.net street: Engelsstraße 23blog: http://usrportage.de city: D-51103 Köln mail/jabber: [EMAIL PROTECTED] f-print: 1FD5 D8EE D996 8E3E 1417 328A 240F 17EB 0263 AC07 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Sat, 2006-08-12 at 17:17 +0200, Harald van Dijk wrote: > On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote: > > [...] > > >> > > >> $ cd gentoo-x86/*/foo > > > > > > This works better: > > > > > > $ cd gentoo-x86/*/foo/ > > > > > > This avoids the case where a file by the same name exists (for > > > example, in licenses/). > > > > may be > > $ cd gentoo-x86/*-*/foo/ > > ? > > Maybe. That avoids virtual/*, which may or may not be a good thing, > depending on your needs. (The only other case where it helps is > uclibc, which is probably already a special enough case that it can > be mostly ignored for this thread.) /me lands in the profiles dir when he really wants the *-* dir all the time. -- Ned Ludd <[EMAIL PROTECTED]> Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Sat, Aug 12, 2006 at 02:42:32PM +, Francesco Riosa wrote: > [...] > >> > >> $ cd gentoo-x86/*/foo > > > > This works better: > > > > $ cd gentoo-x86/*/foo/ > > > > This avoids the case where a file by the same name exists (for > > example, in licenses/). > > may be > $ cd gentoo-x86/*-*/foo/ > ? Maybe. That avoids virtual/*, which may or may not be a good thing, depending on your needs. (The only other case where it helps is uclibc, which is probably already a special enough case that it can be mostly ignored for this thread.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
[...] >> >> $ cd gentoo-x86/*/foo > > This works better: > > $ cd gentoo-x86/*/foo/ > > This avoids the case where a file by the same name exists (for > example, in licenses/). may be $ cd gentoo-x86/*-*/foo/ ? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Sat, 12 Aug 2006 13:13:48 +0200 Simon Stelling <[EMAIL PROTECTED]> wrote: > Jeroen Roovers wrote: > > On a minor note, I'd also like to see bug reporters use canonical > > package names in bug descriptions, including the category (and > > preferably the specific version, not some >=foo-3*!!!one, not to > > mention specifying no version at all). Including the category means > > arch devs won't need to guess/discover which of a few hundred > > categories a package is meant to reside in. > > First off, I second that. Second, here's how you still get where you > want without looking up the category: > > $ cd gentoo-x86/*/foo That's why I explicitly mentioned "discover". It would have been impossible to get ebuilds marked in response to stabilisation bugs since November 2005 if I couldn't discover canonical package names on my own... :) Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Sat, Aug 12, 2006 at 01:13:48PM +0200, Simon Stelling wrote: > Jeroen Roovers wrote: > > On a minor note, I'd also like to see bug reporters use canonical > > package names in bug descriptions, including the category (and > > preferably the specific version, not some >=foo-3*!!!one, not to > > mention specifying no version at all). Including the category means > > arch devs won't need to guess/discover which of a few hundred categories > > a package is meant to reside in. > > First off, I second that. Second, here's how you still get where you > want without looking up the category: > > $ cd gentoo-x86/*/foo This works better: $ cd gentoo-x86/*/foo/ This avoids the case where a file by the same name exists (for example, in licenses/). > This of course doesn't work if there are multiple packages with the same > name in different categories, but if a package maintainer doesn't > specify the category in such a case, he should be hit anyway ;P -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Jeroen Roovers wrote: > On a minor note, I'd also like to see bug reporters use canonical > package names in bug descriptions, including the category (and > preferably the specific version, not some >=foo-3*!!!one, not to > mention specifying no version at all). Including the category means > arch devs won't need to guess/discover which of a few hundred categories > a package is meant to reside in. First off, I second that. Second, here's how you still get where you want without looking up the category: $ cd gentoo-x86/*/foo This of course doesn't work if there are multiple packages with the same name in different categories, but if a package maintainer doesn't specify the category in such a case, he should be hit anyway ;P -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Jeroen Roovers <[EMAIL PROTECTED]> wrote: > ATs can inform you whether something works in the comment to an > attachment, which, unlike the attachment, will end up in my mailbox. Ok, so i sample my emerge --info > myconfig.txt and attach that. This is ok with me. However, i propose that this functionality is included into pybugz, which already offers inlining emerge --info. That would speed up the process tremendously (thanks liquidx!). > One solution might be to open your own AT bug, make the stabilisation > bug depend on it, and use the AT bug to have ATs post their `emerge > info`. I disagree. That adds complexity and thus increases time spent on bugzi w/o actual benefit for the overall dev-community. I'd rather go w/ posting emerge --info as a attachment. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpscnHaz4joo.pgp Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 13:40:23 +0200
Jeroen Roovers <[EMAIL PROTECTED]> wrote:
> On Fri, 11 Aug 2006 12:52:30 +0200
> "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
>
> > In general it depends what you're doing. Personally I find inline
> > emerge --info quicker to process, as I tend to do that by scrolling
> > up and down a bug when trying to determine what triggers a bug.
> > However that's for "normal" bugs - I don't spend much time on
> > stabilisation bugs.
>
> "Personally" is meaningless in this context.
"Personally" is critical. Part of my point was that whatever way it's
done, it will be better for some and worse for others. In other words,
what is "better" is subjective. 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.
> The inline `emerge info`
> is quicker to process for you, not for other-arch devs out there. For
> them the info is useless. Stabilisation bugs in this context are
> bugs CC'd to many arch aliases (see below for a possible solution).
>
> > > you have to wade through all the AT spam to find out what is being
> > > changed over time. It's best to have it in attachments, I think.
> > >
> > > Besides, you're wrong. ATs can add comments to attachments
> > > informing their arch devs of success or failure, and name the
> > > `emerge info` attachment properly so everybody knows what the
> > > attachment actually is (and when to ignore it).
> >
> > In what way am I wrong? I never said AT's can't add comments.
>
> ATs can inform you whether something works in the comment to an
> attachment, which, unlike the attachment, will end up in my mailbox. I
> have no problems with short comments like:
>
>
> --- Comment #5 from [EMAIL PROTECTED] 2006-08-01 02:47 PST ---
> Created an attachment (id=93193)
>--> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
> emerge info
>
> Works Great!!!1omg
ok; that makes better sense.
> > Effectively what you're saying is transcribe the emerge info into
> > the attachment name and attachment comment - which effectively
> > makes it in-line again.
>
> 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.
Whether it's a burden on arch devs or not, you'd have to poll.
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.
> > Rule 1 in problem reporting - report your exact configuration and
> > exactly what you see, in the first instance, do not attempt to
> > interpret until you have that data recorded.
>
> Could you consider having ATs report the exact configuration
> elsewhere? In normal bugs, encouraging users to post their emerge info
> is a good thing. In stabilisation bugs, with well-instructed ATs
> posting comments, there's no need to do all that.
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.
> > Not sure I understand. 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. If people are using stabilisation bugs for
> > development/bug fixing then they should stop doing so.
>
> N/A
>
> Stabilisation bugs should be short and simple. If the stabilisation
> target changes half way through (a revision bump perhaps, which
> happens quite often, or an extra dep, which happens quite often as
> well), arch devs need to be able to find that information quickly.
>
> > Well, it adds around 40 lines - I don't see that as a problem.
> > It's a good idea if the emerge info output is placed after whatever
> > comment is being made, so that if you don't care about it you can
> > just skip to the next message.
>
> Erm. It is a problem - I've explained why. It adds bloat and it clogs
> many arch devs' mailboxen with tons of useless info. Merrily skipping
> past it is impossible when a bug spans 5 instead of 2 pages because
> of 3 AT comments, interspersed with possibly useful comments. I guess
> you would feel the same way if I started inlining `emerge info` for
> all my HPPA systems. You'd have to parse each one of them just to
> find your own ATs' `emerge info` among mine.
I don'
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 12:52:30 +0200
"Kevin F. Quinn" <[EMAIL PROTECTED]> wrote:
> In general it depends what you're doing. Personally I find inline
> emerge --info quicker to process, as I tend to do that by scrolling up
> and down a bug when trying to determine what triggers a bug. However
> that's for "normal" bugs - I don't spend much time on stabilisation
> bugs.
"Personally" is meaningless in this context. The inline `emerge info`
is quicker to process for you, not for other-arch devs out there. For
them the info is useless. Stabilisation bugs in this context are bugs
CC'd to many arch aliases (see below for a possible solution).
> > you have to wade through all the AT spam to find out what is being
> > changed over time. It's best to have it in attachments, I think.
> >
> > Besides, you're wrong. ATs can add comments to attachments informing
> > their arch devs of success or failure, and name the `emerge info`
> > attachment properly so everybody knows what the attachment actually
> > is (and when to ignore it).
>
> In what way am I wrong? I never said AT's can't add comments.
ATs can inform you whether something works in the comment to an
attachment, which, unlike the attachment, will end up in my mailbox. I
have no problems with short comments like:
--- Comment #5 from [EMAIL PROTECTED] 2006-08-01 02:47 PST ---
Created an attachment (id=93193)
--> (http://bugs.gentoo.org/attachment.cgi?id=1&action=view)
emerge info
Works Great!!!1omg
> Effectively what you're saying is transcribe the emerge info into the
> attachment name and attachment comment - which effectively makes it
> in-line again.
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.
> Rule 1 in problem reporting - report your exact configuration and
> exactly what you see, in the first instance, do not attempt to
> interpret until you have that data recorded.
Could you consider having ATs report the exact configuration
elsewhere? In normal bugs, encouraging users to post their emerge info
is a good thing. In stabilisation bugs, with well-instructed ATs
posting comments, there's no need to do all that.
> Not sure I understand. 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. If people are using stabilisation bugs for
> development/bug fixing then they should stop doing so.
N/A
Stabilisation bugs should be short and simple. If the stabilisation
target changes half way through (a revision bump perhaps, which
happens quite often, or an extra dep, which happens quite often as
well), arch devs need to be able to find that information quickly.
> Well, it adds around 40 lines - I don't see that as a problem. It's a
> good idea if the emerge info output is placed after whatever comment
> is being made, so that if you don't care about it you can just skip to
> the next message.
Erm. It is a problem - I've explained why. It adds bloat and it clogs
many arch devs' mailboxen with tons of useless info. Merrily skipping
past it is impossible when a bug spans 5 instead of 2 pages because
of 3 AT comments, interspersed with possibly useful comments. I guess
you would feel the same way if I started inlining `emerge info` for all
my HPPA systems. You'd have to parse each one of them just to find your
own ATs' `emerge info` among mine.
> Stabilisation bugs by their very nature are temporary - they are
> active for the time it takes to decide a package can be marked stable.
> Once the package version is marked stable, the bug should be closed.
> I don't see what the communication problem is.
Your communication problem used to be that you want the AT's info
ready to use. Your solution was to have ATs inline `emerge info` in bug
comments. This solution benefits only you, not other arches's devs, and
in fact, it annoys them. Please find a better solution.
One solution might be to open your own AT bug, make the stabilisation
bug depend on it, and use the AT bug to have ATs post their `emerge
info`. Then, when testing and stabilisation is finished for your arch,
close the AT bug and remove your alias from the stabilisation bug's CC
list. I for one could live with this solution to the problem, which I
hope you understand by now.
Kind regards,
JeR
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Fri, 11 Aug 2006 00:51:56 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > On Thu, 10 Aug 2006 23:58:46 +0200 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > The problem with attachments is that processing the report takes > > longer > > - you have to go to the web to read the attachment to find out what > > config worked (or failed, if that was the case). It's best to have > > it in-line, I think. > > The problem with inlining is that processing the info takes longer - In general it depends what you're doing. Personally I find inline emerge --info quicker to process, as I tend to do that by scrolling up and down a bug when trying to determine what triggers a bug. However that's for "normal" bugs - I don't spend much time on stabilisation bugs. > you have to wade through all the AT spam to find out what is being > changed over time. It's best to have it in attachments, I think. > > Besides, you're wrong. ATs can add comments to attachments informing > their arch devs of success or failure, and name the `emerge info` > attachment properly so everybody knows what the attachment actually is > (and when to ignore it). In what way am I wrong? I never said AT's can't add comments. Effectively what you're saying is transcribe the emerge info into the attachment name and attachment comment - which effectively makes it in-line again. Obviously only a tiny part of that can actually be put in the attachment name, and there's little point to putting stuff in the attachment comment unless it's highly redacted - how is the AT going to decide what information is significant? Rule 1 in problem reporting - report your exact configuration and exactly what you see, in the first instance, do not attempt to interpret until you have that data recorded. > > If you're not interested in the AT emerge --info data, why are you > > watching the stabilisation bug? > > Because as an arch dev not on an AT-equipped arch, I still need to > find the interesting-not-your-arch-info between all the > your-arch-cruft. Not sure I understand. 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. If people are using stabilisation bugs for development/bug fixing then they should stop doing so. > All these `emerge info` comments are completely irrelevant to every > arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' > preparations have their work cut out for them, it seems, having all > that info in their mailbox, while non-AT arches have to fork through > all the spam, both in their mailboxes and on bugs.g.o, to get to the > good bits (ouch, sparc beat us again, must stabilise before mips!). > > Inlining emerge info in comments bloats the e-mail message to roughly > 2.5 times the normal size. Well, it adds around 40 lines - I don't see that as a problem. It's a good idea if the emerge info output is placed after whatever comment is being made, so that if you don't care about it you can just skip to the next message. > I could have spoken out to get AT comments > banned altogether or to urge arches with AT teams to find a proper > technical solution to communicate outside of bugs.g.o. I think using > attachments instead of inlining is a pretty good temporary solution to > a communication problem that has for now been solved by making every > stabilisation bug report a dumping ground for a ton of information > that becomes obsolete within a few days. Stabilisation bugs by their very nature are temporary - they are active for the time it takes to decide a package can be marked stable. Once the package version is marked stable, the bug should be closed. I don't see what the communication problem is. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 10 Aug 2006, Matti Bickel wrote: Thomas Cort <[EMAIL PROTECTED]> wrote: Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Unless this causes problems for people, I'd like to be able to find it. As you see from my signature, I'm extrapolating from sparc here, but on sparc, at least, the specs and configuration of a failing system (or of a system which cannot be made to fail) is sometimes highly relevant. Having this sort of information can't hurt and might help, so I'd ask please provide it someplace if convenient. Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. Yes. Well, if you say everything is good, I just don't read it. I sometimes compromise on bugs and give a two or three line indication of just which system(s) I am reporting on. If people want more information, they can ask me or go to a summary page sparc maintains --- all my systems are described there. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred Regards, Ferris - -- Ferris McCormick (P44646, MI) <[EMAIL PROTECTED]> Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5-ecc0.1.6 (GNU/Linux) iD8DBQFE28DyQa6M3+I///cRAqWRAKCSzbmYM8G16DzXuqdUHbYgVnivsQCgyVqS mO5HEmm6oc3yrqfX0IfrMug= =T6kP -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Thu, 2006-08-10 at 18:29 -0400, Thomas Cort wrote: > On Thu, 10 Aug 2006 23:58:46 +0200 > "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > > > It's not about trust, it's about knowing what the CFLAGS/FEATURES > > were. That way if someone else reports a failure, you can compare the > > reports and see what differences might be triggering the fault. > > I get that posting `emerge --info` provides a "known good" set of > CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at > times. However, we don't require that developers post their emerge > --info when a package works, so why do we require that ATs do it? Honestly, it might be sufficient to only post 'emerge --info' when it *doesn't* work. If we need corroboration from someone where it did work, we can ask. -- 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 on bugs.g.o
On Thu, 10 Aug 2006 23:58:46 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > The problem with attachments is that processing the report takes > longer > - you have to go to the web to read the attachment to find out what > config worked (or failed, if that was the case). It's best to have it > in-line, I think. The problem with inlining is that processing the info takes longer - you have to wade through all the AT spam to find out what is being changed over time. It's best to have it in attachments, I think. Besides, you're wrong. ATs can add comments to attachments informing their arch devs of success or failure, and name the `emerge info` attachment properly so everybody knows what the attachment actually is (and when to ignore it). > If you're not interested in the AT emerge --info data, why are you > watching the stabilisation bug? Because as an arch dev not on an AT-equipped arch, I still need to find the interesting-not-your-arch-info between all the your-arch-cruft. All these `emerge info` comments are completely irrelevant to every arch dev for 14-ish out of 15-ish arches. Arch devs blessed with ATs' preparations have their work cut out for them, it seems, having all that info in their mailbox, while non-AT arches have to fork through all the spam, both in their mailboxes and on bugs.g.o, to get to the good bits (ouch, sparc beat us again, must stabilise before mips!). Inlining emerge info in comments bloats the e-mail message to roughly 2.5 times the normal size. I could have spoken out to get AT comments banned altogether or to urge arches with AT teams to find a proper technical solution to communicate outside of bugs.g.o. I think using attachments instead of inlining is a pretty good temporary solution to a communication problem that has for now been solved by making every stabilisation bug report a dumping ground for a ton of information that becomes obsolete within a few days. Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Thu, 10 Aug 2006 23:58:46 +0200 "Kevin F. Quinn" <[EMAIL PROTECTED]> wrote: > It's not about trust, it's about knowing what the CFLAGS/FEATURES > were. That way if someone else reports a failure, you can compare the > reports and see what differences might be triggering the fault. I get that posting `emerge --info` provides a "known good" set of CFLAGS/USE-flags/FEATURES/toolchain versions/etc which can be useful at times. However, we don't require that developers post their emerge --info when a package works, so why do we require that ATs do it? -Thomas pgpdK7lzralER.pgp Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Thomas Cort <[EMAIL PROTECTED]> wrote: > Why do arch testers need to post `emerge --info` if everything works? > Shouldn't we be able to trust that they have sane CFLAGS, proper > FEATURES, and an up to date system? Once there was the idea of putting AT testing system specs somewhere, so arch devs could actually see what we're running. Is this still needed or is the number of ATs small enough to keep that in head-RAM? Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. -- MfG, Matti Bickel Homepage: http://www.rateu.de Encrypted/Signed Email preferred pgpVGA6cHb38q.pgp Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Thu, 10 Aug 2006 14:44:13 -0400 Thomas Cort <[EMAIL PROTECTED]> wrote: > On Thu, 10 Aug 2006 19:50:55 +0200 > Jeroen Roovers <[EMAIL PROTECTED]> wrote: > > > I propose the `emerge --info` included in arch testers' comments on > > stabilisation bugs should rather be posted as attachments. The AT > > comments clog up the bugs and are usually not interesting at all to > > devs other than those who are arch devs for the relevant arches. The problem with attachments is that processing the report takes longer - you have to go to the web to read the attachment to find out what config worked (or failed, if that was the case). It's best to have it in-line, I think. If you're not interested in the AT emerge --info data, why are you watching the stabilisation bug? > > It would certainly improve my RSI not to have to scroll past them. > > Why do arch testers need to post `emerge --info` if everything works? So that you know what configuration worked. This is useful information. > Shouldn't we be able to trust that they have sane CFLAGS, proper > FEATURES, and an up to date system? It's not about trust, it's about knowing what the CFLAGS/FEATURES were. That way if someone else reports a failure, you can compare the reports and see what differences might be triggering the fault. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
On Thu, 10 Aug 2006 19:50:55 +0200 Jeroen Roovers <[EMAIL PROTECTED]> wrote: > I propose the `emerge --info` included in arch testers' comments on > stabilisation bugs should rather be posted as attachments. The AT > comments clog up the bugs and are usually not interesting at all to devs > other than those who are arch devs for the relevant arches. It would > certainly improve my RSI not to have to scroll past them. Why do arch testers need to post `emerge --info` if everything works? Shouldn't we be able to trust that they have sane CFLAGS, proper FEATURES, and an up to date system? > On a minor note, I'd also like to see bug reporters use canonical > package names in bug descriptions, including the category (and > preferably the specific version, not some >=foo-3*!!!one, not to > mention specifying no version at all). Including the category means > arch devs won't need to guess/discover which of a few hundred categories > a package is meant to reside in. I totally agree. An AT or arch team member should know which category, package, and version to test from the bug summary alone. -Thomas pgp53iXA6klQv.pgp Description: PGP signature
[gentoo-dev] RFC: AT emerge info cruft > attachments on bugs.g.o
Hi everybody, I propose the `emerge --info` included in arch testers' comments on stabilisation bugs should rather be posted as attachments. The AT comments clog up the bugs and are usually not interesting at all to devs other than those who are arch devs for the relevant arches. It would certainly improve my RSI not to have to scroll past them. On a minor note, I'd also like to see bug reporters use canonical package names in bug descriptions, including the category (and preferably the specific version, not some >=foo-3*!!!one, not to mention specifying no version at all). Including the category means arch devs won't need to guess/discover which of a few hundred categories a package is meant to reside in. Kind regards, JeR -- gentoo-dev@gentoo.org mailing list
