[sldev] Re: Getting a community/sandbox area in the SL SVN repository?

[Dzonatas]

We pretty much agree there.

The detail to notes would be to take a "svn copy" of the stable or 
unstable branch first to a user directory to apply the patches and 
basically test that it compiles before being committed to unstable. What 
changes to the patch can be done in the user directory.

I say user directory, but it could be like a project directory for a 
range of patches, too.

Apropos to subjects raised at the Open Source meeting, I'm concerned 
with the history or any auditing not being effective enough under a 
structure too minimal, so I only suggested a structure and simple flow 
on par with such concern.

(scratch that Debian was ever mentioned -- it obviously confused the 
idea of the traditional structure)

Able Whitman wrote:
> I think your branching scheme makes sense, Dzonatas, but I'm curious 
> about what kinds of changes / checkins would be candidates to become 
> their own branches.
>
> The way I envision things, most JIRA patches would go straight into 
> unstable, without having to be placed in their own branch first. More 
> complex changes (like Dale's integration of an external rating system, 
> or my mute visibility stuff) might warrant their own branches, however.
>
> So I think as that for most patches, the process could work like this:
>
> 0. Patches attached to JIRA issue
> 1. Patches integrated into unstable from JIRA
> 2. Sanity tests done on unstable to shake out any glaring bugs
> 3. Changes in unstable integrated into testing
> 4. More extensive QA done on testing
> 5. Changes in testing which pass QA integrated into stable
>
> That way the majority of work happens in JIRA -> unstable -> testing 
> -> stable, and avoids the problem of having to wrangle many many 
> branches.
>
> On 7/20/07, *Dzonatas* <dzonatas at dzonux.net 
> <mailto:dzonatas at dzonux.net>> wrote:
>
>     Laurent Laborde wrote:
>     > On 7/20/07, Dzonatas <dzonatas at dzonux.net
>     <mailto:dzonatas at dzonux.net>> wrote:
>     >>
>     >>  Here is a suggestion for linden/sandbox:
>     >>
>     >>  linden/sandbox/stable
>     >>  linden/sandbox/testing
>     >>  linden/sandbox/branches/unstable
>     >>  linden/sandbox/branches/2007
>     >
>     > My idea of a sandbox is something simple, quick, efficient and
>     easy to
>     > use/manage.
>     > Some kind of "quick and (not-so)dirty".
>     >
>     > The "debian way" is a slow process,
>     Debian team didn't invent the process, but they did highly
>     innovate the
>     way updates are fed. The update process would be "The Debian
>     Way"... not
>     the structure. As far as Debian comes into role at this time, it is
>     easier to go reference Debian on its structure than to spend time to
>     write-up a 10 page essay on the scheme. =)
>
>     Let's not confuse this with Debian in that way.
>
>     Anything less of a structure than suggested I feel will quickly
>     run into
>     stepping on toes.
>
>     Please do post your example of a structure.
>
>     --
>     Power to Change the Void
>     _______________________________________________
>     Click here to unsubscribe or manage your list subscription:
>     /index.html
>
>

-- 
Power to Change the Void
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070720/f8906287/attachment-0001.htm