[Yanel-dev] Code review with Yanel

[Michael Wechner]

Guillaume Déflache schrieb:
> Michael Wechner schrieb:
>> Dear All
>
> Hi!
>
>
>> I would like to  introduce tomorrow a staging branch at
>>
>> https://svn.wyona.com/repos/public/yanel/branches/staging
>>
>> whereas we *all* commit into this branch instead into the trunk, 
>> which is the first rule.
>>
>> (whereas it comes to my mind that we need to update 
>> http://yanel.wyona.org/en/development/processes/rtc.html ...)
>>
>> The second rule is that with "each" commit we add a "review file".
>>
>> The review file should be an XML and should describe which files 
>> belong together and which version (in case it wasn't committed 
>> atomically).
>
> Why shouldn't it be commited atomically? (Not doing it would make 
> reviewing the changes harder anyway.)

for example when changing package name of a Java class. If I moved the 
file and changed it at the same time, then SVN complained about it, my 
maybe you have a solution to this

> Where would we store these XML files? We would need to number them, 
> delete the old ones, and similar bookkeeping, which is a lot of overhead!

agreed, but as discussed this morning if we use SVN hook for the moment 
then it won't be any overheard except programming the hook
> I think patches in Bugzilla is less of a burden.

because you don't use it ;-)

Seriously I have received a lot of complaints that developers do not 
like this approach at all (me neither ;-) and hence
we need to find a better way, and I think the above is better :-)
>
>
>> The third rule is that we need to somehow enforce the review such 
>> that the review stack never becomes too large
>> (for example every morning all reviews need to be examined before any 
>> further commits)
>>
>> And so on  and on ...
>
> Here we are: this is all about new rules you want to set, why should 
> these require new tools?

I would call them follow-up-rules, because the main rule is RTC (review 
then commit), but in order to enforce this rule we must make it as 
simple to follow this rule as possible
>
>
>> I am sure there will be more trouble ahead (for example the rejection 
>> of a commit), but we need to get started somewhere.
>
> IMHO communicating the principles is a much better solution.
it's very important too (and the reasons behind them), but from my 
experience it's unfortunately not enough (not for everyone ...)
> And yes I know I have a bug assigned about writing them, but anybody 
> can help!

I will sit soon next to you ;-)
>
>
>> Any objections?
>
> Well, see above and the "tomorrow-short" delay seems to call for 
> overreaction! :(

I understand, but I want us to take action instead just keep talking 
about it and the above suggestion seems to me a feasible try.
If it shouldn't work out as expected, then we can easily switch back to 
the status quo, but at least we gained some experience.

Cheers

Michi