continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Wed, 06 Feb 2008 10:30:17 GMT
We can create such a wiki any time - the challenge is converting  
existing content. If someone is happy to lose history and do it by  
hand, it can be done straight away.

On 06/02/2008, at 9:25 PM, Rahul Thakur wrote:

> Some good points emerging from this discussion! :-)
>
> Would it be a nice idea to put following on wiki:
> 1)  State goals/philosophy for C2 in light of lessons learnt from  
> 1.x development - lean, mean, extensible (~add any other here~)
> 2)  Document *all* features/requirements we want to see in C2 on  
> wiki (even if they are already present in 1.x!).
> 3)  Draw a proposed architecture.
> 4)  Assign items in (1) a priority/weight. Add use-cases to each  
> item in (1) to determine this.
> 5)  Group the priortised requirements/features into milestones.
> 6)  Start cutting code.
>
> Thoughts?
>
> PS: Codehaus wiki seems to be very slow. Any chance we can have a  
> space created on Apache wiki? Or, I guess it will have to wait for  
> TLP vote.
>
> Cheers,
> Rahul
>
> Brett Porter wrote:
>> This looks very exciting, and agree with most of the thread that  
>> follows. I'm just going to reply in summary - most of my thoughts  
>> are actually non-technical :)
>>
>> Regarding databases: I don't think xml files are the solution  
>> (except for the configuration where it makes a lot more sense :) -  
>> the data needs to be queryable. I think Andy made a good point in  
>> his comment on the roadmap - we need to look at the actual  
>> problems. Here's what I think needs to be improved:
>> - better centralisation of access. The architecture of Continuum  
>> bleeds JDO decisions all through the code since you access lazy  
>> stuff for the first time in obscure places.
>> - I think this might be that the model is too complicated (sorry,  
>> my fault) - it assumes complex relationships are handled easily. It  
>> seems to be going ok these days, but I feel it would be hard to  
>> modify.
>> I haven't looked at Rahul's branch yet, but I think we should  
>> consider a more decoupled database (ie, lookup build results for a  
>> project but keep them separate in the model to avoid the need to  
>> lazyload 90% of the time), and more centralised database logic. I  
>> would consider JPA just because it gives more options in terms of  
>> an implementation. It is quite easy to use from a development  
>> standpoint. But we also need to consider what functionality is  
>> needed up front - I think high on the list needs to be migrations  
>> between versions. Also, We are probably going to need to store more  
>> data in the future, and be able to query it (particularly  
>> historical datapoints).
>>
>> On the container: I would prefer to move off Plexus simply because  
>> it's a moving target and it's a barrier to entry for new developers.
>>
>> Now, my more general observations. Firstly, the roadmap doesn't  
>> appear to have any features - these are all technology changes.  
>> Some of that might be cool and a feature in itself, but I think  
>> there needs to be a balance between evolution, features, and  
>> bugfixing. I would also emphasise that features should be creative  
>> new things Continuum can do (for which we've had plenty of ideas),  
>> not just catching up to other CI servers :)
>>
>> I think the first part of the roadmap is key - separating the  
>> layers out, and basically building Continuum to be lightweight and  
>> distributed from the ground up. I hope that's the focus of the  
>> development. Note this also impacts the database as it should store  
>> much less information on builder machines (it can ship history back  
>> to the main server).
>>
>> I also think that supporting plugins is a good idea - it has been a  
>> huge bonus in other apps and in Maven itself. I'd like to  
>> investigate using OSGi for this.
>>
>> But by far the biggest question I have is what happened to 1.2? I  
>> think Continuum needs to set a target to achieve, but get there in  
>> gradual steps that at each stage sees a production release. The  
>> long 1.1 cycle really set Continuum back - a lot of it was changing  
>> features, but there was also a lot of changing technologies :) I  
>> don't think Continuum will survive another year-and-a-half release  
>> cycle. So the start could be to break all the actions out (plexus,  
>> not webwork) into services and add some features, then the next  
>> release could adjust the database model and add some other  
>> features. And as we split these things out we make sure they are  
>> nicely documented and tested.
>>
>> That's my thoughts :)
>>
>> Cheers,
>> Brett
>>
>> On 30/01/2008, at 9:34 AM, Emmanuel Venisse wrote:
>>
>>> Hi
>>>
>>> I started a document [1] with my ideas about Continuum 2.
>>> As you can see in this doc, I want to add lot of things in the  
>>> next version.
>>>
>>> Feel free to comment on it.
>>>
>>>
>>> [1]
>>> http://docs.codehaus.org/display/CONTINUUM/Continuum+2.0+Design+Discussion
>>>
>>> Emmanuel
>>
>>


Mime
View raw message