Re: [phpGroupWare-developers] Commit in official trunk ...

[Caeies]

Hi all,

Maât a écrit :
> Caeies wrote:
>> Hi all,
>>
>> I'm happy to see new logs in the svn. But I have to urge all devs to be
>> *very* carefull when commiting in the repository.
>> As maat suggest having an easy understable log is important. I will not
>> focus in this email on this, but I think that the way he proposed to
>> "tag" logs is a good idea.
>> The real focus in this message is this :
>> Each commit *in trunk* should be "atomic". I mean, that if somebody do a
>>  checkout, trunk should be "usable" after each commit. You are free to
>> do whatever you want in your own branch (but I would recommand to stick
>> to this policy), but not in trunk. Reasons are :
>>  - easily review patches
>>  - easily merge
>>  - no missing files for people
>>  - ...
>>   
> I'll add also :
> 
> - stable
> - tested
> - reviewed by peers if the change lets some questions unanswered
> 
> Let's take an example with the following :
> 
> Log Message:
> -----------
> Bug fix : try to fix the get_member stuff, not sure if this is the right way 
> to do it, but it works
> 
> 
> Commits with some uncertainty and "i'm not sure" comments like this one
> should not imho be  committed straight in reference repositories but
> rather in personal repositories and should trigger a call for review :)
If trunk was bug free, I will be ok with this way of working.
Unfortunately, trunk is far away such a base, fixing it like this will
be easier. Note that I speak about _fixes_ and not "new features" ...
and IMHO this is a real difference.

> 
> Then, once the patch is tested/reviewed/improved, you can merge the
> (perhaps improved) changes in one single commit with a
> professionnal-looking comment like for example :
> 
> Bug fix : replaced the inexistant variable $this->account_id by the
> existing $account_id

Well If this is what you understand of the patch ... damn, review can
take long time :).

It's not because I take care of doubt in my commit that I'm not sure of
what I do ...


> 
> As we are starting from a low level of quality as far as sources and
> changes control management is concerned we can close eyes a moment and
> go on fixing things without too high expectations on process quality but
> keep in mind that we'll need to improve this sooner or later (dunno if i
> can use this for the french expression "tôt ou tard") if we want to use
> svn logs to generate good looking Changelogs :)
IMHO this should be done when merging new features... from personnal
branches.

Btw, before doing a commit I'm near always doing a svn annotate and take
a look at the people who commited in and the associated log ...

Regards,

Caeies