Edward Catmur wrote: > On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: >> Instead of a simple cvs up; cd /usr/local/portage/category/package I >> need to search for ALL bugs with $name in it, look which one it is, >> curse bugzilla for falling asleep again, see which attachments are >> relevant, download them, curse bugzilla for falling asleep again, copy >> them to my overlay, read the bugcomments to see if any special renaming >> or directory structure is needed ... >> >> Hmmm. I think an overlay does have some advantages there ... > > Advantages? With bugzilla I: search for the bug, cc myself on it, > download the relevant files, look over them, note a style error, try to > merge it, fix a compilation bug, re-upload the fixed ebuild and patch to > bugzilla with a comment to the ebuild author on their mistake. When an > update hits my inbox I can go directly to the bug...
Hmmm, I mostly notice a different scenario: - search for the bug, and file a dupe because you didn't find it :P - bug gets marked as a dupe - the guy who filed the dupe comments on how much bugzilla search sucks - download one of obsolete broken ebuilds attached to the bug - moan that it doesn't work - download another ebuild - moan that it doesn't work either - someone points to comment #27 that says you need to edit lines XX and YY for the ebuild to work - do it, post yet another redundant "yay, that finally worked!" comment - attach a "fixed" ebuild tarball - you get scream upon to not attach tarballs - you attach a plaintext ebuild now - notice that its MIME type is application/octet-stream - change the mime type - look at the ebuild in the browser now that you can and notice bunch of stupid typos you've done that ruin the whole fix (hello, Mr. Murphy) - try to edit the attachment in bugzilla, which produces one huge nonsense comment instead of actually editing the ebuild - attach a new one - oh noes, it's octet-stream again! argh! - fix it... - forgot to mark previous one as obsolete, do it now - produce "sorry for the noise" comment - someone notices that you've still left two typos there and attaches yet another ebuild By now, about 15 bugspams times the number of people CCed on the bug got sent, containing mostly useless crap. > With an overlay: search sunrice.gentoo.org for the package (no, I don't > know category/name), sync that directory (no, I'm not syncing the whole > sunrice tree), check it over, note some mistakes, compile it if I feel > OK with it, it fails, I fix it - and what then? Where do I discuss the > problems? How do I get my fixes to other users, considering the package > is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will > it be read? > > This seems like *raising* the barrier to entry to me... Yes, with an overlay you can prevent all the attachment screwups noted above and once you are really satisfied that it works, you post a link to bugzilla. You can fix your typos in VCS, even multiple times, without bugspamming the hell out of people, and you still have the history to go back if you screw up. Bugs with tens of attachments are essentially useless for most of newcomers and suck for effective development as well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=24247 http://bugs.gentoo.org/show_bug.cgi?id=70161 http://bugs.gentoo.org/show_bug.cgi?id=122500 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;)
signature.asc
Description: OpenPGP digital signature
