On Jul 4, 2006, at 1:11 PM, Simon Nash wrote:
I think releasing every 4-6 weeks is probably a bit too often.
Most users won't want to upgrade so frequently, especially at
this stage of an incubator project when new releases may be a bit
unstable.
At this stage I think we need to have small, incremental releases to
gain momentum, and more importantly, to get features out that
demonstrate the value of Tuscany and attract developers to it. Most
users are bleeding edge people right now so I don't think upgrading
will be an issue. End-users who need to build real, production-ready
applications shouldn't be using Tuscany at this point (they also
shouldn't be using SCA at this stage as the specifications have not
been stabilized). Also, I have found people that deal with open
source software, particularly the developer community we are
primarily concerned with (see my comments below), are used to and
want frequent upgrades.
Another factor is the overhead involved in cutting a
release. On balance I'd suggest releasing every 2 months would be
reasonable timing, with a release closedown cycle starting perhaps
2-3 weeks before the release goes out.
Part of the overhead was due to the fact that we tried to roll
everything together (including SDO and DAS) and it was the our first
time. If we modularize, while we will still have some overhead (e.g.
voting), 4-6 week release cycles seem reasonable to me. I'm not
saying *everything* should be released at the same time or at that
pace. We should be modular enough to break out releases. Also, if a
module does not change much, it does not need to be released that
frequently. However, two month time frames with a 2-3 week feature
freeze sounds a bit long but it's not that far off from 4-6 weeks (a
feature freeze of three weeks is a bit lengthy though).
I think there's value in forward planning for release content.
Our scenarios should provide a basis for deciding what new function
is most needed in the next release, and maybe even thinking a bit
further ahead ("pencilled in" rather than a firm commitment or plan).
For major pieces of functionality, it is likely that forward planning
will be needed to get a realistic idea of what can be fitted into
each release.
While I have no problem with lightweight planning, coordination, etc.
I don't think we can or should project manage our release cycle
according to dates (which are different than "timeframes"). I'm not
sure if you are arguing for that, but I throw it out for discussion
anyway. We're dealing with volunteers, not resources under our
control. I'd rather use the scenarios as a roadmap and when we arrive
at a functional state we believe worthy for release, enter into a
ramp down period. Of course we can have timeframes and goals for the
release, but IMO it would be wrong to over-manage the project by
instituting a release schedule pegged to specific dates.
Other items that are smaller or less critical to our
users (don't forget that these are the audience for our releases) can
be accomodated with a lot less in the way of pre-planning.
I think the way people deal with features that are really important
is to make sure they are implemented. What is important to you may or
may not be important to me. We can both get what we want by doing the
work to implement them - and I may even help you with yours because
you are a nice guy ;-) My point is while there may be some features
everyone agrees on that are important, there will be others that are
important to only a particular segment. We need to be able to
accommodate and encourage this diversity.
One other point is I don't think end-users are our primary audience,
although they are an important constituency. I'd say we are the most
important audience, in other words, the Tuscany developer community.
Simon
Jim Marino wrote:
On Jul 3, 2006, at 11:31 PM, ant elder wrote:
On 7/3/06, Jim Marino <[EMAIL PROTECTED]> wrote:
...and involve a lot less "upfront planning"?
In other words, people work on what interests them and the
community
cuts a release when it decides a useful level of new functionality
has been reached.
Can you provide pointers to any other Apache projects that work
like this?
I've never seen any other project of significant size, open
source or
otherwise, work like that.
There's three main problems I see with the 'do whatever you
like' approach.
Please read my words carefully:
- I wrote, "a lot less 'upfront planning'" as opposed to "no
upfront planning". I'm not an anarchist :-)
- The rest of the passage was also important in this respect:
"Practically, people should just detail the scenarios and
features that they think are interesting on the wiki, through
email, etc. and work on implementing them". By *documenting* what
interests people in some way (we should be flexible here),
letting people work on those features, and then deciding at quick
intervals (4-6 weeks) when to cut a release sounds pretty
reasonable to me. The "lightweight" planning part comes in with
the documenting of interests and then the decision process to
have a release.
Of course, there is the waterfall approach commonly associated
with commercial software development. I don't think this works
well in many open source environments for a variety of reasons
that I won't go into as they are off topic.
In terms of open source projects, I think you will find this type
of "lightweight" planning happening in a lot of projects. For
example, AspectWerkz operated very successfully this way as does
Spring (although they are taking a little longer for releases,
probably due to the maturity of the project). I think you will
find some Apache projects as well...
With no clear goals, direction, or coordination we wont end up
with anything
very useful that fits together and works in an elegant and
seamless way.
I probably could have gone into more detail on my thinking around
release cycles, but it should be patently clear that I was not
advocating an agenda of no goals and no coordination. I assume
you did notice that I have been spending a lot of time creating
scenarios on the wiki? It is also the subject of the current
thread. Hyperbole in my opinion doesn't really move the community
forward.
I believe scenarios are an excellent way to form a basis for
coordination and bring the community together. My point was that
by having people detail what interests them, others join in and
a consensus emerges when certain scenarios gain momentum. I find
this to be a nice balance between the interests of large group as
well as smaller pockets of one or two individuals. Under this
system, one or two people can make a difference since they are
free to implement features they feel strongly about (assuming
they are aligned with the project charter).
No
one will do the boring work - documentation, testing,
uninteresting bugs in
JIRAs, etc.
That's why we have coding standards. I have been one of the
staunchest advocates of unit testing, documentation, etc. as you
are aware.
And it will be hard to grow the community.
Modularity, scenarios and having a positive environment which
encourages people to work on what interests them are all great
ways to grow a community.
Over the past months I've been trying to get new people to come
participate
in Tuscany and they all complain about no roadmap of what we
trying to
achieve, no wish list of wanted function, and no plan of whats
coming up in
the next few milestones.
In the past we had "roadmaps" here:
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Tasks
http://wiki.apache.org/ws/Tuscany/TuscanyJava/Roadmap
There is, however, a general issue related to the SCA specs and
Tuscany of what the value adds are. I have been working with
others in the spec group to help fix this from the braoder SCA
perspective.
In terms of Tuscany, I would suggest we as a community do
likewise. To me, that starts with actions of individuals. Could
you please begin by posting your "wish list" of wanted function
somewhere? I think it would be great to do this as scenarios but
emails to the list will do.
Yes we need to encourage new people to come
contribute whatever function they think is useful regardless of
if or where
we had that function in our plans, but surely the main
development team need
to have a bit more focus and coordination if we're to create
something very
useful.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Simon C Nash IBM Distinguished Engineer
Hursley Park, Winchester, UK [EMAIL PROTECTED]
Tel. +44-1962-815156 Fax +44-1962-818999
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
