Re: openmoko-merges

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

On 19-12-08 21:03, Tom Rini wrote:
> On Fri, Dec 19, 2008 at 04:46:03PM -0300, Ricardo Salveti de Araujo wrote:
>> On Fri, Dec 19, 2008 at 7:48 AM, Graeme Gregory<dp@xora.org.uk>  wrote:
>>> John Lee wrote:
>>>> I'll keep working on the fastboot branch (need the help of original
>>>> author on this one.  since this will become general changes, it's not
>>>> going to be easy), and reorganize the om-merge branch a bit.  Is this
>>>> the first time of such a big merge ?  I think Graeme and I both did
>>>> some merge back before, but this one seems to be bigger...
>>>>
>>> I used to use a process similar to what koen suggested where I would
>>> only merge back into OE the final changes to a .bb not all the
>>> mistakes/fuckups/typos that got us to that result. Then evaluate each
>>> change on its own to judge its level of controversy.
>> Yep, this is something I was thinking about this week, where I decided
>> to reorganize the Mamona patches to merge it back to OE.
>>
>> Merging related modifications in just one patch helps a lot to review
>> the code and also to merge it upstream, the bad part is that we lose
>> all the history behind those patches. Adding a message telling that
>> the patch came from Mamona helps this issue, as the user could see it
>> at the Mamona own repository, but still don't know what's the
>> preferred way.
>>
>> What are your suggestions? Should I create branches and rebase Mamona
>> repo to do the merge with all the history or just merging related
>> commits in one is enough (also with branches and review)?
>
> IMHO, a lot of history is worthless sometimes.  The important things to
> encapsulate from a big history are the tricky things that you should
> comment on, or elaborate on in the final commit message (We had to do
> ... because ...).  So long as the hard to get right / complex / etc bits
> are explained, you don't need 10 commits showing how it was almost
> right, you just need the correct solution explained.

Comments in the code (i.e. recipes, patches) itself would be even 
better, since we might even to monthly tarballs snapshots of the 
upcomining stablebrach where people would lack a bit of history.

regards,

Koen