Re: Continuum 1.1 roadmap
I had a look at this, and added "high" next to the ones that I thought were high, and realised it was all but two. So I took the column out and moved those two to a 1.2 roadmap. Maybe we can break that down into 1.2, 2.0, etc. as we go and just keep this page as the "this is what we're doing and what we'd like to do in future at a high level" page. Do folks think this is helpful? That was basically the intent of the "design discussion page", so I'm going to make that basically a workspace for actual 1.1 design discussions, and then move the roadmappish bits to this. So, we now have: http://docs.codehaus.org/display/CONTINUUM/Continuum+Roadmap and http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Design+Discussions Cheers, Brett On 13/07/2006 8:22 AM, Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse -- Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
Re: Continuum 1.1 roadmap
it disappeared into the ether of the mailing list? :) I still think its a good idea, thanks for bringing it back up...could be very useful on some of the larger issues like security and project groups, etc.. jesse On 7/12/06, Rinku <[EMAIL PROTECTED]> wrote: Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: > hi everyone, > > I have been trying to help emmanuel some with pulling together the > roadmap for Continuum 1.1 on the wiki and maybe help organize some of > the discussions on there. > > I wanted to get out the url to the wiki roadmap and maybe see how you > guys feel about the content on it. I tried to pull out some of the > important things from the 170 + issues in jira currently slated for > 1.1 and also the roadmap thread that started on this mailing list last > month. > > so..any thoughts and improvements would be much appreciated, I was > kinda hoping I could get a somewhat definitive list of the major > hotbutton items for Continuum 1.1 on that roadmap page and then link > out the appropriate wiki page or jira ticket. > > http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap > > > I also reworked the front page a bit...it was sort plain...or empty > rather. > > http://docs.codehaus.org/display/CONTINUUM/Home > > jesse > -- jesse mcconnell [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
Hi, Just wondering what happened to this idea: http://www.nabble.com/2.1-Design-and-Process-tf1617559.html#a4383722 Cheers, Rahul Jesse McConnell wrote: hi everyone, I have been trying to help emmanuel some with pulling together the roadmap for Continuum 1.1 on the wiki and maybe help organize some of the discussions on there. I wanted to get out the url to the wiki roadmap and maybe see how you guys feel about the content on it. I tried to pull out some of the important things from the 170 + issues in jira currently slated for 1.1 and also the roadmap thread that started on this mailing list last month. so..any thoughts and improvements would be much appreciated, I was kinda hoping I could get a somewhat definitive list of the major hotbutton items for Continuum 1.1 on that roadmap page and then link out the appropriate wiki page or jira ticket. http://docs.codehaus.org/display/CONTINUUM/Continuum+1.1+Development+Roadmap I also reworked the front page a bit...it was sort plain...or empty rather. http://docs.codehaus.org/display/CONTINUUM/Home jesse
Re: Continuum 1.1 roadmap
On 3/07/2006 7:17 PM, Jason van Zyl wrote: So you're suggesting we not doing any official alpha/beta releases? Right. - Brett -- Brett Porter <[EMAIL PROTECTED]> Apache Maven - http://maven.apache.org/ Better Builds with Maven - http://library.mergere.com/
Re: Continuum 1.1 roadmap
On 3 Jul 06, at 9:30 AM 3 Jul 06, Brett Porter wrote: On 28/06/2006 8:40 PM, Jason van Zyl wrote: When we last discussed it on the development process, we talked about instead doing regular promotion of the automated builds (eg, roughly once a week we say "this is a stable build with something new/a good fix/etc, let's ask people to test it"). I'd really like to try that (and add anything to continuum to make it easier :) Yes, but we still have to make some official public releases. I don't think we can just release Continuum generated builds and then just release 1.1? Or do I misunderstand what you're talking about. I think we are talking about the same thing, but it's just mechanics. So a fundamental thing I think we need is regular builds that at least passed the basic integration tests (ie, they compiled and the server started). These are what we have now, though I'd rather they came from Continuum and were more easily accessible to joe schmo just coming to the web site. The next thing is regularly approved builds. Currently we schedule and do the alpha/beta thing, but what I'm thinking is not going through the whole release process that is time consuming and doing something more regular - ie every week or two we say "there's been a few new features, or a significant internal change, or some bad bugs fixed and we want people to test it", so we check a particular build is reasonably stable and then vote (or something) to promote it - and we put that up on the web site as the latest "test" build. It's somewhere between unstable nightlies and really stable releases. So you're suggesting we not doing any official alpha/beta releases? I guess what I'm thinking of is something like IDEA's EAP program. Then the final release would what we do now: produce an RC which we intend to be the actual binary, call for testers and vote. Release that, or produce another one, then push it out to the mirrors and announce. Cheers, Brett Jason van Zyl [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
On 28/06/2006 8:40 PM, Jason van Zyl wrote: When we last discussed it on the development process, we talked about instead doing regular promotion of the automated builds (eg, roughly once a week we say "this is a stable build with something new/a good fix/etc, let's ask people to test it"). I'd really like to try that (and add anything to continuum to make it easier :) Yes, but we still have to make some official public releases. I don't think we can just release Continuum generated builds and then just release 1.1? Or do I misunderstand what you're talking about. I think we are talking about the same thing, but it's just mechanics. So a fundamental thing I think we need is regular builds that at least passed the basic integration tests (ie, they compiled and the server started). These are what we have now, though I'd rather they came from Continuum and were more easily accessible to joe schmo just coming to the web site. The next thing is regularly approved builds. Currently we schedule and do the alpha/beta thing, but what I'm thinking is not going through the whole release process that is time consuming and doing something more regular - ie every week or two we say "there's been a few new features, or a significant internal change, or some bad bugs fixed and we want people to test it", so we check a particular build is reasonably stable and then vote (or something) to promote it - and we put that up on the web site as the latest "test" build. It's somewhere between unstable nightlies and really stable releases. I guess what I'm thinking of is something like IDEA's EAP program. Then the final release would what we do now: produce an RC which we intend to be the actual binary, call for testers and vote. Release that, or produce another one, then push it out to the mirrors and announce. Cheers, Brett
Re: Continuum 1.1 roadmap
Trygve Laugstøl a écrit : +1 to most stuff, comments inline. Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. - Remove JDO (at least jpox) because it the source of lot of our issues Remove JPOX, not JDO unless it's required by the new implementation. JDO is a really nice specification and we already have a lot of code that uses it so if we can avoid it that should be prioritized. - implementation of continuum profiles and installation screens(CONTINUUM-44,CONTINUUM-59) - integration of GBuild (CONTINUUM-563) -0, I think that this is a very useful feature but Continuum needs to get the basic stuff right before we start getting fancy. There is nothing wrong in adjusting Continuum so that it is easier to implement this in the future though. - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1, but we need to discuss this as there are many ways of implementing it. - build on dependencies changes This is a very useful feature, have gotten lots of requests for this. - add a tests result summary in build results This one too. Other things that I consider important: * Dead Build Notification Add a thread that will try to see if a build has been hanging for too long. Options include looking at the wall time elapsed, new build output. When it discovers a hung build it can email the administrator of the server, automatically restart Continuum etc. If more features related to process control it can also try to kill the process. We don't have this in jira, but only a stop button for hung build. The thread will be a nice feature. I'll create an issue for this. * Customizable Mail Templates This is something that people find rather useful and should be pretty easy to include. Make sure to make room for both HTML and plain text emails. Document the objects that are available in the Velocity context. The customization is already in the roadmap. Emmanuel
Re: Continuum 1.1 roadmap
ok, I think the roadmap is done now. We have 159 issues. I'll be happy if we can include all these issues in 1.1 :-) Emmanuel Emmanuel Venisse a écrit : Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. - Remove JDO (at least jpox) because it the source of lot of our issues - implementation of continuum profiles and installation screens(CONTINUUM-44,CONTINUUM-59) - integration of GBuild (CONTINUUM-563) - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen - build on dependencies changes - add a tests result summary in build results I'll add missing issues in jira tomorrow when I'll continue the roadmap. Emmanuel
Re: Continuum 1.1 roadmap
- customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen Absolutely. We should talk through this one a bit more, as maybe the solution is to have it better understand module relationships. This also relates to something I'd like to see happen where we have the checkout in the normal layout instead of isolated directories (to avoid checking out the modules twice - once in the parent and once for each module). I created a new issue (CONTINUUM-741) Emmanuel
Re: Continuum 1.1 roadmap
- Remove JDO (at least jpox) because it the source of lot of our issues +1 My only opinion on this is to think about it, but save the work until we bump into the next big problem that is going to require a lot of effort to fix. It seems stable enough in 1.0.3 and if it remains that way through 1.1 it can buy us some time. I'm interested in seeing how JPA progresses as a replacement for this (even if it requires Java 5, which it would be nice to move to anyway :) There should be a better choice of implementations and the API is similar I think. It's a shame we're having so many problems, as the jdo api is actually quite nice. BTW, have we done much trials with databases other than hsqldb and derby? Maybe the problem isn't JDO :) I open an issue for the replacement of it (CONTINUUM-740). Actually, it's planned for 1.1 and we'll can move it to another version if we think it isn't necessary to spend lot of time on it. Some users use Continuum with posgres, mysql or mssql and I don't know if they have issues (except for database schema). Emmanuel
Re: Continuum 1.1 roadmap
On 28 Jun 06, at 10:52 AM 28 Jun 06, Emmanuel Venisse wrote: Jason van Zyl a écrit : On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. Are we deciding that these are the things are going to be in 1.1 and take as long as we need? I would prefer that myself. Looking below there I think that's a good list. I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each items, perhaps we'll do an intermediate release. I assume for this we are going to release a series of alphas? How about for each major feature implemented we release an alpha? The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. If a plexus component is made to integrate Acegi that's cool. As long as Continuum itself has an abstraction for security and Acegi is not coupled directly to Continuum that's fine. Normally, they won't be coupled. Carlos, can you add more informations? If the work is done in a branch we can just comment as the work commences. I'm sure I won't find the time but I would still like to try SASS which Patrick has been working on if I can. - Remove JDO (at least jpox) because it the source of lot of our issues +1 - implementation of continuum profiles and installation screens (CONTINUUM-44,CONTINUUM-59) +1 - integration of GBuild (CONTINUUM-563) +1 - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) +1 Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1 - build on dependencies changes +1 - add a tests result summary in build results +1 I'll add missing issues in jira tomorrow when I'll continue the roadmap. Cool, thanks Emmanuel. Emmanuel Jason van Zyl [EMAIL PROTECTED] Jason van Zyl [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
On 6/28/06, Emmanuel Venisse <[EMAIL PROTECTED]> wrote: Jason van Zyl a écrit : > > On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: > >> Hi, >> >> I started to define the roadmap of continuum 1.1. It will be done >> normally tomorrow. > > Are we deciding that these are the things are going to be in 1.1 and > take as long as we need? I would prefer that myself. Looking below there > I think that's a good list. I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each items, perhaps we'll do an intermediate release. > >> >> The major first things to do in this roadmap are: >> >> - Reimplementation of authentication/authorization management >> (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with >> acegi. Carlos will integrate acegi with plexus. This part must secure >> all requests in continuum and not only don't show some part of the >> interface. >> > > If a plexus component is made to integrate Acegi that's cool. As long as > Continuum itself has an abstraction for security and Acegi is not > coupled directly to Continuum that's fine. Normally, they won't be coupled. Carlos, can you add more informations? Acegi is coupled to some classes of Spring IoC to respond to events that we'll work around in some way with plexus. Everything else related to IoC is just wiring up objects, not tied to Spring. We'll need to get a minimal Spring jar with the classes needed: exceptions, utils,... > >> - Remove JDO (at least jpox) because it the source of lot of our issues >> > > +1 > >> - implementation of continuum profiles and installation >> screens(CONTINUUM-44,CONTINUUM-59) >> > > +1 > >> - integration of GBuild (CONTINUUM-563) >> > > +1 > >> - implementation of project groups (CONTINUUM-30, >> CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) >> > > +1 > >> Other important things I'd want to see in it: >> >> - customization of the add project feature. In this part, I think to >> add a multi-project as a multiple projects or as a single project, scm >> connection string to use, add with a scm url, add all modules by a scm >> connection instead of an url contruction based on project url provided >> in the add screen >> > > +1 > >> - build on dependencies changes >> > > +1 > >> - add a tests result summary in build results >> > > +1 > >> I'll add missing issues in jira tomorrow when I'll continue the roadmap. >> > > Cool, thanks Emmanuel. > >> Emmanuel >> >> > > Jason van Zyl > [EMAIL PROTECTED] > > > > > > -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride
Re: Continuum 1.1 roadmap
Jason van Zyl a écrit : On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. Are we deciding that these are the things are going to be in 1.1 and take as long as we need? I would prefer that myself. Looking below there I think that's a good list. I'd prefer too, but depends of the time we spend on each items. If we need lot of time on each items, perhaps we'll do an intermediate release. The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. If a plexus component is made to integrate Acegi that's cool. As long as Continuum itself has an abstraction for security and Acegi is not coupled directly to Continuum that's fine. Normally, they won't be coupled. Carlos, can you add more informations? - Remove JDO (at least jpox) because it the source of lot of our issues +1 - implementation of continuum profiles and installation screens(CONTINUUM-44,CONTINUUM-59) +1 - integration of GBuild (CONTINUUM-563) +1 - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) +1 Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1 - build on dependencies changes +1 - add a tests result summary in build results +1 I'll add missing issues in jira tomorrow when I'll continue the roadmap. Cool, thanks Emmanuel. Emmanuel Jason van Zyl [EMAIL PROTECTED]
Re: Continuum 1.1 roadmap
On 27 Jun 06, at 10:04 PM 27 Jun 06, Emmanuel Venisse wrote: Hi, I started to define the roadmap of continuum 1.1. It will be done normally tomorrow. Are we deciding that these are the things are going to be in 1.1 and take as long as we need? I would prefer that myself. Looking below there I think that's a good list. The major first things to do in this roadmap are: - Reimplementation of authentication/authorization management (CONTINUUM-542 and CONTINUUM-513): this will be done by carlos with acegi. Carlos will integrate acegi with plexus. This part must secure all requests in continuum and not only don't show some part of the interface. If a plexus component is made to integrate Acegi that's cool. As long as Continuum itself has an abstraction for security and Acegi is not coupled directly to Continuum that's fine. - Remove JDO (at least jpox) because it the source of lot of our issues +1 - implementation of continuum profiles and installation screens (CONTINUUM-44,CONTINUUM-59) +1 - integration of GBuild (CONTINUUM-563) +1 - implementation of project groups (CONTINUUM-30, CONTINUUM-289,CONTINUUM-290, CONTINUUM-291, CONTINUUM-292) +1 Other important things I'd want to see in it: - customization of the add project feature. In this part, I think to add a multi-project as a multiple projects or as a single project, scm connection string to use, add with a scm url, add all modules by a scm connection instead of an url contruction based on project url provided in the add screen +1 - build on dependencies changes +1 - add a tests result summary in build results +1 I'll add missing issues in jira tomorrow when I'll continue the roadmap. Cool, thanks Emmanuel. Emmanuel Jason van Zyl [EMAIL PROTECTED]
