Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On Tue, 4 Dec 2012 18:51:36 + Markos Chandras hwoar...@gentoo.org wrote: Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. The b-w project page already explains how you can get someone in the Assignee field: by listing them first. Nothing needs to change except people's desire to format metadata.xml in whatever pretty pleases them. For anyone who doesn't want to go and look it up: The bug's Assignee field will have: 1) First listed maintainer from the top of the file 2) Lacking maintainer tags, the first listed herd tag The bug's CC field will contain every maintainer and herd left, except upstream ones. Elaborate descriptionAssign to this person when in doubt, but not during a full moon/description tags are likely to get ignored. Tags like maintainer restrict=gt;=sys-boot/grub-2... complicate matters slightly, but are much more useful than description tags (or !-- comments --, FCOL) that explain intricate hierarchical maintainer modes. Regards, jer
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 4 December 2012 17:19, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 01:18, Ben de Groot yng...@gentoo.org wrote: In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin As I said, the only drawback is that devmanual will become huge and without a proper search functionality, it will be a real pain to search for something quickly. Especially for new developers who are not familiar with how devmanual is structured. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2 Except the situation now is worse. Things are spread over multiple documents, and we don't have a proper site search. Even so, 1) Google is your friend, and 2) a single document with a good index would be a step forward. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 5 December 2012 02:51, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 17:28, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. Actually, as I have been arguing elsewhere, scattering policies over multiple documents is not helpful. So this should be documented in devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 6 December 2012 11:02, Ben de Groot yng...@gentoo.org wrote: On 5 December 2012 02:51, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 17:28, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. Actually, as I have been arguing elsewhere, scattering policies over multiple documents is not helpful. So this should be documented in devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. However, it is possible to add a note on metadata.xml section in devmanual to explain how to structure a metadata.xml file for proxy maintainers. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
Markos Chandras wrote: This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. The reason is that I as a developer (whenever I become one) want to be able to fix stuff right now that is broken on my system and publish those fixes somewhere. I believe and hope that working with bugs will see new approaches when the warm git blanket is swept around the portage repo. In the last 15 hours I've dealt with several trivial bugs that I've found fixes for in bugzilla but which were not committed anywhere. I've committed them to my overlay and that's fine for me, but if I were a developer I would find it super lame to have to stop there and wait for $otherguy to take time to look at his bugs. The bugs are equally much mine, because they bite me. I'm not saying I expect to change everyone's ebuilds, but I'm saying that I think the bug tracker has way more emphasis today than I would like it to. I think most of that is because it simply couldn't have worked any other way. In the future it might, and I think that's good. I would expect to fix the bugs, and then email patches to whoever is the maintainer. It would be worthwhile to have automatic extraction of who needs to get that email based on what files were touched. No bug needed, if maintainers get perfect patches in email they can review them quickly and simply push them into the tree. End result: Everyone has mandate to fix bugs and it becomes so easy for maintainers to apply fixes that they can do it immediately when anyone sends a perfect patch. The dream scenario would be a gerrit instance in front of the repo. (Yes infra, that means Java. Sorry, but that tool is best in class IMO.) Finally my thanks to everyone who helps make Gentoo better every day! //Peter
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 06/12/12 10:27 AM, Peter Stuge wrote: [ Snip! ] In the last 15 hours I've dealt with several trivial bugs that I've found fixes for in bugzilla but which were not committed anywhere. I've committed them to my overlay and that's fine for me, but if I were a developer I would find it super lame to have to stop there and wait for $otherguy to take time to look at his bugs. [ Snip! ] I would expect to fix the bugs, and then email patches to whoever is the maintainer. It would be worthwhile to have automatic extraction of who needs to get that email based on what files were touched. No bug needed, if maintainers get perfect patches in email they can review them quickly and simply push them into the tree. There's a bit of an issue with this, though -- for many projects, and many bugs, patches are not committed to the tree until that bug and patch has been submitted upstream (job of the maintainer) and upstream has approved or accepted that patch. I think quite often this is why patches sit in bugs instead of getting to the tree. Essentially, if the problem is with the ebuild or the way the package is integrated into gentoo, then fixing it immediately is fine. If the problem is with the software itself, then usually upstream needs to be involved before the fix will occur in gentoo. Also, Emailing patches to the maintainer is much less acceptable/desirable than filing them through bugzilla. As a developer, I find it much easier to grab patches from this nice centralized bug-tracking filing system than to have to organize them in email, and git integration is not something I see changing this. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDAv7EACgkQ2ugaI38ACPCQ/QEAmYjna1exh9qxqptbdB08Hvoo TzJi72ux2nf9edZsR3IA+wXENBA1EDuc/8JDN74aJ0/iFdhL1yG2CxJ515tNDxxX =4d2v -END PGP SIGNATURE-
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
Ian Stakenvicius wrote: Essentially, if the problem is with the ebuild or the way the package is integrated into gentoo, then fixing it immediately is fine. If the problem is with the software itself, then usually upstream needs to be involved before the fix will occur in gentoo. Yes that's fair of course. None of the handful issues I've had so far while building 900 packages were about upstream however. Also, Emailing patches to the maintainer is much less acceptable/desirable than filing them through bugzilla. As a developer, I find it much easier to grab patches from this nice centralized bug-tracking filing system than to have to organize them in email, and git integration is not something I see changing this. Have you tried gerrit? It is really a leap ahead. //Peter
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 6 December 2012 15:27, Peter Stuge pe...@stuge.se wrote: Markos Chandras wrote: This policy is for the bug-wranglers project, which someone must read before he attempts to do any bug-wrangling. I see no reason to move this to devmanual. The reason is that I as a developer (whenever I become one) want to be able to fix stuff right now that is broken on my system and publish those fixes somewhere. ... I am not sure I understand how this is related to this discussion. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2012 10:21 AM, hasufell wrote: As I was told in my recruiting process we usually don't just fix up ebuilds of other devs unless it's trivial, very severe or something. The usual process is nothing new: try to contact the maintainer, open a bug, set a deadline when you will go and fix yourself. Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. I tried to document that a bit: https://bugs.gentoo.org/show_bug.cgi?id=445402 any objections? This is nothing new, just a clarification of already existing policy and a reminder. If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. I would suggest something in the metadata.xml under the maintainer section. We could have a specific maintainer section : maintainernamehelp welcome/name/maintainer or a specific tag to put under our own maintainer section maintainernameRick Farina/namedemeanorjust fix it/demeanor/name I currently, and will continue to maintain a completely open policy on my packages. To write in the rules that this is not acceptable would be more than rude. Thanks, Zero PS I don't actually mean for either of those suggestions to be used mind you, it's just an example. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQva/iAAoJEKXdFCfdEflKFkwP/jBl4I1qFtTPFh52FfBJF7yX h4fQSisiYYFitwzWDVoxjkAbKdfdSTxmevkJfRUfIz7AG+8rBjrndHJscwQQXCCm 3533r5B0ql6cXI38pb7WSJdc6xplXx1NVTsPFwxn7rmJVKddFPfa8nOv1dUfjjFN 16Yc6B2oV9rfb0AkaUdnAYNJLgjP5gL7AXIJoScUcPVXJZ/glWp/ADmlN+sKsKoy bOBe1Hbm2Z5tTNPun4zOqKtb34daBbLjbtYHz4fR2r+MdbgHQKUIdO1z8iBE6+fR /cOCbN+64jG7Yz3G1n+6rXfFBocRjkin8fEk4hXaZ7FkHOa5w7ONRNFvqmQ+BBfa 4SlI/scZ6lEDMi4GDFMdX/ShdaptXvHYcaJIKyE//EP6Q40Ijtqe2HUv1eUjbR5V /HfTapF8YnxX6NZwQPTihpMv3TCneTbKH3anHuWLR3wK0SAMraP6zqYIImfPG0Pt ePm+dRQ6ocZIoDuGroYX9gInqLRqeI+2EWFLMvN3VkDq358N1tX5PhGfTw6AUCw7 ao3iZkE3n49xywSYzDAsschoV7iWoJfBdSYbcqRcok/3Z1sEBRd6P2wc6NMFJbO3 rWpCDj3vrg08Up6CJIgAsh4r3e5McAcvwycTcWEaDCDgRujjcJN6iN5JR4zur5AK JNc0sFc3rrPHo4Pyu079 =ZBY6 -END PGP SIGNATURE-
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 4 December 2012 01:18, Ben de Groot yng...@gentoo.org wrote: On 3 December 2012 03:30, Markos Chandras hwoar...@gentoo.org wrote: On Dec 2, 2012 6:09 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich Maybe adding some bits here[1] is preferred instead of the devmanual. Unless we agree to make devmanual a technical and non-technical document, which I personally don't like because it will end up being huge without some sort of indexing/search textbox for quick queries. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2 In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin As I said, the only drawback is that devmanual will become huge and without a proper search functionality, it will be a real pain to search for something quickly. Especially for new developers who are not familiar with how devmanual is structured. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 4 December 2012 08:10, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2012 10:21 AM, hasufell wrote: As I was told in my recruiting process we usually don't just fix up ebuilds of other devs unless it's trivial, very severe or something. The usual process is nothing new: try to contact the maintainer, open a bug, set a deadline when you will go and fix yourself. Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. I tried to document that a bit: https://bugs.gentoo.org/show_bug.cgi?id=445402 any objections? This is nothing new, just a clarification of already existing policy and a reminder. If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. I would suggest something in the metadata.xml under the maintainer section. We could have a specific maintainer section : maintainernamehelp welcome/name/maintainer or a specific tag to put under our own maintainer section maintainernameRick Farina/namedemeanorjust fix it/demeanor/name Nobody said the opposite. The devaway message should always be checked for people who appear to be inactive and if they say Do not touch my packages then you shouldn't touch them even if he doesn't even touch them himself. Let the retirement team kick him out. There is always the description tag on metadata.xml you can use eg maintainer emailf...@gentoo.org/email nameMe/name descriptionPrimary maintainer but feel free to fix the bugsdescription /maintainer -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On Tue, Dec 4, 2012 at 1:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 01:18, Ben de Groot yng...@gentoo.org wrote: On 3 December 2012 03:30, Markos Chandras hwoar...@gentoo.org wrote: On Dec 2, 2012 6:09 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich Maybe adding some bits here[1] is preferred instead of the devmanual. Unless we agree to make devmanual a technical and non-technical document, which I personally don't like because it will end up being huge without some sort of indexing/search textbox for quick queries. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2 In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin As I said, the only drawback is that devmanual will become huge and without a proper search functionality, it will be a real pain to search for something quickly. Especially for new developers who are not familiar with how devmanual is structured. site:devmanual.gentoo.org term Works in bing, I tried it! It likely works in any modern search engine. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 04:23 AM, Markos Chandras wrote: On 4 December 2012 08:10, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2012 10:21 AM, hasufell wrote: As I was told in my recruiting process we usually don't just fix up ebuilds of other devs unless it's trivial, very severe or something. The usual process is nothing new: try to contact the maintainer, open a bug, set a deadline when you will go and fix yourself. Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. I tried to document that a bit: https://bugs.gentoo.org/show_bug.cgi?id=445402 any objections? This is nothing new, just a clarification of already existing policy and a reminder. If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. I would suggest something in the metadata.xml under the maintainer section. We could have a specific maintainer section : maintainernamehelp welcome/name/maintainer or a specific tag to put under our own maintainer section maintainernameRick Farina/namedemeanorjust fix it/demeanor/name Nobody said the opposite. The devaway message should always be checked for people who appear to be inactive and if they say Do not touch my packages then you shouldn't touch them even if he doesn't even touch them himself. Let the retirement team kick him out. There is always the description tag on metadata.xml you can use eg maintainer emailf...@gentoo.org/email nameMe/name descriptionPrimary maintainer but feel free to fix the bugsdescription /maintainer maintainer emailf...@gentoo.org/email nameMe/name descriptionProxy maintainer, assign bugs to proxied maintainer, cc on bugs, but feel free to just fix the bugsdescription /maintainer I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvh4+AAoJEKXdFCfdEflKbp8P/2x+DGuDTlLv1ZKJjTQn1zpy nf6izcfmYcoqaGTIgL5ynFaGmv/H3U6LX42G/kL041bqUn9SjozM+liU+k0RzrQ1 SQcJUPs1tc4qzp+loWnXZnPDWmUJLkRI7n1B/O9SnvEl1g1LxXKmc2j9w51kYWmz 9Lowv3/CKGhWjow5A05DEzNya7bShjm/9tJulXltIL7H0IeC0cZGJeB5/cD7+Qfz TwugXiGNIWp0gErBUDa9wYdgzI2Z8LEc8IrQhUQS+56IF/ZNcwYP0zJi1S7YEYAs YVtCMPrUt/JmMKDluDlxQ9JXJ3YZkbz7Eb/iwAXFHlJYNWkf9hjWtQfDmzETx7xu wqNKF9m1IpoQANgsZRgsKdyAG56ELUW7QtfFNbVTYy0LGu36yZ2Hc3zbZNMvjZhP T8GYIF/5My89gNdBonHuZ7ub0zP1NpTFWI3qrNdzgI5Ko+aaH75y1Hz+puCwlHOG Ht0HbhpqRYidos2NSppecGhl9p5oZ8xZI/rVh/BgjtonJrXlIEfYzhUQHU4SzIxt v0hVJTIXq1RwE7gF4OGLEbpGTM5V0BcdT+FzSRuq5bJiAEvDLXIixdMh5kga6t7F e9H0iM5aRl9pxO1Rs0bOJmZhoZ+vwyOs/aPLYDNmNx8aNLicIWqfs2aGgjK7G8Y+ QYrB3h0du6gZymOZ+oys =IpQP -END PGP SIGNATURE-
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 05:01 PM, Rick Zero_Chaos Farina wrote: maintainer emailf...@gentoo.org/email nameMe/name descriptionProxy maintainer, assign bugs to proxied maintainer, cc on bugs, but feel free to just fix the bugsdescription /maintainer I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. Please start a new thread, this is unrelated to introducing a _global_ policy on that issue. On 12/04/2012 09:10 AM, Rick Zero_Chaos Farina wrote: If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. This certainly depends on the severity of the bug. If you think my text can be improved please provide a new patch or tell me what exactly you would describe differently. The vague character of this policy is a bit on purpose, otherwise you would have to describe every possible case. That's not what I want here. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQvixWAAoJEFpvPKfnPDWzigwH/RtjCwIncSB0DREo6rJhV+aV MitPqMpR1N+2GAcNs/Bmt9ocWyw2p2mWoPagAlffp6VAoCCg4ocr6xEEsRJUT0ai xsIBBPC+t+B08GtxdFhv8dWLUrPsVt0N4YwcQ7JmYE8YjDYr6vVxSOBMqmnjX98i Lsls2QgIdadhsQmPkaz/H5lxTPyxeesCNgsWOejvpJMNFpN6jqcpaMb1jwiqJF9g aYpU3LMniHeK92RXBv8t/uyYzRaoYLLEzPqXSXGFgxQ0CXsIF9Ub/230n9xCMHG4 +ep3zLl4VsyZcPkwkatwypfHvBRyBNFP3Kv4Ey0q5ipzNxEbAryfRaPqgOqX4Ds= =eSK5 -END PGP SIGNATURE-
Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 04/12/2012 08:01, Rick Zero_Chaos Farina wrote: I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. because, you know, that's the only way a proxy maintainer can close/change a bug at all. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 12:01 PM, hasufell wrote: On 12/04/2012 05:01 PM, Rick Zero_Chaos Farina wrote: maintainer emailf...@gentoo.org/email nameMe/name descriptionProxy maintainer, assign bugs to proxied maintainer, cc on bugs, but feel free to just fix the bugsdescription /maintainer I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. Please start a new thread, this is unrelated to introducing a _global_ policy on that issue. I'm sorry but isn't specific policy related to global policy? Why yes, yes it is. On 12/04/2012 09:10 AM, Rick Zero_Chaos Farina wrote: If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. This certainly depends on the severity of the bug. If you think my text can be improved please provide a new patch or tell me what exactly you would describe differently. A patch against what? I've not seen a link, only vague references to the dev manual. The vague character of this policy is a bit on purpose, otherwise you would have to describe every possible case. That's not what I want here. If we are vaguely defining a policy of not touching other peoples packages then the only specific thing in that policy should be what is exempt (which would be if xyz is in the metadata.xml then follow those instructions over this policy). This is VERY much on topic. I am really unhappy that people are writing policy that will get me less help and more work, and I won't be happy until I have a way to tell others that in the metadata.xml and the policy you are writing refers to it. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvjAQAAoJEKXdFCfdEflK0hoP/2IdAy65cH1ZQQo0riNthZJu vCkz0xmW6RB3woJDBy3Z98sbr/b1SLp7iBJ4EL11/CTj7HPtgTRrJc4lsTAXVMto TZDOV8IMAY8nK8Xscf3Lm3mmSF36741KyM/T48VyLZ5byy5Awr12DDCXaO3usL0a fexcwHtNLA5HEyhcvYNNfFNprBTU4CHRxusb/xJxy/sHGffeeE58blXqcFR4qbL6 8N0Kl7E2uu8hZ+w6IbByDyqSsDK5dA8O9ybDBeObzoqOe7hZiP4Q9BDZbmYz9q3+ VPMeU9NeUozrVbPkNBFjuJbd9tD+NABop9QZzJhJJgdoCoLrZDtuzaCNBl86cazW 64gWJmmnrLWKh5ZnYKwSHbAET+2Ua5jyF2E7PEnB/vn2urvyaCSmprU33O20yzma y6yyvwj89YVk+pEs2oaRUL3ePon8CCQ75vFW1musz6ga/hdAk+O5JXPugIPK6eQT vLmOPgoskU/rKmzGaztlQtMkRiCRSDta3xy6+/8QKL2vFh+Knyj6uSws7UJjUeIl eqEts3jzETHnObmQbNGhuwH9iNE9RcxpMki/sS2ziAS5TixQZoY2S6rYbwlA9659 X+bYvRkceImy4XS9MOyaFyfMAnYrIraxXcg6t1u/uXKDDsEKAgGxuVZ/G4Cb8XND BjfMVk7KiAfhwLRm4PPH =EEh9 -END PGP SIGNATURE-
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: On 04/12/2012 08:01, Rick Zero_Chaos Farina wrote: I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. because, you know, that's the only way a proxy maintainer can close/change a bug at all. That is a very good point. But being that it's a very good point it obviously never occurred to me that it shouldn't be spelled out in the metadata. Is there a policy for this as well that I am unaware of? A quick site:devmanual.gentoo.org proxy search indicates no documentation of this at all. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvjK5AAoJEKXdFCfdEflKQIUQALGbqDUONaKpQk4xLYDXDTQE gC7x7MMEyyBveZ3F2aZc/9IvWAzGYU0rQg7qOeEY8v6CLEDsNvi1mOQinhTNaJiv wnnk6NbnFrDEtBx5/J/3HDoR1PMFaCsAXM6Gd4vfMbtLYH3093COS5IyvBNP4oFB 3FQ+/kBZo9xN3TCpqxBCIjSZoR8aqxd4U6Px4o8KEKrDAkR9czyPRnqRAYb85ch1 qW37YOB2/MrYt1qDNo7m9NIQwmHVnThjkTqR/dzwxAEN7OEpo3MOXi0BX9CKb/kg 1Gp0XDE8iKzb3grnECZ+og4oyBWwZ9ydtGHOW7Vqa85CB2Zk2CkDPAq7RctYlS0t ItzBhSCDzuRjm3Y5J5jBrz0WaIMKfMQHqJR5ETXDnZmQIN39EqKb+oZYe1ei5hIJ LmX3zvjF9DVquC/JUQ2yeS/0m2YmF7G56dlE8OII7PlechpYb6pCyPoGttPcuI51 vUy+es8Ib8a2wqFHgpbmcbT37fJ/UVI0FgEuR6YV3ZH+uRwHcpLC8T7cIaTtI59Q mwIbFOu1+7JlNzJ3kEwZvY1ySuji8t8HbnBAWg6ehhaySbzijywlQtJCkyoUC+1I AMYkR085XWtomDss113E/c/cJqdn4UzzYR3C6gSyVf1iDqd4XgaG3AR2BGzKAiGr /J5yITUtwA99CNEpz6d8 =IukP -END PGP SIGNATURE-
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 12:32 PM, hasufell wrote: On 12/04/2012 06:17 PM, Rick Zero_Chaos Farina wrote: I'm sorry but isn't specific policy related to global policy? Why yes, yes it is. Unless they conflict, then no. On 12/04/2012 09:10 AM, Rick Zero_Chaos Farina wrote: If we are going to document this policy and make it official (which since it's not documented it's not official) then it only makes sense to have an opt-out option. I personally don't wish to see my users suffer for 2-4 weeks because I'm busy and people are pretending to be polite. I have no issue with this policy, but to do it without an explicit option to opt-out is not acceptable to me. This certainly depends on the severity of the bug. If you think my text can be improved please provide a new patch or tell me what exactly you would describe differently. A patch against what? I've not seen a link, only vague references to the dev manual. You missed to look at the initial post which refers to https://bugs.gentoo.org/show_bug.cgi?id=445402 which includes a patch for the devmanual. You are correct. I'm going to skip the back and forth on the mailing list about why, and simply propose my changes on the bug. This mail is intended only as a pointer to that fact. Thanks, Zero The vague character of this policy is a bit on purpose, otherwise you would have to describe every possible case. That's not what I want here. If we are vaguely defining a policy of not touching other peoples packages then the only specific thing in that policy should be what is exempt (which would be if xyz is in the metadata.xml then follow those instructions over this policy). This is VERY much on topic. I am really unhappy that people are writing policy that will get me less help and more work, and I won't be happy until I have a way to tell others that in the metadata.xml and the policy you are writing refers to it. The global policy is a general policy and does not overrule any developer saying touch my packages at will. That would not make sense. There are already numerous ways to do that, in the ebuild and in the description field in metadata.xml. If you want more ways to communicate that to other devs, then propose something, open a bug, open a new thread. So what in this policy do you disagree with? This is _not_ just about your own packages, this is a tree-wide policy which is more or less already in action. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQIcBAEBAgAGBQJQvjbYAAoJEKXdFCfdEflK3kwP+gOpmiyJ0sbb+UNLRSgClsLb nDC+6AmAY4ZFk0KTfjY/s8CYJ+fBWzHD1hKiT0akrb1oowMH3qcDlw7EibWUeQeE uQ+SDrBjzEJNCtfKaRH69h/Lp0OiSKC1KENRfI1sJqY9URPgL5arYsXXSZjLraGR /LsgnwPQd4z1TewkPA5FEUah2nAXj/BGI8t2c+h0iq8eD5bCv88hjwivdiP2xKLf DNe7fj6KItH91Di43n+hr1B6EP50GpOwW+FBSkpbAfrgcoWuBy0hoSEoKQNgsDy3 JMpT2DHlxaTj2t3ogIA886249hCfiSjteoUaJ3GivMX+FXMSjVNIkNckrkZ+/u75 D0XecB8wJdhiMheyQ2rELsA0dPPcHjJCeIBa7Mmv5h++vEjFkGe8D8AlozK6AodI y1ZsLVLdCKpVvikLkDIN17KxqyIZGSDbrkminqgZVdngbd5HHIhOfMvlsnPw9tzP bv4RFbbiDPl9Q/WomvjO4ayKgg+WHToHi0TwkMFK79TQYAkOcH39THjwcEzY1q0L 4TGPhjP3X5Nkp9CSA20Z3sD2Y9maG44wZyosa/PXUJg3xNQrZQ8xkMner5tcp+0R ozuS/ampoGDdxsR3o+8aIeQ6dDOtDX+j2T4teoMYz7u5dw8cJ7ui09QN0tsIm5Wg 1X5iMIMC0rly2VC3KOQC =qxgs -END PGP SIGNATURE-
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
the patch has been modified to reflect Zero_Chaos suggestions: - tell where to look for herd or maintainer notes (such as touch at will): metadata.xml - explicitly say to contact other devs if unsure how to handle a situation, especially if it's a critical one commit e6ebf193852f92aa1dfec162f1bcdc34e933eda1 Author: hasufell julian.osp...@googlemail.com Date: Sat Dec 1 00:04:51 2012 +0100 add ebuild comitting guide section diff --git a/ebuild-committing-guide/cvs-tutorial/text.xml b/ebuild-committing-guide/cvs-tutorial/text.xml new file mode 100644 index 000..a2bd612 --- /dev/null +++ b/ebuild-committing-guide/cvs-tutorial/text.xml @@ -0,0 +1,14 @@ +?xml version=1.0? +guide self=ebuild-committing-guide/cvs-tutorial/ +chapter +titleCVS Tutorial/title + +body +p +TODO: write something here. +/p +/body + +/chapter + +/guide diff --git a/ebuild-committing-guide/ebuild-policy/text.xml b/ebuild-committing-guide/ebuild-policy/text.xml new file mode 100644 index 000..44ce9aa --- /dev/null +++ b/ebuild-committing-guide/ebuild-policy/text.xml @@ -0,0 +1,14 @@ +?xml version=1.0? +guide self=ebuild-committing-guide/ebuild-policy/ +chapter +titleEbuild policy/title + +body +p +TODO: write something here. +/p +/body + +/chapter + +/guide diff --git a/ebuild-committing-guide/text.xml b/ebuild-committing-guide/text.xml new file mode 100644 index 000..db8e982 --- /dev/null +++ b/ebuild-committing-guide/text.xml @@ -0,0 +1,23 @@ +?xml version=1.0? +guide self=ebuild-committing-guide/ +chapter +titleEbuild Committing Guide/title + +body +p +This section describes how to commit an ebuild. It covers the basics of handling CVS commits and desribes some ebuild and tree policies. +/p +/body + +section +titleContents/title +body +contentsTree maxdepth=1/ +/body +/section +/chapter + +include href=ebuild-policy// +include href=tree-policy// +include href=cvs-tutorial// +/guide diff --git a/ebuild-committing-guide/tree-policy/text.xml b/ebuild-committing-guide/tree-policy/text.xml new file mode 100644 index 000..1c56a00 --- /dev/null +++ b/ebuild-committing-guide/tree-policy/text.xml @@ -0,0 +1,23 @@ +?xml version=1.0? +guide self=ebuild-committing-guide/tree-policy/ +chapter +titleTree and Etiquette policy/title + +body +p +This section outlines the etiquette policy for Gentoo developers and describes common sense when dealing with problems in the tree. +/p +section +titleChanging/Fixing other developers ebuilds/title +body +pUsually you don't just change other developers ebuilds without a word unless you know he does not mind or if you are part of the herd involved in maintenance (those information can be found in metadata.xml). Start with filing a bug or try to catch them on IRC or via email. Sometimes you cannot reach them or there is no response to your bug. It's a good idea to consult other developers on how to handle the situation, especially if it's a critical one and needs to be handled ASAP. Otherwise a soft limit of 2 to 4 weeks depending on the severity of the bug is an acceptable timeframe before you go ahead and fix it yourself./p +important Common sense dictates to us that toolchain/base-system/core packages and eclasses or anything else which is delicate (e.g. glibc) or widely used (e.g. gtk+) should usually be left to those maintainers. If in doubt, don't touch it./important +/body +/section + + +/body + +/chapter + +/guide diff --git a/text.xml b/text.xml index 88016b0..137a99f 100644 --- a/text.xml +++ b/text.xml @@ -50,6 +50,7 @@ section lists specific contributions to this manual. include href=quickstart// include href=general-concepts// include href=ebuild-writing// +include href=ebuild-committing-guide// include href=eclass-writing// include href=profiles// include href=keywording//
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 04/12/2012 10:35, Sergey Popov wrote: Agreed. I add description field to metadata for proxying packages, cause i see such field in other packages' metadata. That is it. But it would be better when this became official policy. At least - define actual maintainer first, even if he is not developer - this would never confuse scripts for automated bug filing Yes if you notice I usually go around changing the order if I find the order not matching the instruction, as the output of Portage, and thus my script, use the first as assignee and the rest as CC. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)
On 4 December 2012 17:28, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/04/2012 12:06 PM, Diego Elio Pettenò wrote: On 04/12/2012 08:01, Rick Zero_Chaos Farina wrote: I feel the description field is already overloaded when there is a proxy situation, maybe it would be best to define a field for this. Also english isn't primary language for everyone in the world so if the policy could actually be specific on this it would benefit everyone. Or maybe we can just agree that common sense rules all, and we always set the proxied maintainer as assignee, and the proxy maintainer as CC.. because, you know, that's the only way a proxy maintainer can close/change a bug at all. That is a very good point. But being that it's a very good point it obviously never occurred to me that it shouldn't be spelled out in the metadata. Is there a policy for this as well that I am unaware of? A quick site:devmanual.gentoo.org proxy search indicates no documentation of this at all. http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml?style=printable This page exists, but doesn't really mention anything about proper bug assignment. I know a lot of you have been doing this a very long time and there is a 'standard' way of doing things, but for us new guys if there is no documentation there is no policy. Bug-wranglers are supposed to do that by default. When you see a non-gentoo developer in metadata.xml, the default action is to assume his is the real maintainer and the bugs should be assigned to him. Such guidance should be documented in the bug-wranglers project page and not on the proxy-maintainers one. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 4 December 2012 15:42, Alec Warner anta...@gentoo.org wrote: On Tue, Dec 4, 2012 at 1:19 AM, Markos Chandras hwoar...@gentoo.org wrote: On 4 December 2012 01:18, Ben de Groot yng...@gentoo.org wrote: On 3 December 2012 03:30, Markos Chandras hwoar...@gentoo.org wrote: On Dec 2, 2012 6:09 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich Maybe adding some bits here[1] is preferred instead of the devmanual. Unless we agree to make devmanual a technical and non-technical document, which I personally don't like because it will end up being huge without some sort of indexing/search textbox for quick queries. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2 In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin As I said, the only drawback is that devmanual will become huge and without a proper search functionality, it will be a real pain to search for something quickly. Especially for new developers who are not familiar with how devmanual is structured. site:devmanual.gentoo.org term Works in bing, I tried it! It likely works in any modern search engine. I don't quite like depending on external resources to index our documentation. But I guess there is no alternative at the moment -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On 3 December 2012 03:30, Markos Chandras hwoar...@gentoo.org wrote: On Dec 2, 2012 6:09 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich Maybe adding some bits here[1] is preferred instead of the devmanual. Unless we agree to make devmanual a technical and non-technical document, which I personally don't like because it will end up being huge without some sort of indexing/search textbox for quick queries. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2 In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
In my opinion we should limit the amount of places where we document policies and best practices. I suggest we keep only devmanual and PMS as authoritative documents. In that case we should go forward and add these kind of policies to the devmanual. +1 from me
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich
Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds
On Dec 2, 2012 6:09 PM, Rich Freeman ri...@gentoo.org wrote: On Sun, Dec 2, 2012 at 10:21 AM, hasufell hasuf...@gentoo.org wrote: Only question is now what is a sane soft limit, before you go on and fix stuff. From a discussion in #gentoo-dev we thought 2-4 weeks depending on the severity of the bug is fine. Ofc this should exclude major changes or delicate packages from base-system/core/toolchain. Seems reasonable - I'd say 2 weeks is plenty. Of course, if the maintainer explicitly rejects the change in a posting on the bug, then it is hands off without some kind of escalation. Non-maintainers who are concerned about a package can always step up to maintain, as long as it involves real commitment. Oh, and on a side note Markos raises a valid point on the bug about whether the devmanual is a good place for policy. The problem is that I'm not sure we really have a good place, especially with the ebuild docs gone in favor of the devmanual now. Rich Maybe adding some bits here[1] is preferred instead of the devmanual. Unless we agree to make devmanual a technical and non-technical document, which I personally don't like because it will end up being huge without some sort of indexing/search textbox for quick queries. [1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2chap=2
