continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Venisse <>
Subject Re: separating the builder code from the UI
Date Thu, 02 Jul 2009 11:29:25 GMT
I'm fine with your approach but I don't think the final code will be similar
to the actual so I thought to write it from scratch.
If we use your approach, it would be good to decide all modules and
architecture components before to start so we'll can create an issue for
each and follow easily the progress.

On Thu, Jul 2, 2009 at 8:44 AM, Brett Porter <> wrote:

> Do you mean start from scratch, or write one component and integrate it,
> then write the next one, etc.? (That's more the approach I was trying with
> continuum-scm since I got faster feedback, but I haven't been back to it in
> a year)
> On 02/07/2009, at 1:55 AM, Emmanuel Venisse wrote:
>  After a big review of the code, I think it would be better to do it in a
>> branch and rewrite each part one by one to clean correctly all the code.
>> Emmanuel
>> On Thu, Jun 25, 2009 at 5:34 PM, Wendy Smoak <> wrote:
>>  I'm not likely to be the one doing most of the work, and it doesn't
>>> really look like we'll have competing branches that we'll have to
>>> decide between, so it's fine with me. :)
>>> Re: the problem of merging to trunk... I don't see that happening.  If
>>> a branch shapes up to be Continuum 2.0, I'd expect that we just _move_
>>> it to trunk.
>>> But again if those that are doing the work want to do it on "trunk"
>>> rather than "continuum-NEXT", go for it!  They're all just directories
>>> in Subversion that can be moved around at any time we decide to.
>>> --
>>> Wendy
>>> On Thu, Jun 25, 2009 at 8:20 AM, Emmanuel
>>> Venisse<> wrote:
>>>> I'd prefer to decide what will be Continuum 2.0. I won't like to start
>>>> to
>>>> work on a new architecture if we aren't sure because we'll spend lot of
>>> time
>>>> to write a POC, so personnaly, I'd prefer to start directly in trunk.
>>> ...

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message