[gentoo-dev] Project pages modifiable by all
Dear all, Thanks to Klieber and Pylon, the gentoo/xml/htdocs/proj/en CVS directory is now open to all developers, meaning that any Gentoo dev may now create new projects and sub-projects at will. Of course, the open permissions means that a dev may also modify projects at will, so the usual rules of courtesy apply (i.e., don't play in other folks' sandboxes unless you know what you're doing--essentially the same idea as with gentoo-x86). Also, projects that are manifestly moribund will be relocated to a "retired" directory for some amount of time and then yanked (-infra is working on the details). Best, -g2boojum- -- Grant Goodyear Gentoo Developer [EMAIL PROTECTED] http://www.gentoo.org/~g2boojum GPG Fingerprint: D706 9802 1663 DEF5 81B0 9573 A6DC 7152 E0F6 5B76 pgpbwltQTUfEi.pgp Description: PGP signature
Re: [gentoo-dev] Proposed security policy for web-based apps
On Sun, 10 Jul 2005 09:57:44 +0100 Stuart Herbert <[EMAIL PROTECTED]> wrote: > It'd perhaps make sense to extend the DTD for metadata.xml, so that the > tag has 'type' and 'organisation' attributes. This would > allow tools to tell the difference between an entry for a Gentoo > maintainer, and an entry for an upstream maintainer. Why modifying the DTD? We did something like this recently with mail-filter/razor, in agreement with $upstream, and all that was needed was the 'description' tag, which is already present in the DTD. -- Andrej "Ticho" Kacian Gentoo Linux Developer - net-mail, antivirus, amd64 pgpYzxlW3CxkO.pgp Description: PGP signature
Re: [gentoo-dev] New developer: Scott Shawcroft (tannewt)
On Monday 11 July 2005 00:07, Bryan Oestergaard wrote: > It's a great pleasure to welcome our newest developer, Scott Shawcroft > to the team. Welcome Scott.. did you already subscribed to your local conspiration? Search for the nearest "Gentoo's conspirations" office! :P -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgpwtWX3sF4xp.pgp Description: PGP signature
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maurice van der Pot wrote: > If the developer shortage was not as big as it is, we could probably > really do something with your proposition. Then why not lay the ground work, documentation-wise, now? Then as you add on developers they have a nice reference on 'best practices' for Gentoo development. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0aGh2QTTR4CNEQARApwyAKCIIM6lv5fgZIH/zENJ0k63WaQKLgCglnUH 0qWsK9ByqQqyKFxvPPLvtAc= =ZPnl -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R Hill wrote: > Ah, okay. You're talking about patch review. Now this makes sense. > I've always considered the Verified status to be indicative that a third > party has been able to reproduce the bug, not that a fix has been > "approved". My mistake. No problem; I appreciate your input. I think Chris White's (et. al.) recent work on the documentation is going to have a better effect on the problem you mention. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Z832QTTR4CNEQARAlxWAJwIkswVeLsJlSfcVmcTGcjaBGAKZACghI0b eqbYsXXyTLxJhyf8YhEH/VI= =R/2Y -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 10 Jul 2005 11:32:44 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]> > wrote: > | > Again, Gentoo is not a large corporation or Debian. > | > | I don't see how Gentoo's status (or rather lack thereof) as a > | corporation or Debian has anything to do with encouraging peer review. > > You're taking methods from a "how your typical oversized software > engineering bloatware project works" situation and trying to apply them > outside of their domain. The Linux kernel has a mult-tiered sign-off/peer review method[1]. I guess they're just your typical oversized software engineering bloatware project then, right? > | > The assumption is > | > that the majority of fixes are done correctly the first time, and > | > this assumption is valid. > | > | I don't see how you could prove that assumption. If you can, please do > | so. > > Experience. I receive bug mail for a heck of a lot of bugs. I see how > many of them are indeed correctly resolved when they are marked as such. Ah ha! So you've been peer reviewing bug fixes!!! Wouldn't it be nice if all developers did that sort of thing and gained that kind of experience? > | > Hence, the default behaviour is to mark bugs as > | > RESOLVED, with reopening being an entirely legitimate and encouraged > | > response for those occasional instances where the resolution was not > | > sufficient. > | > > | > | There are plenty of devs who don't share in the viewpoint that > | reopening bugs is legitimate and should encouraged (although I agree > | it is and should be). I base opinion that on some of the kicking and > | screaming I've seen on bugzilla in the past. ;) > > No, that kicking and screaming is reserved for when bugs are reopened > inappropriately. Let's not reopen old wounds. ;) [1] http://www.groklaw.net/article.php?story=20050529095918381 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Z6n2QTTR4CNEQARAg/vAJ0d74aHyB1123sAmIMMxuSgxX4bKQCglP6a ihY16+oc5BTRLudHW6PtZ3s= =Me/f -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New developer: Scott Shawcroft (tannewt)
Hi all. It's a great pleasure to welcome our newest developer, Scott Shawcroft to the team. Scott is joining Gentoo to help with all things Bugday. He already has a lot of great ideas that I'm sure we'll all see soon :) Besides working on Bugday related things, Scott is also an upstream developer for Denu (denu.sourceforge.net) which is a GTK based menu editor. When not working on his computer Scott enjoys spending time acting, singing, kayaking and skim boarding. Please join me in welcoming Scott to the team. Regards, Bryan Østergaard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
On 15:57 Sun 10 Jul , Daniel Drake wrote: > How to give us lots of yummy info: > - How to apply patches > - How to use strace > - How to identify a configure failure > - and how to upload config.log > - How to use gdb, for C apps > - Using valgrind? > etc Tigger wrote a doc about writing helpful bug reports for the auditing team which covers some of this. I can't remember the url, so someone might like to poke him about it if he isn't paying attention to this discussion. Dave -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
Shyam Mani wrote: > As for the rest of the points you've brought up, did you have time to > pen down answers as well? If so, could we have a look at them please? > Some answers are obvious, but some others aren't and these points are > quite valid and do need to be in the doc. I haven't written any answers. I was planning to write this document based on those points, but never got around to it. I'm happy to modify the document to cover my points, but I don't know when I'd get time to do so. So if you or anyone else want to takes the job, feel free ;) If you'd like me to elaborate on any points, just ask. Thanks, Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/10/2005 08:27 PM, Daniel Drake wrote: > As you know, I've been meaning to write one of these for a while. I've been > keeping a list of topics I think should be mentioned. Stripping out the ones > you have covered, here's what I have left: > > maintainer-needed description > maintainer-wanted description These two are there, but kinda obscure. They need to be more prominent. As for the rest of the points you've brought up, did you have time to pen down answers as well? If so, could we have a look at them please? Some answers are obvious, but some others aren't and these points are quite valid and do need to be in the doc. > Since the doc is already covering a lot of content, and adding some of these > points to it will broaden it further, I think it makes sense to have 2 docs. > One for "how to report a bug", and another for "how to give us lots of yummy > info" in a bug report. > > Something like: > > How to report a bug: > - Search, check that nobody has filed it already > - Fill in the form under the right product > - How to get "emerge info" output > - General policy stuff: > - If attaching, use plain text and never tarballs > - Don't reassign bugs, leave that to devs > - Don't close just because you have workarounds > - What to do if your bug isnt getting attention > - maintainer-needed/wanted description > etc > > How to give us lots of yummy info: > - How to apply patches > - How to use strace > - How to identify a configure failure > - and how to upload config.log > - How to use gdb, for C apps > - Using valgrind? > etc Yeah, I guess that's the way the doc will go now. I'll have a word with Chris before we start splitting the doc. Other docs-team people had a similar opinion as well, so I guess it's only a matter of time before we end up having the above format. > It could also be used as a reference thing, e.g. on a kernel bug, I'll say > "please try this patch", user says "how?", it would be nice if i could point > them to a specific page on the tech doc. Very valid point. Thanks for the inputs Daniel! :) Regards, - -- Shyam Mani | <[EMAIL PROTECTED]> docs-team | http://gdp.gentoo.org GPG Key| 0xFDD0E345 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC0YGFYZNYgP3Q40URAsACAJ9q3nWpqaJlTvAXUHIQq0iuSKuqRQCeN3cn Apy9mAtQymYDYRXGy/kkMQY= =SBEp -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sun, Jul 10, 2005 at 11:08:41AM -0400, Nathan L. Adams wrote: > "Ideally any bug that a fix is submitted for should be verified and peer > reviewed. It should be verified by the reporter or another user. If the > reporter or another user are unable or unwilling to verify the fix, the > Team Lead should take responsibility for the verification. Ideally, all > bug fixes should be peer reviewed by the Team Lead and/or other team > members before the bug is marked as RESOLVED. " I think right now the situation is so far from ideal that we should not focus too much on ideally, but rather on realistically as we do now. The number of open bugs in Gentoo's bugzilla keeps growing. It really is triage. And when doing triage, it's still valid to say that ideally something would be done so and so, but you know that's never gonna happen. If the developer shortage was not as big as it is, we could probably really do something with your proposition. Regards, Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgp412UEN8KmD.pgp Description: PGP signature
[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: > I'm assuming that this would only apply to cases where the dev has provided a fix (in most cases I assume they would have reproduced the problem). The reporter's test would have the benefits mentioned above, and if the Team Lead tested, they could review the fix for technical correctness, etc. Again, my suggestion attempts to improve the process farther down stream; the problem of validating new bugs and tagging them appropriately is a separate matter. Ah, okay. You're talking about patch review. Now this makes sense. I've always considered the Verified status to be indicative that a third party has been able to reproduce the bug, not that a fix has been "approved". My mistake. --de. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sun, 2005-07-10 at 09:14 -0400, Nathan L. Adams wrote: > Are you offering me a job? ;) Are you applying for one? No, really - I think the basic idea in your proposal is great. But Gentoo is a community based open source software project, worked on by volunteers in their spare time. I think you're forgetting this in your current proposal. If you're so keen on seeing this proposal through, I suggest you do what any other open source developer must do to get his/her ideas through: show me the code - or in this context - be prepared to do most of the initial work yourself. That's how open source works. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sunday 10 July 2005 17:32, Nathan L. Adams wrote: > I don't see how you could prove that assumption. If you can, please do so. You see more people ranting that bugs aren't resolved, or more people happy because their bugs are resolved? I'm sorry but I can say at least for myself that most of the bugs i marked RESOLVED FIXED are actually resolved, a couple of them had little problems fixed just a bit later. When I can't be sure if a change is fixed, I usually use RESOLVED TEST-REQUEST (If I'm sure enough to say that is resolved) or I just ask the reporter to see if the bug *is* really resolved. > There are plenty of devs who don't share in the viewpoint that reopening > bugs is legitimate and should encouraged (although I agree it is and > should be). I base opinion that on some of the kicking and screaming > I've seen on bugzilla in the past. ;) Reopening WONTFIX, CANTFIX or INVALID bugs stating that "it's a bug because I screwed up everything and *you* must fix that for me" is something I don't really like. Reopening bugs because the fix isn't complete, or because there is still the same problem is fine. What is really annoying is getting bug reopened because after one bug is fixed there's something else not working right, and the reporter continues on the same bug report. One bug, one report. If after a fix there are still problems, open a *new* bug for a new issue. -- Diego "Flameeyes" Pettenò Gentoo Developer - http://dev.gentoo.org/~flameeyes/ (Gentoo/FreeBSD, Video, Gentoo/AMD64, Sound, PAM) pgprXToF4HALo.pgp Description: PGP signature
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sun, 10 Jul 2005 11:32:44 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]> wrote: | > Again, Gentoo is not a large corporation or Debian. | | I don't see how Gentoo's status (or rather lack thereof) as a | corporation or Debian has anything to do with encouraging peer review. You're taking methods from a "how your typical oversized software engineering bloatware project works" situation and trying to apply them outside of their domain. | > The assumption is | > that the majority of fixes are done correctly the first time, and | > this assumption is valid. | | I don't see how you could prove that assumption. If you can, please do | so. Experience. I receive bug mail for a heck of a lot of bugs. I see how many of them are indeed correctly resolved when they are marked as such. | > Hence, the default behaviour is to mark bugs as | > RESOLVED, with reopening being an entirely legitimate and encouraged | > response for those occasional instances where the resolution was not | > sufficient. | > | | There are plenty of devs who don't share in the viewpoint that | reopening bugs is legitimate and should encouraged (although I agree | it is and should be). I base opinion that on some of the kicking and | screaming I've seen on bugzilla in the past. ;) No, that kicking and screaming is reserved for when bugs are reopened inappropriately. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: > Good point. See my reply to Jon Portnoy for the latest revision of the > idea that would apply to everyone as an optional 'best practice'. Again, it doesn't really work like this. The groups you describe are different in nature, and certain procedures suit some groups better than others. Sure, we can write somewhere "its good to review bug fixes" but thats not really making any progress unless you can convert a particular group to do it as you describe. (As a sidenote, I don't think writing a general recommendation like that is such a good idea. At least, I can't see it working in the groups I am involved in.) Here's what I suggest you do: Pick a group. Subscribe to their mailing list. Write a mail to their list, stating clearly what you think the current problem is, and how you propose to solve or minimize it. Be prepared to back up your proposal with existing closed bug reports, where having someone explicitly review the fix and make a comment after the bug has been fixed would have been beneficial and would have made some positive difference. Try hard to understand their responses in full. As you've found out, its not easy to know whether your own suggestions would be worthwhile to a development community which you haven't had much involvement in (at least, not as much involvement as the people you are speaking to). Good luck :) Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 10 Jul 2005 11:08:41 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]> > wrote: > | Maybe as a start, the Developer's Guide can be revised to state that: > | > | "Ideally any bug that a fix is submitted for should be verified and > | peer reviewed. It should be verified by the reporter or another user. > | If the reporter or another user are unable or unwilling to verify the > | fix, the Team Lead should take responsibility for the verification. > | Ideally, all bug fixes should be peer reviewed by the Team Lead and/or > | other team members before the bug is marked as RESOLVED. > > Again, Gentoo is not a large corporation or Debian. I don't see how Gentoo's status (or rather lack thereof) as a corporation or Debian has anything to do with encouraging peer review. > The assumption is > that the majority of fixes are done correctly the first time, and this > assumption is valid. I don't see how you could prove that assumption. If you can, please do so. > Hence, the default behaviour is to mark bugs as > RESOLVED, with reopening being an entirely legitimate and encouraged > response for those occasional instances where the resolution was not > sufficient. > There are plenty of devs who don't share in the viewpoint that reopening bugs is legitimate and should encouraged (although I agree it is and should be). I base opinion that on some of the kicking and screaming I've seen on bugzilla in the past. ;) Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0T+c2QTTR4CNEQARAmhWAJ485c4s5MjMzQRUrCn4rR06qB/nDwCfQowx KGJfs0VkcxZO3yHOKKIPFwE= =LdlM -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sun, 10 Jul 2005 11:08:41 -0400 "Nathan L. Adams" <[EMAIL PROTECTED]> wrote: | Maybe as a start, the Developer's Guide can be revised to state that: | | "Ideally any bug that a fix is submitted for should be verified and | peer reviewed. It should be verified by the reporter or another user. | If the reporter or another user are unable or unwilling to verify the | fix, the Team Lead should take responsibility for the verification. | Ideally, all bug fixes should be peer reviewed by the Team Lead and/or | other team members before the bug is marked as RESOLVED. Again, Gentoo is not a large corporation or Debian. The assumption is that the majority of fixes are done correctly the first time, and this assumption is valid. Hence, the default behaviour is to mark bugs as RESOLVED, with reopening being an entirely legitimate and encouraged response for those occasional instances where the resolution was not sufficient. -- Ciaran McCreesh -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris White wrote: > Doc is still here: > > http://www.gentoo.org/doc/en/bugzilla-howto.xml > > After a good ammount of user input the bugzilla doc has been updated. The > new version uses ggdb3 instead of g for debugging and contains a new section > on testing ebuilds. Thanks goes to robbat2 for his commentary on what to > improve. Thanks goes to the people who help fix my crap for grammar mistakes > ;). So far it seems to be comming along nicely, I've been notified of the > upgrade to bugzilla comming soon, and will update my screenshots and other > information accordingly. Thanks again to everyone. > > Chris White This sort of thing could reduce the number of INVALID and NEEDINFO bugs. Great job! Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0TvG2QTTR4CNEQARAl3LAKCd4ODRkgSLpgf64yz1BcrGZAbnAwCeKPg+ RNBnuP0w+ISiDU2XFvqU3js= =c30Y -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Drake wrote: > Nathan L. Adams wrote: > >>What do you think about adding the step only to certain critical >>products, such as Portage or maybe Catalyst or even the Installation Docs? > > You're now significantly altering your proposal, from something that affects > almost everyone, to something that affects only some 'minority groups'. Nobody > can give you a straight single answer. The whole point of this discussion is to get feedback and alter the idea as needed, not to beat everyone over the head with the Original Idea (c) until everyone sees it My Way (TM). So kindly pick the version of the idea that you like best, and base your discussion on that. ;) > For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on > the catalyst mailing list. For installation docs, ask on the docs mailing > list. These groups are significantly different, have their own distinctive > procedures, etc. Good point. See my reply to Jon Portnoy for the latest revision of the idea that would apply to everyone as an optional 'best practice'. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0TtM2QTTR4CNEQARAjeAAJ0bhA31Oc0Ho5mRnjkjCvg5zZZVkwCgm7Ib ehPatwEpWl9LdD59n8HJnxE= =J1U+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Portnoy wrote: > On Sun, Jul 10, 2005 at 09:49:16AM -0400, Nathan L. Adams wrote: > >>To restate the problem: When a dev submits a fix for a bug, it should be >>verified and peer reviewed before the bug is marked done. >> > > > That's not a problem, that's an opinion. > > I'm not at all convinced that not having every bug resolution reviewed > every time is a problem, maybe you should start there :) > Well originally I was going for "any bug that a dev thinks has merit", but after reading some of the replies I'm now leaning towards "any bug that a dev submits a fix for". And I've also fielded the idea that it only be mandatory for certain critical products such as Portage. Maybe as a start, the Developer's Guide can be revised to state that: "Ideally any bug that a fix is submitted for should be verified and peer reviewed. It should be verified by the reporter or another user. If the reporter or another user are unable or unwilling to verify the fix, the Team Lead should take responsibility for the verification. Ideally, all bug fixes should be peer reviewed by the Team Lead and/or other team members before the bug is marked as RESOLVED. The following products have been deemed critical, and therefor must follow the above process: X Y Z" Then it becomes a completely optional 'best practice' for the vast majority of bugs. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Tn52QTTR4CNEQARAliRAJ9CNmaI5OnHd4i1w0UKHEBq2e9XxgCgk2Hh 4Ep0I76PAIb9ItQCmD/929E= =YQOy -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New Bugzilla HOWTO Update
Hi Chris, Chris White wrote: > Doc is still here: > > http://www.gentoo.org/doc/en/bugzilla-howto.xml I've just read over it in full. It looks good - thanks for writing it. As you know, I've been meaning to write one of these for a while. I've been keeping a list of topics I think should be mentioned. Stripping out the ones you have covered, here's what I have left: maintainer-needed description maintainer-wanted description why isnt my bug being looked at why isnt my ebuild being looked at what are bug-wranglers never reassign a bug dont close as fixed just because you have a workaround if in doubt, let the developer close it link to how to go into the testing tree make sure you are using the latest version always try the testing package before reporting bug dont pollute existing bugs by posting unrelated or related problems. use one bug for one issue. always post "emerge info" always upload as plain text always attach large postings, never paste always use unified diff always post stuff on the bug, never in private email unless requested if you find a duplicate bug, instead of filing yours, tag onto the end of the existing one, even if the information you are adding does not differ debugging with dmesg never say "it doesnt work" or "it crashes" post config.log if it fails during configure why did you mark it as upstream instead of fixing it yourself how to apply patches in general how to apply patches in ebuilds Since the doc is already covering a lot of content, and adding some of these points to it will broaden it further, I think it makes sense to have 2 docs. One for "how to report a bug", and another for "how to give us lots of yummy info" in a bug report. Something like: How to report a bug: - Search, check that nobody has filed it already - Fill in the form under the right product - How to get "emerge info" output - General policy stuff: - If attaching, use plain text and never tarballs - Don't reassign bugs, leave that to devs - Don't close just because you have workarounds - What to do if your bug isnt getting attention - maintainer-needed/wanted description etc How to give us lots of yummy info: - How to apply patches - How to use strace - How to identify a configure failure - and how to upload config.log - How to use gdb, for C apps - Using valgrind? etc That way, most users will find all the information they need in the first doc, without being scared away by scary stuff. It would also serve as a document that you can read and understand in full before filing your first bug. Those who have the time and experience can go onto the second doc and learn how to help us debug the problem after the bug has been filed. It could also be used as a reference thing, e.g. on a kernel bug, I'll say "please try this patch", user says "how?", it would be nice if i could point them to a specific page on the tech doc. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sunday 10 July 2005 22:55, Nathan L. Adams wrote: > What do you think about adding the step only to certain critical > products, such as Portage or maybe Catalyst or even the Installation Docs? Portage doesn't have a team lead as such. All bug traffic is delivered to all members via email though, so what is it that you are actually asking for? Regards, Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: > What do you think about adding the step only to certain critical > products, such as Portage or maybe Catalyst or even the Installation Docs? You're now significantly altering your proposal, from something that affects almost everyone, to something that affects only some 'minority groups'. Nobody can give you a straight single answer. For portage, ask on the gentoo-portage-dev mailing list. For catalyst, ask on the catalyst mailing list. For installation docs, ask on the docs mailing list. These groups are significantly different, have their own distinctive procedures, etc. Daniel -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New Bugzilla HOWTO Update
Doc is still here: http://www.gentoo.org/doc/en/bugzilla-howto.xml After a good ammount of user input the bugzilla doc has been updated. The new version uses ggdb3 instead of g for debugging and contains a new section on testing ebuilds. Thanks goes to robbat2 for his commentary on what to improve. Thanks goes to the people who help fix my crap for grammar mistakes ;). So far it seems to be comming along nicely, I've been notified of the upgrade to bugzilla comming soon, and will update my screenshots and other information accordingly. Thanks again to everyone. Chris White pgplZ64L3ZpOJ.pgp Description: PGP signature
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Sun, Jul 10, 2005 at 09:49:16AM -0400, Nathan L. Adams wrote: > > To restate the problem: When a dev submits a fix for a bug, it should be > verified and peer reviewed before the bug is marked done. > That's not a problem, that's an opinion. I'm not at all convinced that not having every bug resolution reviewed every time is a problem, maybe you should start there :) -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R Hill wrote: > Nathan L. Adams wrote: >> But come on guys, I'm suggesting *one* look at a bug by an independent >> party before marking it done. > > > That's reasonable, but I don't see that party being a Team Lead or even > a dev. If there's a bug filed and another user can confirm it, it's > Verified. That's the whole idea behind the status. I'm suggesting that the Team Lead be ultimately responsible, not that the TL has to verify each bug. The best case would be that all bugs get verified by the reporter (or another user as you suggest). The worst case is that no reporters or other users verify the bug, so *then* the TL gets the job. > I don't really see much to gain by adding another step in the bug > reporting process. Some projects use it, some don't. I don't think > b.g.o is formal enough re. bugzilla to warrant it. I'm suggesting that making b.g.o a *little* more formal might be a Good Thing. What do you think about adding the step only to certain critical products, such as Portage or maybe Catalyst or even the Installation Docs? > I do agree with the original point. Reports shouldn't be marked > resolved unless the bug is fixed or permanent, or not enough info is > given to verify that a bug actually exists. As Mike keeps pointing out, the NEEDINFO status covers bugs that a dev can't reproduce, etc. But my suggestion only covers bugs that a dev has provided a fix for (irreguardless of whether the dev reproduced the bug or not). Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Sjc2QTTR4CNEQARAvCdAJ4tJaecjuA2mQRtiOZ8O9pDOt4kHQCfaMGP wtIxSh8fX218TXlYyOfBgQs= =iPoD -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R Hill wrote: > a) what would be the point of the reporter also being the verifier as > far as confirming that the bug is real and not a PEBKAC error? Sometimes devs do clever things to their systems that end-users aren't aware of, or they test the fix logged into their machine with special priviledges, etc. So having the reporter verify would test the fix with those things out of the loop. > b) what would be the point of requiring that verification be done by a > third party if the dev the PR is assigned to can reproduce the bug > themselves? I'm assuming that this would only apply to cases where the dev has provided a fix (in most cases I assume they would have reproduced the problem). The reporter's test would have the benefits mentioned above, and if the Team Lead tested, they could review the fix for technical correctness, etc. > c) how do you propose the assignee fix the bug if they cannot reproduce > it? this may be possible in some cases, but not anywhere near the > majority. My suggestion doesn't even cover that; it assumes that the dev has provided a fix. > d) team leads lead the team, not attempt to reproduce bugs for every PR > that falls under their umbrella. to be blunt, they have much better > things to do. Is it out of the scope of the Team Lead to check that [his|her] devs are fixing things in a technically correct manner? From the "Gentoo Developer Handbook": "Team leads are responsible for organizing the developer in their team and coordinating releases and also resolving issues within the team, as well as improving products on the basis of feedback from the community." http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=5 I think a bug report qualifies as feedback from the community and verifying that a bug fix actually works would qualify as improving products. > Dear Nathan, > > In your spare time, could you please begin testing every new problem > report filed as of now for validity and tag them appropriately? This > small, incremental move should greatly improve our QA process. Thanks boo. Again, my suggestion attempts to improve the process farther down stream; the problem of validating new bugs and tagging them appropriately is a separate matter. Also, suggesting that I do all the work is silly. It suggests, to me at least, that you can't find anything wrong with what I'm suggesting, but for some reason or another you're unwilling to change your working habits. So you throw up the "if its such a good idea, you do it... ALL of it!" nonsense. Obviously, no process (including the current Gentoo bugzilla process being used daily) will work without participation from most of the people involved. There will *always* be people who disagree, and there will *always* be people who skirt the system in some way. That's just life. > Note: I am not denying there could be a (small) policy problem, I'm just > pointing out that the proposed solution is unworkable. Great! Can you think of any ways to make my idea workable? What about a completely different solution? To restate the problem: When a dev submits a fix for a bug, it should be verified and peer reviewed before the bug is marked done. Nathan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0Sdc2QTTR4CNEQARAsh+AJ93PRmC0JLJlBNV3kSbFlKR2vOkOgCdEpvq 2SVJFg/G2B0sb8CXTstOGEY= =CAPL -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: > Dear Nathan, > > On Sat, 2005-07-09 at 12:04 -0400, Nathan L. Adams wrote: > >>But come on guys, I'm suggesting *one* look at a bug by an independent >>party before marking it done. > > > Great! Thank you for your offer to review our bugfixes. Please start > right away. > Are you offering me a job? ;) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0R8t2QTTR4CNEQARAjV8AJ0QgimQUfj2PxpfC18jBB42dNirRgCfXZYt 0v6Tj6qMJU8Cmj+ZApi/Pkk= =wyyT -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
R Hill posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 10 Jul 2005 01:39:18 -0600: > Marco Matthies wrote: >> Nathan L. Adams wrote: >> The person reporting the bug can reopen the bug, as he/she is in a >> perfect position to test the fix. > > Just a thought I've had from time to time - why can't people other than > the reporter reopen a resolved bug report? I'm thinking that there are > cases where the reporter files a PR that gets marked resolved for > whatever reason and then buggers off. Later someone else comes across > the bug and can either comment in the closed bug and hope someone > notices or file a new report which will inevitably be marked Dupe. > What's the correct thing to do in this situation? Here's how I've handled it. I've filed a new bug, mentioning the other one by number (which bugzilla will automatically turn clicky to reach the old one, if you give it the proper hint, bugzilla #xx) in my report, and detailing why the issue remains, either detailing how this report is the same issue and the fix either wasn't right or wasn't reapplied to a new version, or detailing how this one may /look/ similar but is /not/ the same, because x and y and z are different. This works well enough, because it's known that only the original reporter can reopen, so they aren't expecting you to do something you can't do. Further, you preempt the duplicate thing, by saying why this one is different or why the problem reoccurred. For those unable to trace the technical details, simply saying the same problem appears to occur with a new version, or still occurs for them with the old version, or whatever, should suffice. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] net-wireless/linux-wlan-ng scheduled for package.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henrik Brix Andersen wrote: > > If you have an (USB?) adapter, which works with linux-wlan-ng, but not > with orinoco-cvs, I would like to hear about that too. I have a Flybook with a Prism 3 usb adapter and I have been succesfully using linux-wlang-ng with it. Following your suggestion I tried orinoco-cvs and this is what dmesg gives me: usbcore: registered new driver prism_usb usb 2-3: new full speed USB device using ohci_hcd and address 7 prism_usb_hard_reset - dummy prism_usb_init - dummy prism_usb_init - dummy prism_usb_allocate - dummy prism_usb_read_ltv - dummy eth1: Cannot read hardware identity: error -95 eth1: Incompatible firmware, aborting prism_usb: Cannot register network device prism_usb: probe of 2-3:1.0 failed with error -95 I know linux-wlan-ng has its problems but it might still be the only working driver for some people with usb devices. I am willing to take maintership if they one day accept me as a dev. I am currently in mentoring with the java herd. You can contact me as [EMAIL PROTECTED] > Sincerely, > Brix Regards, Petteri Räty -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC0QvkcxLzpIGCsLQRAobBAJ46B2zt/IiVHV4OnhQd7Rh/0HrSVgCePk7L iG34n4L58zMsCvbU5cmGYFE= =bK0X -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Dear Nathan, On Sat, 2005-07-09 at 12:04 -0400, Nathan L. Adams wrote: > But come on guys, I'm suggesting *one* look at a bug by an independent > party before marking it done. Great! Thank you for your offer to review our bugfixes. Please start right away. Thanks again. Sincerely, Brix -- Henrik Brix Andersen <[EMAIL PROTECTED]> Gentoo Metadistribution | Mobile computing herd signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed security policy for web-based apps
On Fri, 2005-07-08 at 12:58 +0200, Martin Schlemmer wrote:
> Stupid question .. why does webapps.eclass have SLOT=${PVR} ?
If you're running a hosting server, and have many customers using the
same app, it may not be practical to bump them all at the same time.
* They may have different busy periods during the day, making it
impossible to schedule a common downtime.
* Many upgrades require manual steps - it's less disruptive to upgrade
each installation one at a time.
* Different customers may want or need to run different versions of the
same app. If a customer is happy with what they have, they may not wish
to upgrade.
> This
> basically means that even a bump from foo-webapp-1.0-r1 to
> foo-webapp-1.0-r2 will not unmerge foo-webapp-1.0-r1 ...
If you don't have USE=vhosts set, then the eclass will automatically
unmerge the older version. If you have USE=vhosts set, then you're
telling Portage that you need the flexibility of running webapp-config
manually.
Best regards,
Stu
--
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer http://www.gentoo.org/
http://stu.gnqs.org/diary/
GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C
--
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed security policy for web-based apps
Hi, On Wed, 2005-07-06 at 20:10 +0200, Radoslaw Stachowiak wrote: > On 7/5/05, Stuart Herbert <[EMAIL PROTECTED]> wrote: > > I'd like to introduce the following security policy for web-based apps. > > Why only web-based apps? What about other tools and apps exposed to the > network? That's for other herds and developers to decide for themselves. My proposal is aimed at the web-apps herd, which I am a member of. There's nothing stopping anyone writing up a security policy GLEP if they want to apply a policy to a wider range of apps. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed security policy for web-based apps
On Wed, 2005-07-06 at 00:30 +0200, Marius Mauch wrote: > Hmm, what's the criteria to decide if something falls under this policy > or not? Package category, maintainership, dependency on webserver, ...? > > Marius The only criteria I can suggest is that any package which is maintained by the web-apps herd would fall under this policy. I'd love to see this policy adopted for all web-based packages, but I respect the right of developers to make their own decisions about what they think is best. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed security policy for web-based apps
On Tue, 2005-07-05 at 23:12 +0100, David Morgan wrote: > > > 1. The Gentoo package's maintainer will identify one *named* contact > > >UPSTREAM for security-related matters, and one named general contact > > >UPSTREAM (as a fallback for when the security contact is > > >unreachable). > > And what happens if upstream is only one person? In that case, it wouldn't be possible to have a fallback. I wouldn't want to exclude a package just because there's only one upstream dev. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Proposed security policy for web-based apps
On Tue, 2005-07-05 at 17:52 -0400, Alec Warner wrote: > > 3. This information will be checked every three months to ensure it > >remains valid. > > Are you volunteering to do 3? If not, who will? I'm proposing that 3. is the responsibility of the webapps herd Strategic and Operational Leads - positions we need to create and elect developers to. Whether they do it themselves, or delegate it, would be for them to decide. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: > (a) Its not a waste of time, and it is a FACT that peer review improves > quality. I don't think anyone is disputing that it would be a beneficial concept, in terms of improving quality and feedback. However the suggestion you are making is really not practical in our development model. Daniel -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposed security policy for web-based apps
On Tue, 2005-07-05 at 15:40 -0500, Lance Albertson wrote: > Yeah, having it in metadata.xml would make more sense. We can do that. It'd perhaps make sense to extend the DTD for metadata.xml, so that the tag has 'type' and 'organisation' attributes. This would allow tools to tell the difference between an entry for a Gentoo maintainer, and an entry for an upstream maintainer. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://stu.gnqs.org/diary/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Marco Matthies wrote: Nathan L. Adams wrote: The person reporting the bug can reopen the bug, as he/she is in a perfect position to test the fix. Just a thought I've had from time to time - why can't people other than the reporter reopen a resolved bug report? I'm thinking that there are cases where the reporter files a PR that gets marked resolved for whatever reason and then buggers off. Later someone else comes across the bug and can either comment in the closed bug and hope someone notices or file a new report which will inevitably be marked Dupe. What's the correct thing to do in this situation? --de. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
Nathan L. Adams wrote: living. I know this fact: Sometimes the developer doesn't realise what the actual problem is. Sometimes its because the end-user didn't communicate well. Sometimes its because the developer is being an ass (we've all been guilty of this). *That* is why verification should be done not by the person writing the fix. It should be by an independent party; Team Lead, reporter, etc. a) what would be the point of the reporter also being the verifier as far as confirming that the bug is real and not a PEBKAC error? b) what would be the point of requiring that verification be done by a third party if the dev the PR is assigned to can reproduce the bug themselves? c) how do you propose the assignee fix the bug if they cannot reproduce it? this may be possible in some cases, but not anywhere near the majority. d) team leads lead the team, not attempt to reproduce bugs for every PR that falls under their umbrella. to be blunt, they have much better things to do. "Dear Developers Who Take Constructive Critizism as Insults, Please grow thicker skin. No one is out to get you. Believe it or not, the people trying to improve the process are on your side, and they're not trying to insult you. No one is saying that because the process could be better that your work is somehow diminished. Sincerely, Nathan Dear Nathan, In your spare time, could you please begin testing every new problem report filed as of now for validity and tag them appropriately? This small, incremental move should greatly improve our QA process. Thanks boo. XOXOX --de. Note: I am not denying there could be a (small) policy problem, I'm just pointing out that the proposed solution is unworkable. -- gentoo-dev@gentoo.org mailing list
