[gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[hasufell]

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.

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Rich Freeman]

On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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

[Markos Chandras]

[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]

On Dec 2, 2012 6:09 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>
> On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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=2&chap=2

[-- Attachment #2: Type: text/html, Size: 1800 bytes --]

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On 3 December 2012 03:30, Markos Chandras <hwoarang@gentoo.org> wrote:

>
> On Dec 2, 2012 6:09 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
> >
> > On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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=2&chap=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

[-- Attachment #2: Type: text/html, Size: 2629 bytes --]

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Ian Whyman]

[-- Attachment #1: Type: text/plain, Size: 268 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 318 bytes --]

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Markos Chandras]

On 4 December 2012 01:18, Ben de Groot <yngwin@gentoo.org> wrote:
> On 3 December 2012 03:30, Markos Chandras <hwoarang@gentoo.org> wrote:
>>
>>
>> On Dec 2, 2012 6:09 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>> >
>> > On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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=2&chap=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

[Alec Warner]

On Tue, Dec 4, 2012 at 1:19 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
> On 4 December 2012 01:18, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 3 December 2012 03:30, Markos Chandras <hwoarang@gentoo.org> wrote:
>>>
>>>
>>> On Dec 2, 2012 6:09 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>>> >
>>> > On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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=2&chap=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

[Markos Chandras]

On 4 December 2012 15:42, Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Dec 4, 2012 at 1:19 AM, Markos Chandras <hwoarang@gentoo.org> wrote:
>> On 4 December 2012 01:18, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 3 December 2012 03:30, Markos Chandras <hwoarang@gentoo.org> wrote:
>>>>
>>>>
>>>> On Dec 2, 2012 6:09 PM, "Rich Freeman" <rich0@gentoo.org> wrote:
>>>> >
>>>> > On Sun, Dec 2, 2012 at 10:21 AM, hasufell <hasufell@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=2&chap=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

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 1179 bytes --]

On 4 December 2012 17:19, Markos Chandras <hwoarang@gentoo.org> wrote:

> On 4 December 2012 01:18, Ben de Groot <yngwin@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

[-- Attachment #2: Type: text/html, Size: 1777 bytes --]

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Rick "Zero_Chaos" Farina]

-----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 : <maintainer><name>help welcome></name></maintainer>
or a specific tag to put under our own maintainer section
<maintainer><name>Rick Farina</name><demeanor>just 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

[Markos Chandras]

On 4 December 2012 08:10, Rick "Zero_Chaos" Farina <zerochaos@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 : <maintainer><name>help welcome></name></maintainer>
> or a specific tag to put under our own maintainer section
> <maintainer><name>Rick Farina</name><demeanor>just 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>
<email>foo@gentoo.org</email>
<name>Me</name>
<description>Primary maintainer but feel free to fix the bugs<description>
</maintainer>

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Rick "Zero_Chaos" Farina]

-----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 <zerochaos@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 : <maintainer><name>help welcome></name></maintainer>
>> or a specific tag to put under our own maintainer section
>> <maintainer><name>Rick Farina</name><demeanor>just 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>
> <email>foo@gentoo.org</email>
> <name>Me</name>
> <description>Primary maintainer but feel free to fix the bugs<description>
> </maintainer>
> 
<maintainer>
<email>foo@gentoo.org</email>
<name>Me</name>
<description>Proxy maintainer, assign bugs to proxied maintainer, cc on
bugs, but feel free to just fix the bugs<description>
</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-----

Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 679 bytes --]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Rick "Zero_Chaos" Farina]

-----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: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Sergey Popov]

[-- Attachment #1: Type: text/plain, Size: 927 bytes --]

04.12.2012 21:28, Rick "Zero_Chaos" Farina wrote:
> 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.
> 

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

-- 
Best regards, Sergey Popov
Gentoo Linux Developer
Desktop-effects project lead


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 554 bytes --]

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Diego Elio Pettenò]

