geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Date Wed, 20 Jul 2005 01:51:12 GMT
Thanks for pushing on this issue.

I think it is really important that we put out a 1.0 release very soon. 
  I think it needs to work, and be tck compliant, but I don't think it 
has to be all that much more usable than what we have now.  I'd rather 
get feedback and users than perfection.

The features I think we need for 1.0 are:

clean up some architectural problems.  I think I'll get the ones I know 
about fixed by the end of this week.
clean up the plan xml.  I think this is a fairly quick job.
Decide what we will continue to support from our 1.0 release.  IMO this 
is only the plan xml schemas and possibly some interfaces exposed by 
some gbeans, primarily gbeans "exposed" by jsr-77
get the web console in, preferably with instructions on how to change 
the static page in which the portlets appear.

I'd like to get 1.0 out by Sept 15th.

Can everyone think carefully about what they really need to be in 1.0, 
what they will commit to actually implementing themselves, and when 
they think it can be done by?

david jencks

On Jul 19, 2005, at 12:58 PM, David Blevins wrote:

> On Jul 19, 2005, at 7:06 AM, wrote:
>> Maybe after M4 is out we should look at creating some further 
>> milestone versions in JIRA and start assigning some of the tasks that 
>> were in the Roadmap that Geir discussed to them, so we can get a good 
>> visual on the project's plans.
>> At the moment it isn't obvious (from JIRA) what needs to be done to 
>> get to a 1.0 release, and how we are going to achieve that (steps 
>> along the way).  The JIRA roadmap view is useful to see what is 
>> planned for future releases and would probably assist prioritizing 
>> work.  There are also a lot of unscheduled issues that would be nice 
>> to place on a roadmap.  Maybe a review of tasks for future milestones 
>> should be done at the end of each milestone?    Comments?
> We are still hammering on M4, so I don't want to distract people to 
> much.  Just want to get people thinking.
> I have a couple things in my mind still in the abstract.  Will try to 
> get them out in some sensible way.  Bare with me.
> <rambling>
> Ok, so it's been a year since M3 (ouch) and we have threatened to do 
> an M4 several times.  Why did we keep putting off M4 even though we 
> knew very well M3 was no good?  I think the reason is something along 
> the lines of 1) being optimistic in many forms, 2) wanting the next 
> release to be some form of perfect, 3) being focused on a couple (or 
> one) very large goal.
> More important than 1, 2 or 3 is time.
> Let's ask ourselves:
>   - How much usablility feedback could we have gotten in an entire 
> year's time?
>   - How many releases could we have done in the last year?
>   - How many would-be committers and users did we miss out on by not 
> releasing?
> Let's be more humble and admit that every release is going to "suck" 
> to some degree (i.e. not be perfect) and it's better to work on 
> getting them out faster, not slower.
> We need to stop making such a bid deal about the next release, which 
> only slows it down, and start thinking two or three releases out.
> Normally some form of competition would drive us to push releases out 
> the door quickly and keep our goals in check with what people really 
> do need now and what they would be fine having later.  There is 
> competition out there, but it's us not competing with them, not the 
> other way around.  Sorry, just calling it like I see it.
> Alright, IMHO, we've outgrown milestones.  Better said we've attained 
> our goal of passing the CTS, the major technical milestone.  Now we 
> all are focusing on usability.  From my experience, obtaining 
> usability is all about iterations, as many as you can get and as often 
> as you can get them.  I think milestones will actually slow us down on 
> achieving our goal of usability.
> We are going to have to crank out a half dozen releases minimum over 
> the next couple months in order to achieve the kind of growth we want. 
>  At this point in the game it's all about momentum.  We need to be an 
> unstoppable freight-train leaving a trail of release numbers behind us 
> and picking up as much community we can carry as we go forward.
> Pushing a milestone every three months is not going to cut it, nor is 
> Geronimo 1.0 M12 such good idea either.
> The 1.0 release is not about the cool things we want to add to make 
> Geronimo great.  It's about reaching a point where you and the users 
> agree on what will be supported in a year's time, which won't be much 
> as it's a 1.0, not a 2.0 or 3.0 or 4.0.  That's it, no more, no less.  
> All sorts of cool things can be added later!
> Here is the point where I have particular experience, ... you will 
> cross that magical "1.0" line at some point, wether you choose to call 
> it 1.0 or not!
> At some point, people will start using the software and become 
> dependent on whatever you are at the time.  Their expectations will 
> naturally settle on what you have and not where you say you are going. 
>  1.0 or not, you now have to maintain stability, only you weren't so 
> clear on what was going to change and what was to remain supported (be 
> at least backwards compatible), so now you are in the position to have 
> to support much more than you wanted.
> </rambling>
> Anyway, those are my rambling thoughts and experiences.  Just throwing 
> them out there for now.
> -David

View raw message