[opensource-dev] Wiki posting: Open Source Repository Strategy

[Philippe (Merov) Bossut]

Hi,

Thanks Robin for the summary of the Hippo discussion. It's consistent with
Q's schema and the point of the discussion was to avoid Merov becoming the
bottleneck for merges in Snowglobe trunk...

Another thing we said this week was that the export (from viewer-public to
viewer-external, process B in Q's schema) will be frequent (ideally for each
commit in viewer-public, practically for each successful build of
viewer-public which should happen several times a day), completely automatic
(viewer-external is a "read-only" repo, i.e. no one but the automatic export
process commit to that branch) and will keep history (i.e. the various hg
commit messages are collated and used as commit message during the export).

Cheers,
- Merov

On Mon, Mar 22, 2010 at 7:43 AM, Robin Cornelius
<robin.cornelius at gmail.com>wrote:

> On Mon, Mar 22, 2010 at 1:59 PM, Kent Quirk (Q Linden) <q at lindenlab.com>
> wrote:
>
> > The merge to Snowglobe isn't automatic -- it probably requires
> intelligent
> > merging. So if that includes leaving things out, so be it. The right way
> to
> > do it will probably be to undo the changesets so that it doesn't become a
> > fork that requires constant maintenance.
>
> Merov specificaly talked about this point at last Thursdays snowglobe
> meeting. Although we were running short of time and there may be need
> for some fine details. The consensus of those present was to manually
> merge from vendor branch about once a week. A manual merge is probably
> vital here as snowglobe will be adding its own features and fixes and
> any of these could be damaged by incomming code based of a slightly
> different code base. Hopefully a great deal of snowglobe patches will
> make there way back to the main viewer code anyway and this type of
> conflict will not happen too often. The other thing Merov said is if a
> vendor imported patch breaks/conflicts with snowglobe then just revert
> that patch and flag up the situation. The final idea was the help of a
> "merge monkey" someone who could assist with the merging from vendor
> to snowglobe so that its not always merov, this could be multiple
> people taking it in turns etc, this was all up in the air and just
> ideas banded around at the meeting.
>
> Robin
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20100325/6fb297c5/attachment.htm