You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2001/11/23 11:38:10 UTC
[tale+rant] The 2.0 syndrome
Once upon a time,
there was a group of distinguished software engineers (also known as
'geeks') who were redesigning a piece of software called "Cocoon".
The geek who started all this was young and even was the technology so
he made a bunch of design mistakes trying to get it right the first
time. Other friendly geeks came, showed him the mistakes and worked
together in peace and harmony to come up with a new version that would
remove those issues.
Being the second attempt, they called the effort "2.0".
Seasons passed and the productive geeks were crunching lines and lines
of code and the more noise they were making, the more geeks were
attracted by this idea of the big "2.0" release.
They knew how painful it was to discover the limitations of the first
release so, this time, they want to make it *right*.
So, everytime somebody passed by and had to suggest something they found
important, they kept on saying "oh, this is right, the users will love
this, let's move this pixel down one spot".
They were trapped in the "2.0 syndrome": an endless loop of postponing
the release for the fear of having to modify it again in the future.
So they continued to work and work and work and they were producing an
incredibly valuable software, but their community died because nobody
could ever see what they were working on.
The end.
- o -
Result: let's get this damn release out, people!
Documentation is not good enough? who cares!
Files are not in their *best* position? we'll move them later.
It seems that everyone around here has gone nuts: in case you didn't
know, we are *NOT* a software house and the people using our software
are *used* to open source and "fixme" tokens scattered around.
The *ONLY* thing we should be concerned for a final release is if the
*contracts* users will build on are *solid* enough to be considered
final.
*contracts* people, CONTRACTS!
Do you build your software on the location of our files into the
distribution? well, if you do it, you're nuts.
Do you build your software on the wording of the documentation so that
if they change you're screwed? no way.
Gosh, where did "release early and often go"? down the drain?
Linus Torvalds invented the concept of open development by making a
kernel release *each* *day* for months! [of course, he never used CVS so
he was forced to]
I started Cocoon 2.0 in November 1999.
It took two damn years and we want to move files around few days before
final release? Are we going insane?
The question is simple: are the code contracts (interfaces, components,
API, schemas, protocols) solid enough for a final release?
If so, we release *NOW*.
If not, we fix it.
*ANYTHING ELSE* can be added to 2.0.1 or 2.1 (depending on what naming
scheme we'd like to use)
Moreover: your *elegance taste* might tell you that the better a
software release is, the more people will use it.
This might be correct (nobody knows).
But, this also creates a big user community but doesn't help the
development one.
We want people that uses cocoon in order for them to come here and help.
This is the final goal: the more hands the better.
Is anybody going to help us if they find everything already good and
perfect in the final release?
I love slightly confused distributions because they force you to come
back and interact with the community.
This is the way I infected all of you: Cocoon 1.0 should have been
called Cocoon 0.01alpha but then we would now aim for Cocoon 1.0 today,
but I'd almost be alone around here.
yes, people, I fooled you with inflated version numbers.
Now, tell me, was I successful in creating this community? well, you
have to use a couple of tricks.
And believe me, *polishing* a final release lowers the chance of
building a community around it in open source, unlike common sense seems
to suggest.
So, guys, even if I totally understand your concerns, let's cut the crap
and release the damn thing as far as contracts are solid and *build
dist* works.
We'll polish it down the road.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stefano Mazzocchi wrote:
>
> Carsten Ziegeler wrote:
> >
> > Hi Stefano,
> >
> > a really nice fairy tale...
> >
> > I totally agree with you, that we should get this release out very soon,
> > but as the last months when we released the betas and the rcs showed,
> > there were many new users which very totally frustrated with c2 as they
> > didn't get it working. And I think 80% of them could have been helped
> > if the documentation were more complete. OK, they all could use the
> > mailing lists to get their problems fixed, but the usual user doesn't
> > want to do so. He will something which simply works. And I really
> > don't want to say: "Who cares about them?" And I personally
> don't want to
> > say: "Hey, it's opensource, so what do you expect?"
>
> Oh, c'mon, did I ever say that?
>
> My point is entirely different: what would you choose? a perfect project
> with a perfect documentation that takes three years to get out, or a
> nice project with sloppy documentation that takes two and adds
> documentation down the road?
>
> *final* in my vocabulary doesn't mean *perfect*, doesn't even mean *the
> way I'd love it to be*.
>
> It simply means: I don't expect much back-compatible changes in the
> contracts between the framework and the user's code.
>
> Period.
>
Agreed!
> Everything else can (and *must*, I totally agree) come after this.
>
> Another choice: would you like a software with sloppy docs but solid
> contracts or software with nice docs but contracts that change every
> bugfix release?
>
> > We all here know that Cocoon is a great piece of softwarwe, but for
> > what, if noone except some geeks can use it? Ok, you argue that
> > all these users will join the developer site and help us. This
> > might be true. Who knows this?
>
> Nobody knows, but my personal experience (judge the value of it
> yourself) tells me that sloppy docs never harmed any open source project
> (linux kernel project was successful much before the linuxdoc project
> started), while moving targets did.
>
> > So, my plan was to get as much documentation as possible and use
> > this time to sort out some other areas (like the directory structure
> > etc. in the meantime). Not all of us are capable of writing good
> > documentation and they can spend their time on the other things.
> > But of course, you're a right that the directory structure should
> > not delay the release.
> >
> > Ok, at least, the gap between our opinion about the final release
> > date is not that wide.
> > Let's see how we can make it? What about this? We leave the directory
> > structure as it is for now and we add any documentation that is
> currently
> > in the pipeline. If noone is currently working on documentation,
> > we will do the release on monday as proposed some month ago.
> > If there is someone working on it, he should comeup now and say if he
> > it is worth waiting for it.
>
> Carsten,
>
> you've been the third release coordinator of this project (myself and
> giacomo before you) and, IMO, you've done an absolutely outstanding job.
>
Thanks.
> My tale/rant was *NOT* a critic to your proposal of directory changing,
> but a more general critic to the "priority list" that this project seems
> to have adopted.
>
> Is documentation more important than contract solidity? NO! Never! You
> should not sacrifice *any* solidity for docs.
>
> Again: is lack of commercial-quality documentation harmful for an open
> source project? NO! It might slow down adoption (this is absolutely
> correct) but sometimes it's even a good filter.
>
> Even more: which software is better to build a community around it? a
> perfect codebase or a buggy codebase? the *buggy* one!!!
>
> The *one* and *only* thing that harms an open source project is lack of
> solidity in the contracts (being them protocols, interfaces, APIs,
> schemas, design patterns) and lack of solidity and diversity in the
> development community.
>
> Please, read my lips: I'm NOT advocating that Cocoon should *NOT* have a
> good documentation or that Cocoon devs should not be making all possible
> efforts to make Cocoon simpler to use.
>
> I'm *JUST* saying that documentation and usability (despite their
> absolute and invaluable importance) [not even mentioning cosmetic
> cleanup] should *NOT* be *showstoppers* for a *FINAL* release.
>
> My simple idea is: let's get the release out and then improve it later
> on.
>
> I'm *NOT* advocating: let's get the shit out and let the users dig into
> it, we'll move on talking about RTs and more sexy stuff.
>
> I'm simply saying that postponing further the final release for some
> showstoppers that should not stopping any open source project, is
> hurting more than any addition that we could add.
>
Ok, now I get what you meant. Indeed, believe it or not, we have absolutely
the same opinion. Contracts are very important. No doubt. And exactly stable
contracts were the reasons why it took so long from the beta 1 to the rc2.
But, unfortunately, not much was done through this period on docs, but
fortunately this changed in the last days!
> So, please, let's come up with a *showstopper* list and we'll identify
> which one is really stopping the release and what is not and can be
> postponed later on.
>
Yes, that sounds great. Ironically, we have found two showstoppers (well at
least one) after we started this discussion on friday:
Here is the list from bugzilla:
------------------------------
ID Sev Pri Plt Owner State Result Summary
5051 Blo Hig All cocoon-dev@xml.apache.org NEW Resolving relative to
subsitemaps does not work
5060 Blo Oth PC cocoon-dev@xml.apache.org NEW Poorly formed filesystem URL
with file:// issues
5063 Blo Oth Oth cocoon-dev@xml.apache.org NEW Distribution .war broken in
Tomcat 4
I think, at least, #5060 is a real blocker, #5051 would be nice to fix but
as this bug is in there
since over a year and noone complaint...And #5063 should be easily fixed by
changing the build scripts.
So, what do you all think about these blockers? Let's fix them and get this
great release out!
Carsten
PS: Stefano, the more we discuss on this list, the more I feel we should
meet somewhere and
have some beer. It's really nice raining here in Paderborn, what do you
think?
> Thanks.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
AW: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Posted by Matthew Langham <ml...@s-und-n.de>.
Stefano & Carsten & Others :-),
There is no doubt that this Cocoon community is one of the strongest Open
Source communities around. Just look at the number of people subscribed to
the lists to see that. Also, one of the reasons for this is that the people
here are so diverse - as we can follow nearly every day on this list - And
this is Great!
=> With Cocoon, the community has a fantastic chance. There is still (even
after 2 years) nothing that can compare to it (neither OS or commercial) so
we can establish Cocoon as _the_ XML application platform (that's my feeling
anyway).
=> Releasing Cocoon will make the community stronger. There is no doubt
about that.
=> Releasing Cocoon will increase the "visuality" of the project in the
media. For example - Carsten and I are currently writing articles on Cocoon
for several publications - to coincide (roughly) with the release.
=> Cocoon is ready for "prime-time", in fact I think after 2 years of
development we _really_ need to release it. Otherwise no-one will take the
project seriously.
=> Cocoon has also already made its mark on the commercial side. HP, our
company and others are already using it to build industry-strength
applications. And more will follow as soon as the release is out. So we also
need "to get it right". We don't want to scare people off using Cocoon - do
we?
So we need to find the correct balance between our different and varied
opinions. I agree that we need to remove the blockers before releasing 2.0
and make sure the documentation is enough to stop people panicking and using
something else. In addition we need to make sure people _know about_ this
great community so that they can find their way here - regardless of whether
they are users, developers, lurkers, head-hunters :-). You name it - they
should all know about Cocoon.
And last - to quote Guy Kawasaki: "Build a great product - and they will
come". So let's release this really great product!
Matthew
--
Open Source Group sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30 mlangham@s-und-n.de - http://www.s-und-n.de
=================================================================
-----Ursprungliche Nachricht-----
Von: Stefano Mazzocchi [mailto:stefano@apache.org]
Gesendet: Samstag, 24. November 2001 13:06
An: cocoon-dev@xml.apache.org
Betreff: Re: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Carsten Ziegeler wrote:
>
> Hi Stefano,
>
> a really nice fairy tale...
>
> I totally agree with you, that we should get this release out very soon,
> but as the last months when we released the betas and the rcs showed,
> there were many new users which very totally frustrated with c2 as they
> didn't get it working. And I think 80% of them could have been helped
> if the documentation were more complete. OK, they all could use the
> mailing lists to get their problems fixed, but the usual user doesn't
> want to do so. He will something which simply works. And I really
> don't want to say: "Who cares about them?" And I personally don't want to
> say: "Hey, it's opensource, so what do you expect?"
Oh, c'mon, did I ever say that?
My point is entirely different: what would you choose? a perfect project
with a perfect documentation that takes three years to get out, or a
nice project with sloppy documentation that takes two and adds
documentation down the road?
*final* in my vocabulary doesn't mean *perfect*, doesn't even mean *the
way I'd love it to be*.
It simply means: I don't expect much back-compatible changes in the
contracts between the framework and the user's code.
Period.
Everything else can (and *must*, I totally agree) come after this.
Another choice: would you like a software with sloppy docs but solid
contracts or software with nice docs but contracts that change every
bugfix release?
> We all here know that Cocoon is a great piece of softwarwe, but for
> what, if noone except some geeks can use it? Ok, you argue that
> all these users will join the developer site and help us. This
> might be true. Who knows this?
Nobody knows, but my personal experience (judge the value of it
yourself) tells me that sloppy docs never harmed any open source project
(linux kernel project was successful much before the linuxdoc project
started), while moving targets did.
> So, my plan was to get as much documentation as possible and use
> this time to sort out some other areas (like the directory structure
> etc. in the meantime). Not all of us are capable of writing good
> documentation and they can spend their time on the other things.
> But of course, you're a right that the directory structure should
> not delay the release.
>
> Ok, at least, the gap between our opinion about the final release
> date is not that wide.
> Let's see how we can make it? What about this? We leave the directory
> structure as it is for now and we add any documentation that is currently
> in the pipeline. If noone is currently working on documentation,
> we will do the release on monday as proposed some month ago.
> If there is someone working on it, he should comeup now and say if he
> it is worth waiting for it.
Carsten,
you've been the third release coordinator of this project (myself and
giacomo before you) and, IMO, you've done an absolutely outstanding job.
My tale/rant was *NOT* a critic to your proposal of directory changing,
but a more general critic to the "priority list" that this project seems
to have adopted.
Is documentation more important than contract solidity? NO! Never! You
should not sacrifice *any* solidity for docs.
Again: is lack of commercial-quality documentation harmful for an open
source project? NO! It might slow down adoption (this is absolutely
correct) but sometimes it's even a good filter.
Even more: which software is better to build a community around it? a
perfect codebase or a buggy codebase? the *buggy* one!!!
The *one* and *only* thing that harms an open source project is lack of
solidity in the contracts (being them protocols, interfaces, APIs,
schemas, design patterns) and lack of solidity and diversity in the
development community.
Please, read my lips: I'm NOT advocating that Cocoon should *NOT* have a
good documentation or that Cocoon devs should not be making all possible
efforts to make Cocoon simpler to use.
I'm *JUST* saying that documentation and usability (despite their
absolute and invaluable importance) [not even mentioning cosmetic
cleanup] should *NOT* be *showstoppers* for a *FINAL* release.
My simple idea is: let's get the release out and then improve it later
on.
I'm *NOT* advocating: let's get the shit out and let the users dig into
it, we'll move on talking about RTs and more sexy stuff.
I'm simply saying that postponing further the final release for some
showstoppers that should not stopping any open source project, is
hurting more than any addition that we could add.
So, please, let's come up with a *showstopper* list and we'll identify
which one is really stopping the release and what is not and can be
postponed later on.
Thanks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
>
> Hi Stefano,
>
> a really nice fairy tale...
>
> I totally agree with you, that we should get this release out very soon,
> but as the last months when we released the betas and the rcs showed,
> there were many new users which very totally frustrated with c2 as they
> didn't get it working. And I think 80% of them could have been helped
> if the documentation were more complete. OK, they all could use the
> mailing lists to get their problems fixed, but the usual user doesn't
> want to do so. He will something which simply works. And I really
> don't want to say: "Who cares about them?" And I personally don't want to
> say: "Hey, it's opensource, so what do you expect?"
Oh, c'mon, did I ever say that?
My point is entirely different: what would you choose? a perfect project
with a perfect documentation that takes three years to get out, or a
nice project with sloppy documentation that takes two and adds
documentation down the road?
*final* in my vocabulary doesn't mean *perfect*, doesn't even mean *the
way I'd love it to be*.
It simply means: I don't expect much back-compatible changes in the
contracts between the framework and the user's code.
Period.
Everything else can (and *must*, I totally agree) come after this.
Another choice: would you like a software with sloppy docs but solid
contracts or software with nice docs but contracts that change every
bugfix release?
> We all here know that Cocoon is a great piece of softwarwe, but for
> what, if noone except some geeks can use it? Ok, you argue that
> all these users will join the developer site and help us. This
> might be true. Who knows this?
Nobody knows, but my personal experience (judge the value of it
yourself) tells me that sloppy docs never harmed any open source project
(linux kernel project was successful much before the linuxdoc project
started), while moving targets did.
> So, my plan was to get as much documentation as possible and use
> this time to sort out some other areas (like the directory structure
> etc. in the meantime). Not all of us are capable of writing good
> documentation and they can spend their time on the other things.
> But of course, you're a right that the directory structure should
> not delay the release.
>
> Ok, at least, the gap between our opinion about the final release
> date is not that wide.
> Let's see how we can make it? What about this? We leave the directory
> structure as it is for now and we add any documentation that is currently
> in the pipeline. If noone is currently working on documentation,
> we will do the release on monday as proposed some month ago.
> If there is someone working on it, he should comeup now and say if he
> it is worth waiting for it.
Carsten,
you've been the third release coordinator of this project (myself and
giacomo before you) and, IMO, you've done an absolutely outstanding job.
My tale/rant was *NOT* a critic to your proposal of directory changing,
but a more general critic to the "priority list" that this project seems
to have adopted.
Is documentation more important than contract solidity? NO! Never! You
should not sacrifice *any* solidity for docs.
Again: is lack of commercial-quality documentation harmful for an open
source project? NO! It might slow down adoption (this is absolutely
correct) but sometimes it's even a good filter.
Even more: which software is better to build a community around it? a
perfect codebase or a buggy codebase? the *buggy* one!!!
The *one* and *only* thing that harms an open source project is lack of
solidity in the contracts (being them protocols, interfaces, APIs,
schemas, design patterns) and lack of solidity and diversity in the
development community.
Please, read my lips: I'm NOT advocating that Cocoon should *NOT* have a
good documentation or that Cocoon devs should not be making all possible
efforts to make Cocoon simpler to use.
I'm *JUST* saying that documentation and usability (despite their
absolute and invaluable importance) [not even mentioning cosmetic
cleanup] should *NOT* be *showstoppers* for a *FINAL* release.
My simple idea is: let's get the release out and then improve it later
on.
I'm *NOT* advocating: let's get the shit out and let the users dig into
it, we'll move on talking about RTs and more sexy stuff.
I'm simply saying that postponing further the final release for some
showstoppers that should not stopping any open source project, is
hurting more than any addition that we could add.
So, please, let's come up with a *showstopper* list and we'll identify
which one is really stopping the release and what is not and can be
postponed later on.
Thanks.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi Stefano,
a really nice fairy tale...
I totally agree with you, that we should get this release out very soon,
but as the last months when we released the betas and the rcs showed,
there were many new users which very totally frustrated with c2 as they
didn't get it working. And I think 80% of them could have been helped
if the documentation were more complete. OK, they all could use the
mailing lists to get their problems fixed, but the usual user doesn't
want to do so. He will something which simply works. And I really
don't want to say: "Who cares about them?" And I personally don't want to
say: "Hey, it's opensource, so what do you expect?"
We all here know that Cocoon is a great piece of softwarwe, but for
what, if noone except some geeks can use it? Ok, you argue that
all these users will join the developer site and help us. This
might be true. Who knows this?
So, my plan was to get as much documentation as possible and use
this time to sort out some other areas (like the directory structure
etc. in the meantime). Not all of us are capable of writing good
documentation and they can spend their time on the other things.
But of course, you're a right that the directory structure should
not delay the release.
Ok, at least, the gap between our opinion about the final release
date is not that wide.
Let's see how we can make it? What about this? We leave the directory
structure as it is for now and we add any documentation that is currently
in the pipeline. If noone is currently working on documentation,
we will do the release on monday as proposed some month ago.
If there is someone working on it, he should comeup now and say if he
it is worth waiting for it.
Carsten
Stefano Mazzocchi wrote:
>
> Once upon a time,
>
> there was a group of distinguished software engineers (also known as
> 'geeks') who were redesigning a piece of software called "Cocoon".
>
> The geek who started all this was young and even was the technology so
> he made a bunch of design mistakes trying to get it right the first
> time. Other friendly geeks came, showed him the mistakes and worked
> together in peace and harmony to come up with a new version that would
> remove those issues.
>
> Being the second attempt, they called the effort "2.0".
>
> Seasons passed and the productive geeks were crunching lines and lines
> of code and the more noise they were making, the more geeks were
> attracted by this idea of the big "2.0" release.
>
> They knew how painful it was to discover the limitations of the first
> release so, this time, they want to make it *right*.
>
> So, everytime somebody passed by and had to suggest something they found
> important, they kept on saying "oh, this is right, the users will love
> this, let's move this pixel down one spot".
>
> They were trapped in the "2.0 syndrome": an endless loop of postponing
> the release for the fear of having to modify it again in the future.
>
> So they continued to work and work and work and they were producing an
> incredibly valuable software, but their community died because nobody
> could ever see what they were working on.
>
> The end.
>
> - o -
>
> Result: let's get this damn release out, people!
>
> Documentation is not good enough? who cares!
>
> Files are not in their *best* position? we'll move them later.
>
> It seems that everyone around here has gone nuts: in case you didn't
> know, we are *NOT* a software house and the people using our software
> are *used* to open source and "fixme" tokens scattered around.
>
> The *ONLY* thing we should be concerned for a final release is if the
> *contracts* users will build on are *solid* enough to be considered
> final.
>
> *contracts* people, CONTRACTS!
>
> Do you build your software on the location of our files into the
> distribution? well, if you do it, you're nuts.
>
> Do you build your software on the wording of the documentation so that
> if they change you're screwed? no way.
>
> Gosh, where did "release early and often go"? down the drain?
>
> Linus Torvalds invented the concept of open development by making a
> kernel release *each* *day* for months! [of course, he never used CVS so
> he was forced to]
>
> I started Cocoon 2.0 in November 1999.
>
> It took two damn years and we want to move files around few days before
> final release? Are we going insane?
>
> The question is simple: are the code contracts (interfaces, components,
> API, schemas, protocols) solid enough for a final release?
>
> If so, we release *NOW*.
>
> If not, we fix it.
>
> *ANYTHING ELSE* can be added to 2.0.1 or 2.1 (depending on what naming
> scheme we'd like to use)
>
> Moreover: your *elegance taste* might tell you that the better a
> software release is, the more people will use it.
>
> This might be correct (nobody knows).
>
> But, this also creates a big user community but doesn't help the
> development one.
>
> We want people that uses cocoon in order for them to come here and help.
> This is the final goal: the more hands the better.
>
> Is anybody going to help us if they find everything already good and
> perfect in the final release?
>
> I love slightly confused distributions because they force you to come
> back and interact with the community.
>
> This is the way I infected all of you: Cocoon 1.0 should have been
> called Cocoon 0.01alpha but then we would now aim for Cocoon 1.0 today,
> but I'd almost be alone around here.
>
> yes, people, I fooled you with inflated version numbers.
>
> Now, tell me, was I successful in creating this community? well, you
> have to use a couple of tricks.
>
> And believe me, *polishing* a final release lowers the chance of
> building a community around it in open source, unlike common sense seems
> to suggest.
>
> So, guys, even if I totally understand your concerns, let's cut the crap
> and release the damn thing as far as contracts are solid and *build
> dist* works.
>
> We'll polish it down the road.
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org