Re: Commit in official trunk ...

Hi all,

Ma=C3=A2t a =C3=A9crit :
> Caeies wrote:
>> Hi all,
>>
>> I'm happy to see new logs in the svn. But I have to urge all devs to b=
e
>> *very* carefull when commiting in the repository.
>> As maat suggest having an easy understable log is important. I will no=
t
>> 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 stic=
k
>> to this policy), but not in trunk. Reasons are :
>>  - easily review patches
>>  - easily merge
>>  - no missing files for people
>>  - ...
>>  =20
> I'll add also :
>=20
> - stable
> - tested
> - reviewed by peers if the change lets some questions unanswered
>=20
> Let's take an example with the following :
>=20
> Log Message:
> -----------
> Bug fix : try to fix the get_member stuff, not sure if this is the righ=
t way to do it, but it works
>=20
>=20
> 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.

>=20
> 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 :
>=20
> 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 ...


>=20
> 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 bu=
t
> keep in mind that we'll need to improve this sooner or later (dunno if =
i
> can use this for the french expression "t=C3=B4t ou tard") if we want t=
o 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