You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Blevins <da...@visi.com> on 2005/07/19 21:58:04 UTC
Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
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
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) -- more feedback please
Posted by Joe Bohn <jo...@earthlink.net>.
OK, you asked for it so here is my opinion.
I agree that once R1 is delivered there should be no more milestones ...
but rather maintenance releases. I assume
that by not doing milestones we will be creating new releases instead.
This is what should be planned out in our
roadmap. We should have a general statement like "we will build a
maintenance release (which may include minor
enhancements) every 6-8 weeks." I think we should strive for a major
release every year or sooner. The thing
that I've seen stymie other projects is to get so wrapped up in
incremental change that the "big things" can never
really get done because there just isn't enough time. Having a roadmap
and focusing some energy on larger
items that are targeted for new releases (or span multiple smaller
releases) would help to prevent this problem.
It's also been my experience that nobody really installs release 1.0,
2.0, or x.0 on any production system. It is
always assumed that there are bugs that still need to be worked out so
most people will wait until a .1 or .2 release
before moving it into production. This is also another reason to
ensure that we have regular deliveries that
follow the "large" releases to "clean up the loose ends".
David Blevins wrote:
> Panagiotis,
>
> Thank you very much for posting some feedback. We need a lot more
> people like you helping us with direction and feedback!
>
> Hey everyone, seriously, post! We are here to serve.
>
> Best regards,
> David
>
> On Jul 20, 2005, at 3:16 AM, Panagiotis Astithas wrote:
>
>> David Blevins wrote:
>>
>>> 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
>>>
>>
>> Amen :-)
>>
>>
>>> 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?
>>>
>>
>> It is interesting that even Erich Gamma (among others) considers
>> this to be an important factor in building a thriving community
>> around Eclipse:
>>
>> http://www.artima.com/lejava/articles/eclipse_culture.html
>>
>>
>>> 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.
>>>
>>
>> Precisely!
>>
>>
>>> Pushing a milestone every three months is not going to cut it, nor
>>> is Geronimo 1.0 M12 such good idea either.
>>>
>>
>> While Geronimo 1.0.8 is perfectly fine.
>>
>>
>>> 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!
>>>
>>
>> We should also keep in mind that hardly anyone is going to recommend
>> a Geronimo installation in production while still in beta versions.
>>
>>
>>> 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
>>>
>>
>> I've been seeing many open-source projects gradually transitioning
>> from feature-oriented releases to time-based ones. Users tend to
>> upgrade regularly, treating software like a constantly evolving
>> organism that grows and matures.
>>
>> Regards,
>>
>> Panagiotis
>>
>>
>
>
>
--
Joe Bohn
joe.bohn@earthlink.net
"He is no fool who gives what he cannot keep, to gain what he cannot lose." -- Jim Elliot
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) -- more feedback please
Posted by David Blevins <da...@visi.com>.
Panagiotis,
Thank you very much for posting some feedback. We need a lot more
people like you helping us with direction and feedback!
Hey everyone, seriously, post! We are here to serve.
Best regards,
David
On Jul 20, 2005, at 3:16 AM, Panagiotis Astithas wrote:
> David Blevins wrote:
>
>> 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
>>
>
> Amen :-)
>
>
>> 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?
>>
>
> It is interesting that even Erich Gamma (among others) considers
> this to be an important factor in building a thriving community
> around Eclipse:
>
> http://www.artima.com/lejava/articles/eclipse_culture.html
>
>
>> 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.
>>
>
> Precisely!
>
>
>> Pushing a milestone every three months is not going to cut it, nor
>> is Geronimo 1.0 M12 such good idea either.
>>
>
> While Geronimo 1.0.8 is perfectly fine.
>
>
>> 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!
>>
>
> We should also keep in mind that hardly anyone is going to
> recommend a Geronimo installation in production while still in beta
> versions.
>
>
>> 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
>>
>
> I've been seeing many open-source projects gradually transitioning
> from feature-oriented releases to time-based ones. Users tend to
> upgrade regularly, treating software like a constantly evolving
> organism that grows and matures.
>
> Regards,
>
> Panagiotis
>
>
Re: Thinking beyond 1.0 (e.g 1.1, 1.2)
Posted by Panagiotis Astithas <pa...@ebs.gr>.
David Blevins wrote:
>
> 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
Amen :-)
> 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?
It is interesting that even Erich Gamma (among others) considers this to
be an important factor in building a thriving community around Eclipse:
http://www.artima.com/lejava/articles/eclipse_culture.html
> 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.
Precisely!
> Pushing a milestone every three months is not going to cut it, nor is
> Geronimo 1.0 M12 such good idea either.
While Geronimo 1.0.8 is perfectly fine.
> 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!
We should also keep in mind that hardly anyone is going to recommend a
Geronimo installation in production while still in beta versions.
> 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
I've been seeing many open-source projects gradually transitioning from
feature-oriented releases to time-based ones. Users tend to upgrade
regularly, treating software like a constantly evolving organism that
grows and matures.
Regards,
Panagiotis
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Posted by David Blevins <da...@visi.com>.
On Jul 21, 2005, at 8:44 AM, Matt Hogstrom wrote:
> 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).
Don't be dismayed. The actual quote, "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" is more of a call to get
people to not put releases on a pedestal such that they never come.
-David
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Posted by Matt Hogstrom <ma...@hogstrom.org>.
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" <am...@alumni.princeton.edu>
To: <de...@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
> > >
> > >
> > >
> >
> >
>
>
>
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for
future releases)
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
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
> >
> >
> >
>
>
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Posted by Dain Sundstrom <da...@iq80.com>.
On Jul 19, 2005, at 6:51 PM, David Jencks wrote:
> 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
I'd add "well defined gbean names such as the Deployer" to the
stability list. I think we should be very clear about what we are
supporting for the long term. This should be documented and if
possible tested.
-dain
Re: Thinking beyond 1.0 (e.g 1.1, 1.2) (was: Managing tasks for future releases)
Posted by David Jencks <da...@yahoo.com>.
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
>
>
>