continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Edward Gruber <cgru...@israfil.net>
Subject Re: [Discussion] Continuum 2.0 Roadmap
Date Fri, 08 Feb 2008 03:50:41 GMT
1.  +1 on distributed builds, along with examples on the 2 main use  
cases I see for distributed builds:
      a. building on many platforms for native builds that need  
multiple distributions.
      b. distribute the build across many machines to decrease the  
latency of building everything.

2. +1 on the docs comment below.

3. As to slicker UI, I'm not sure it's as necessary, and there's  
nothing stopping 1.x from getting a better UI.  The bigger issues for  
me are:
	a) better co-ordination of reports/dashboards
	b) integrations with various other systems and dashboards and  
monitors (mylyn, jira, etc.)

4. Full configuration of the bootstrapping/staging of the build  
environment.  I'm still experimenting with the current mechanisms, but  
I think it still needs work.

5. Apart from distributed builds, I think we need parallel building of  
mutually independent projects.

I care less about the underlying technologies because most people  
won't be adding osgi or plexus or picocontainer components willy- 
nilly.  I would replace plexus if it is deficient, but unless there's  
a compelling reason to switch, I wouldn't work at it too hard.  For  
example, if it was based on Tapestry (not a plug, just an example),  
then moving to tapestry-ioc would make sense because t5 comes with it,  
it's based on that model, and it cleanly integrates with spring for  
extension.  In that case, however, it's a change for convenience.  I'd  
be even happier if such a switch of any given subsystem was because of  
a solid decision of either defect in the current approach, or  
improvement in the new one.  Spring makes me a bit woodgy because  
while it's an IoC container, it's not really (in my experience) a  
great plug-in system.  An infrastructure around a plugin lifecycle  
would need to be built on or (3rd party) added to spring to make it  
really useable that way.

Christian.

On 7-Feb-08, at 21:56 , Rahul Thakur wrote:

>
> Here's my list:
>
> 1)  Peformance improvements.
> 2)  A slicker User Interface. Ability to let the user work in an  
> offline mode (Google Gears!) and sync periodically.
> 3)  Good user and developer documentation.
> 4)  Better public APIs (rework Store and Continuum)
>
> Rahul
>
> Napoleon Esmundo C. Ramirez wrote:
>> Just some thoughts,
>>
>> I strongly agree to the proposed technology changes, particularly  
>> in the
>> database, as it will definitely improve the storage performance.   
>> In line
>> with the objectives to make Continuum a slick CI server, I think  
>> the design
>> changes is a good move as well.  In my opinion, having plugins will  
>> provide
>> a platform for flexibility and a workflow-type of approach in  
>> managing the
>> builds.
>>
>> My proposed features would be the following:
>> 1.  Aside from the improvement in the UI, I think a visual  
>> representation of
>> statistics would be nice.  Graphs of the success rates, charts of  
>> project
>> health, etc.  I think Bamboo has it as telemetry.
>> 2.  Distributed builds, this has been started before but it was  
>> never used.
>> I think this would be a strong point in using Continuum if it were
>> available.  Hudson has it, iirc.  I think implementing it as a  
>> plugin would
>> provide more control to it.
>>
>> Again, just my thoughts.
>>
>> Cheers!
>> Nap
>>
>> On Feb 6, 2008 8:12 AM, Carlos Sanchez<carlos@apache.org>  wrote:
>>
>>
>>> Some comments
>>>
>>> Database vs xml: definitely database. Throwing away the db access  
>>> api
>>> (JDO/JPA/...) now that it's already there doesnt make much sense.
>>> Maybe there are implementations that use xml for storage and that's
>>> where you'd need to look if you want file storage
>>>
>>> Spring vs Guice vs Plexus: Spring for sure. Big community, lots of
>>> users, documentation, support,... Specially if you want to add JMX
>>> support (can be done really easily just with annotations using
>>> reflection), and thinking in OSGi in the future I'm sure it will be
>>> really easy to integrate Spring and OSGi if it is not already. I'd
>>> start softly, just migrating thing that would require adding  
>>> features
>>> to plexus, and move from there.
>>>
>>> I agree with Brett on having 1.2, 1.3,... it's good to have a list  
>>> of
>>> what you want to do for 2.0 but as it gets done it should be  
>>> released
>>> in minor versions.
>>>
>>> On Jan 29, 2008 2:34 PM, Emmanuel Venisse<emmanuel@venisse.net>   
>>> 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
>>>>
>>>>
>>>
>>> --
>>> I could give you my word as a Spaniard.
>>> No good. I've known too many Spaniards.
>>>                             -- The Princess Bride
>>>
>>>
>>
>>
>


Mime
View raw message