[-- Attachment #1: Type: text/plain, Size: 678 bytes --]

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
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Markos Chandras]

On 4 December 2012 17:28, Rick "Zero_Chaos" Farina <zerochaos@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: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Ben de Groot]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On 5 December 2012 02:51, Markos Chandras <hwoarang@gentoo.org> wrote:

> On 4 December 2012 17:28, Rick "Zero_Chaos" Farina <zerochaos@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

[-- Attachment #2: Type: text/html, Size: 1966 bytes --]

Re: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Markos Chandras]

On 6 December 2012 11:02, Ben de Groot <yngwin@gentoo.org> wrote:
>
>
>
> On 5 December 2012 02:51, Markos Chandras <hwoarang@gentoo.org> wrote:
>>
>> On 4 December 2012 17:28, Rick "Zero_Chaos" Farina <zerochaos@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)

[Peter Stuge]

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)

[Ian Stakenvicius]

-----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)

[Peter Stuge]

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)

[Markos Chandras]

On 6 December 2012 15:27, Peter Stuge <peter@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: Proxy maintainers in metadata.xml (was Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds)

[Jeroen Roovers]

On Tue, 4 Dec 2012 18:51:36 +0000
Markos Chandras <hwoarang@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 <description>Assign 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

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/04/2012 05:01 PM, Rick "Zero_Chaos" Farina wrote:
> 
> <maintainer> <email>foo@gentoo.org</email> <name>Me</name> 
> <description>Proxy maintainer, assign bugs to proxied maintainer,
> cc on bugs, but feel free to just fix the bugs<description> 
> </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-----

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Rick "Zero_Chaos" Farina]

-----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> <email>foo@gentoo.org</email> <name>Me</name> 
>> <description>Proxy maintainer, assign bugs to proxied maintainer,
>> cc on bugs, but feel free to just fix the bugs<description> 
>> </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: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[hasufell]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> 
>> 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 Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQvjOYAAoJEFpvPKfnPDWzoj0H/1g4iV63w0/slCoZgXVRumEf
bovcEEqctUvl7ayyNuPdu7mzcOeyWfLTG7/4Xqpntn/XzNvOtU9pTi5/GAoPYSqt
rbSH/RpREgS3pQNctDqcB4zi7DVdCY5ugQBs/M9m/CWKpUsWwSZpp7/bsa3f9t2U
DOdEQjP35EWr9XP3kbSY/J2U5lSYhX/1n8SNlKGMKnwVes4RlKxC2MVTMoodGjW3
12wfpQ1FjAgF5hkz1HfM0tgrDPp994Iiu9wdjp6FtqHZVSZye0MetNu2AvuTH8Ft
Cs2Isf9Y5dJ+p48BWEY9jWwQRD+/H7TgAj6G7NarYGJ4u4lLe4Sf9qBO/BFN3fA=
=IPl8
-----END PGP SIGNATURE-----

Re: [gentoo-dev] introduce a soft-limit policy for changing other developers ebuilds

[Rick "Zero_Chaos" Farina]

-----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

[hasufell]

[-- Attachment #1: Type: text/plain, Size: 264 bytes --]

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

[-- Attachment #2: ebuild-committing-guide.patch --]
[-- Type: text/x-patch, Size: 3700 bytes --]

commit e6ebf193852f92aa1dfec162f1bcdc34e933eda1
Author: hasufell <julian.ospald@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 0000000..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>
+<title>CVS 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 0000000..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>
+<title>Ebuild 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 0000000..db8e982
--- /dev/null
+++ b/ebuild-committing-guide/text.xml
@@ -0,0 +1,23 @@
+<?xml version="1.0"?>
+<guide self="ebuild-committing-guide/">
+<chapter>
+<title>Ebuild 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>
+<title>Contents</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 0000000..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>
+<title>Tree 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>
+<title>Changing/Fixing other developers ebuilds</title>
+<body>
+<p>Usually 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/"/>