geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Hogstrom" <m...@hogstrom.org>
Subject Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Date Thu, 21 Jul 2005 13:44:26 GMT
My 2c...

On the issue of releases there are several different types of folks that are
interested in using Geronimo.  Off the top of my head they are:

Techies that want an implementation to play around with and are very
comfortable with an unstable, constantly evolving codebase.  (Unstable is
good enough)

Developers that want a J2EE compliant container that is mostly stable (more
stable than not) so they can quickly crank out some code.  They are willing
to accept bug fixes but their goal is more on getting applications coded
than on coding the Application Server.  (Milestones are good enough)

ISVs.  These folks need a stable infrastructure because they are most likely
imbedding Geronimo and their application together.  Their need for stability
is significantly higher than the perceding two.  They would choose to
support the App Server themselves or pay someone for support.  Their goal is
to sell applications and make some money.  (Vn.n is their preferred choice
of delivery)

Enterprise customers.  They are in business to make money and technology is
a business decsision.  They want infrastructure that will not disrupt their
business, provides a good function / per dollar spent.  They want (Vn.1+ and
support so they don't have to chase things down).  They want N-1 or  N-2
compatibility so things don't break and they have to rework their
infrastructure.  They are the most demanding.

I'm a bit dismayed about the previous posts about "assuming a release will
suck".  If thats your view then it will suck and one has to ask what is the
relvance of the project?  I think the goals in the past has been to get to
J2EE 1.4 certification and you guys made it (well almost).  IMHO the
important item at this point is for the PMC to set a list of goals for a
release and a target date.  I know that the community doesn't operate on a
schedule but I think its important to have a set of goals that folks are
converging on as a team.  Perhaps there is a model that Eclipse uses with
their sub projects for additional function that might be worth considering.
If my understanding is correct they have the Eclipse project and a number of
sub projects that add value.  (UML, EMF, etc.)  What if we had a set of core
J2EE functionality for Geronimo and a set of subprojects that could be
bolted in (like clustering for instance).  It would allow them to be a bit
more independent in terms of development and delivery and would allow the
Core to be more stable in terms of release.

I agree with Jencks that a September deliverable makes sense if we can agree
what the content should be.  For my part I would like to add ARM support for
the post V1.x product and some monitoring capability.  (I'll open JIRA
features today).  There are a lot of excellent ideas on the table to make
Geronimo immensely useful and widely adopted.  The team has not built
something that sucks; its just yound and it will grow up, if we want it to.

<Flamesuit state=on/>

- Matt


----- Original Message ----- 
From: "Aaron Mulder" <ammulder@alumni.princeton.edu>
To: <dev@geronimo.apache.org>
Sent: Wednesday, July 20, 2005 12:06 PM
Subject: Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for
future releases)


>         For my part, I'm not convinced that September is realistic for
> 1.0.  But I definitely hope to get 1.0 out by ApacheCon US (December).  I
> need to spend some time on what I want to see in 1.0.  Perhaps a 1.0
> release number should be added to JIRA, so we can put things in there, and
> then mark them back to a sooner milestone where appropriate.
>
> Aaron
>
> On Tue, 19 Jul 2005, David Jencks wrote:
> > 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?
> >
> > thanks
> > david jencks
> >
> >
> > On Jul 19, 2005, at 12:58 PM, David Blevins wrote:
> >
> > >
> > > On Jul 19, 2005, at 7:06 AM, sissonj@insession.com 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>
> > > RELEASE OFTEN, PERFECT OR NOT
> > >
> > > 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.
> > >
> > > MILESTONES AND USABILITY
> > >
> > > 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.
> > >
> > > 1.0, THE UNATTAINABLE GOAL (CROSSING THE LINE)
> > >
> > > 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
> > >
> > >
> > >
> >
> >
>
>
>





Mime
View raw message