phpgroupware-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Phpgroupware-developers] PHPDocs for head


From: Mailings - Christian Boettger
Subject: RE: [Phpgroupware-developers] PHPDocs for head
Date: Wed, 20 Apr 2005 09:20:08 +0200

 Hi,


[Dave]:
> Who did you ask about running php -l? Did someone ask you to run it?  I
don't think so.


Hey, get a clue .. ;-)

Running php -l on any code before checking in any code should be done
anyway. It's just a syntax check and I do think that we cannot tolerate any
syntactically broken code in CVS anyway. And I seem to remember that we have
agreed on this some time ago. 

So running php -l on the code should in theory not lead to any hit... But
obviuosly it does. I can't see any reason why such syntax errors should not
be fixed immediately (they should not have been there anyway). And I can't
see any violation of "this is MY code" in this case. It's a formal syntax
error being fixed, nothing else. Calm down everyone. Same holds e.g. for
typos ("fro" instead of "for" and such) and for XHTML compliance. These
things have to be fixed in any case; and they do not add or change features
nor do they infringe the personal achievements in writiung that code. 

And I don't think it's a good way to first try to find out who might be the
maintainer, send a mail, prepare a patch, wait for 3 months, prepare a new
patch etc etc before a simple syntax error finally might get fixed. This
procedure couldn't do any good for the quality of the project.

As quality coordinator of the project (sic!) I have to vote for immediate
fixes of php syntax errors, formal xhtml compliance errors and other purely
formal code errors as soon as they may be found; without going through a big
"ask me first" process. It would be a good idea to send a mail to the
maintainer announcing the fix incl. the diff. Any changes to the code *apart
from purely formal fixes*, i.e. anything that changes the functionality,
design, ... features of the code must of course be done only with explicit
permission of the maintainer or must be submitted via the patch tracker. 

And yes, there are projekcts in which these error corrections do NOT fork
off a big discussion about "someone has touched MY code!".  

Think about it: from the outside this does not look like a real team; but
like a bunch of people not trusting each other.

[Kai]:
> > My point is that your behaviour is like a pool of single 
> developers - 
> > where everyone will fight his area.

Yes, sometimes it looks like it. I'm not very hapy about it.

Kind regaqrds

bofh42 aka CB 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]