Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date
Date: Mon, 26 Nov 2001 10:06:52 +0100
Message-ID: <GMEBIBHGAOFGJCDPJANDCEPDDCAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3BFF8D40.C35362E4@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"


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.
> <stefano@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