Re: [gentoo-dev] Re: Closing bugs [was: New Bugzilla HOWTO]
On Friday 08 July 2005 11:46 pm, Nathan L. Adams wrote: Mike Frysinger wrote: This brings up a point that really irks me. In the bug, I believe the dev implies that the reported bug has merit /yet he closes the bug before actually doing something about it/. And I don't mean to pick on Jeffrey; this seems to be a common habit among Gentoo devs. that's because we got tired of asking for more info/whatever and never getting anything back ... so we close the bug, get it off our 'todo' lists, and wait for the user to get back to us (not all do) this is the biggest reason NEEDINFO was created Having the reporter be the verifier is a great idea (probably ideal), but again, you could assign the verification to the Team Lead. If the Team Lead can get the user to respond, great, otherwise they could do the QA themselves. you missed the point of NEEDINFO the bug is closed as NEEDINFO until the reporter gets back to us ... then it's re-opened ... in fact, the entire point is that the reporter *never responds again* so having them verify anything doesnt make any sense in this case -mike -- gentoo-dev@gentoo.org mailing list
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 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] 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
[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] 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
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]
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
[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 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] 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]
-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] 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] 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]
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] 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]
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]
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]
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
[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, 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
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] 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 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] 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] 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 maintainer 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 ticho at gentoo dot org Gentoo Linux Developer - net-mail, antivirus, amd64 pgpYzxlW3CxkO.pgp Description: PGP signature
[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
