Blame assignment [was: mkfontscale strikes again]

2003-07-03 Thread Juliusz Chroboczek
EE> So far submitted code was thoroughly tested...

EE> I would like to get to a situation where the submitter himself 
EE> takes over more responsibilities and takes his code to a committable 
EE> state...

I think that both should be available -- (1) the case when I take full
responsibility for a patch and you trust me, and (2) the case when I
don't feel competent and want you to double-check what I'm doing.

We need some convention to distinguish between (1) and (2).  The lkml,
for example, use the phrase ``please apply'' to mark case (1).

Juliusz


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Blame assignment [was: mkfontscale strikes again]

2003-07-03 Thread Egbert Eich
Juliusz Chroboczek writes:
 > EE> So far submitted code was thoroughly tested...
 > 
 > EE> I would like to get to a situation where the submitter himself 
 > EE> takes over more responsibilities and takes his code to a committable 
 > EE> state...
 > 
 > I think that both should be available -- (1) the case when I take full
 > responsibility for a patch and you trust me, and (2) the case when I
 > don't feel competent and want you to double-check what I'm doing.

Definitely. In some cases the four eyes principle is the only
way. There are pieces of code where I have just as much expertise
about as you do. And I expect that even those who have been on
the project much longer than me have not looked into every tiny
corner.
 > 
 > We need some convention to distinguish between (1) and (2).  The lkml,
 > for example, use the phrase ``please apply'' to mark case (1).
 > 
Right!

Egbert.


___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel


Re: Blame assignment [was: mkfontscale strikes again]

2003-07-03 Thread Brad Hards
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Fri, 4 Jul 2003 06:22 am, Egbert Eich wrote:
>  > I think that both should be available -- (1) the case when I take full
>  > responsibility for a patch and you trust me, and (2) the case when I
>  > don't feel competent and want you to double-check what I'm doing.
>
> Definitely. In some cases the four eyes principle is the only
> way. There are pieces of code where I have just as much expertise
> about as you do. And I expect that even those who have been on
> the project much longer than me have not looked into every tiny
> corner.
>  >
>  > We need some convention to distinguish between (1) and (2).  The lkml,
>  > for example, use the phrase ``please apply'' to mark case (1).
>  >
> Right!
I've personally used "please review and apply if OK". Seems to work OK, 
although if this is going to a mailing list, sometimes you won't get it 
reviewed - it'll just get dropped. That usually means that no-one else 
thought it was OK (eg it was too hard, no-one else felt confident, poorly 
phrased request, just too busy) and you need to work it some more yourself.

For more invasive changes, using [RFC/RFD] and describing the changes (not 
just a posting of a diff) and the relative advantages/disadvantages is 
clearly a good idea.

How you work that into a formal mentoring arrangement probably depends on the 
individual developers involved. Probably a community based (eg mailing list) 
arrangement is better, especially in the (common) situation pointed out 
above, where a particular developer may be quite inexperienced in general, 
but have particular expertise in a certain area.

Brad

BTW: Thanks to all the XFree86 developers - great work.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/BJjXW6pHgIdAuOMRAoLJAKCWE3T0DXW6jqdf/okbLk5UR/gs6QCfTF9j
27aDHNYCoVJuWbxkhOGEeyQ=
=t/Av
-END PGP SIGNATURE-

___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel