[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Duncan wrote:
Matti Bickel [EMAIL PROTECTED] posted [EMAIL PROTECTED],
excerpted below, on Thu, 10 Aug 2006 23:59:51 +0200:
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.
Even back before it became the in thing, I was posting emerge --info as
attachments, because it simply fit the bill -- bugzy /says/ to put long
stuff as attachments. I never did quite understand why all that
admittedly often useful high-volume spew was tolerated in the bug comments
themselves.
bugzy also says ('emerge --info' goes here) above Description and
(this is where you put 'emerge --info') above Comments. ;) you're
right, it does say make it an attachment if it's too long, but how long
is too long?
--de.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
it does say make it an attachment if it's too long, but how long is too long? 8K characters (and bugzilla will actually send you to places where the sun doesn't shine if you try to post something that exceeds this limit). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Tach Matti, 0x2B859DE3 (PGP-PK-ID) Matti Bickel schrieb: 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? The problem is that at least USE flags change relatively fast overtime and there are slight differences. When you compare a bug from July 06 and have a look at the emerge --info that has been updated August 06, it can be somewhat misleading. Anyways, I agree that posting emerge --info to a highly frequented stable bug is annoying and should be abolished. Do you have a proposition how to provide the same functionality? V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ pgp7kIpvd7RVq.pgp Description: PGP signature
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID) Jeroen Roovers schrieb: 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. And when there is a problem, attachments have to be opened...some more steps, especially when there have been a dozen testers and their info has to be filtered out of the attachment list. 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. Seconded. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ pgpM6yPkvrYCR.pgp Description: PGP signature
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID) Jeroen Roovers schrieb: 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. Basically you are right about cruft, but the information the ATs submit should be accessible to everyone so the actual solution without attachments (because of more work) is the bestTM. What other ways of communication between ATs and devs do you propose? Some kind of arch Bugzilla? IMO it should be permanent with a link from the stabilisation bug so that everyone (devs, users, ATs) can follow the path of stabilisation. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ pgp756JUdHV3A.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
On Fri, 11 Aug 2006 04:56:18 + (UTC) Duncan [EMAIL PROTECTED] wrote: Even back before it became the in thing, I was posting emerge --info as attachments, because it simply fit the bill -- bugzy /says/ to put long stuff as attachments. I never did quite understand why all that admittedly often useful high-volume spew was tolerated in the bug comments themselves. Personally I find it a lot easier to read a bug when the emerge --info data from people is inline. Frequently, the trigger for a bug becomes apparent when you compare the emerge --info of the various people who see a bug, and it's a moment's effort to scroll up and down the bug to compare data. This process takes longer if the info is in a bunch of attachments. [re. posting AT configs somewhere] I like the idea above, tho. For ATs especially, having some place where emerge --info could be posted just once, with a link to it instead of the duplicated inline /or/ attachment, makes even more sense. Presumably, where it's posted could have dated versions, too, allowing for updated flags without invalidating the info pointed to for older links. If variation off the norm was needed or used for an individual package, that could be noted in the comments along with the link to the standard info. I think the info changes frequently enough that it's easier, and more likely to be correct, if it's posted to the bug at the time the report is made. -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Tach Jeroen, 0x2B859DE3 (PGP-PK-ID) Jeroen Roovers schrieb: 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. This sounds quite interesting...maybe some arch devs should comment on that. The only problem I see is when two ATs test at the same time and open two separate bugs for the same arch. And another problem: Other arches don't see the problems in the depending bug and are unlikely to comment on it. V-Li -- Fingerprint: 68C5 D381 B69A A777 6A91 E999 350A AD7C 2B85 9DE3 http://www.gnupg.org/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
On 11 Aug 2006 00:00:00 + [EMAIL PROTECTED] (Christian 'Opfer' Faulhammer) wrote: Tach Jeroen, 0x2B859DE3 (PGP-PK-ID) Jeroen Roovers schrieb: 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. This sounds quite interesting...maybe some arch devs should comment on that. The only problem I see is when two ATs test at the same time and open two separate bugs for the same arch. And another problem: Other arches don't see the problems in the depending bug and are unlikely to comment on it. Besides the points you mentioned, it would create a lot of bug spam. There would be the a new bug depends on this bug e-mail when the AT files the bug, then there would be the a bug that depends on this bug has changed state e-mail when the arch dev closes the AT's bug, and then there would be the e-mail from the arch dev when he/she comments on the original bug saying arch-xyz stable -Thomas pgpsF5RKCaBpJ.pgp Description: PGP signature
[gentoo-dev] Re: RFC: AT emerge info cruft attachments on bugs.g.o
Matti Bickel [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 10 Aug 2006 23:59:51 +0200: 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. Even back before it became the in thing, I was posting emerge --info as attachments, because it simply fit the bill -- bugzy /says/ to put long stuff as attachments. I never did quite understand why all that admittedly often useful high-volume spew was tolerated in the bug comments themselves. I like the idea above, tho. For ATs especially, having some place where emerge --info could be posted just once, with a link to it instead of the duplicated inline /or/ attachment, makes even more sense. Presumably, where it's posted could have dated versions, too, allowing for updated flags without invalidating the info pointed to for older links. If variation off the norm was needed or used for an individual package, that could be noted in the comments along with the link to the standard info. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- gentoo-dev@gentoo.org mailing list
