Re: openmoko-merges

[Koen Kooi <k.kooi@student.utwente.nl>]

On 18-12-08 11:11, John Lee wrote:
> On Thu, Dec 18, 2008 at 10:02:53AM +0100, Koen Kooi wrote:
>> On 18-12-08 08:19, John Lee wrote:

 > As mentioned before, what's in /etc/init.d/ , rcS and different
 > runlevels varies from distro to distro, machine to machine...  Would
 > it be better if I remove as many overrides as possible, we merge it to
 > oe.dev and fix problems there?  I don't think I can test all these
 > combinations alone.

My proposal would be:

* move it to seperate branch
* remove nearly all overrides (putting them back is easier than removing 
them a few months later when everybody has forgotten why it was there)
* review it

When the review comes out ok send a mail stating "this branch will get 
merged in 2 weeks unless serious bugs emerge, please test". I don't 
think anyone can rightfully complain after that :)


>> I suspect review and merging would be easier if you 'collapse' the
>> patches per recipe or per directory. Reviewing all the seperate commits
>> will take too much time :(
>
> Maybe it will be easier if people just review it by rebase first then
> diff the content instead of read though commits, so one can clearly
> see what will be changed, while still keeping the development process
> recorded in the commit messages.

It's too big to get reviewed, plain and simple. For OE we agreed (see 
the RFC sent yesterday) that changes should be in small topic branches. 
If you put the changes in topic branches (e.g. fast-boot, bug-fixes, 
openmoko-misc) we could keep the precioussssssss development process if 
the branches are small. Small branches is the key thing.

Oh, and with 'review' I mean a real review *process* where change are 
made to the proposed patches and if needed get a few iterations of the 
commit-fix-comment-fix cycle.

regards,

Koen