On Jul 19, 2006, at 8:41 AM, Sam Ruby wrote:
Jim Marino wrote:
On Jul 19, 2006, at 2:07 AM, Simon Nash wrote:
I wasn't asking for an "official" policy statement on this, and
I wasn't suggesting that we stop all innovation and move into a
phase where we only work on things that were part of M1.
By releasing M1, we moved from a phase of focusing purely on
the developer community into a phase of starting to attract
potential users as well. I think we need to strike a balance
between the needs of developers and users. We met some
potential users at ApacheCon, and I expect that we will meet
more at OSCON. For now we can point them to M1, but given
our desire to focus around a single codebase that is actively
being enhanced, I would expect that we would want to be able to
start to point these people to the new codebase in the fairly
near future.
And we should. In fact, I would point them at the "new" code now,
not just in the future. That is the codebase chosen by the
community. That is our code.
If you believe the decision to adopt chianti as our code to be in
error, you are free to ask the community to reconsider, although I
believe the vote last week accurately expressed the community will
(as willful an act as it may have been ;-) ).
Of course, people can also resort to M1 if they prefer to
experiment with the .9 version of the SCA specification or
features specific to that milestone.
If history is any guide, the path that has been chosen will result
in another revolution in a year or so's time, reverting a number of
architectural decisions that have been made with this revolution.
However, not *all* will be lost as much of the additions will also
have been retained. What will have been lost is much time.
The Rules for Revolutionaries was penned in a time when Tomcat 4
was poised to replace Tomcat 3. Tomcat 5 was the inevitable result.
Even from a developer community standpoint, I think there is
considerable value in maintaining a working base level of
functionality that can support end-to-end scenarios. This
allows developers creating new code to exercise that code in
the context of real-world usage, in addition to unit tests.
I would imagine there is unanimous agreement on this point as we
are working hard to add "real-world" functionality that interests
members of the community.
Based on your statements, it sounds as if there is functionality
you would like to see added. The somewhat, although not
completely, flippant response to this is: Thanks for volunteering!
Votes work best when the victors are understanding and gracious.
This response treads awfully near towards being rather gloating.
Sorry if it sounds gloating but it was not intended that way. First,
I wouldn't characterize the vote or decision as a matter of "victors"
or "winners". More importantly, my point was to reiterate that if
someone feels a particular piece of functionality important, words
backed by contributions go further than words alone.
If you would like to see a particular set of functionality in
Tuscany you can either request it (preferably in JIRA) or develop
it and submit a patch. Depending on the importance of the feature
to the community, I suspect the latter approach has a higher
probability of success in the short-term. It is also the option I
would personally prefer as it expands the active, contributing
segment of the community.
Votes in the ASF imply a level of commitment. They mean "I will
stand behind this course of action and make it work", not "Hey! I
won! Deal with it!".
And I think my actions and contributions adding functionality to
chianti have demonstrated this.
If there are things that used to work in the M1 trunk that aren't
yet handled completely in Chianti, then I fully expect those that
participated in this vote to pro-actively and expediently work to
close those gaps.
That was exactly my point. That's why I've been working on closing
the gap in areas I deem to be the most pressing (which may receive a
different priority by others and they may choose to approach it
differently).
And with an eye towards giving the benefit of the doubt to the
codebase it replaces (i.e., no: see, it didn't handle this obscure
edge case, so the entire function wasn't fully implemented in M1,
and yes, I've been around the block once or twice).
The alternative is for the people who voted to say that the rules
for voting weren't fully explained to them, in which case, I will
simply say "my bad", and we can hold the vote again.
- Sam Ruby
---------------------------------------------------------------------
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]