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