Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Date: Thu, 25 Sep 2003 08:51:29 +0200
Subject: Re: Block Management [was Re: on better release and version
 management]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v552)
From: Bertrand Delacretaz <bdelacretaz@codeconsult.ch>
To: dev@cocoon.apache.org
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <33991CEC-EED3-11D7-AD24-000393D2CB02@apache.org>
Message-Id: <B0D78A53-EF24-11D7-8212-000393CFE402@codeconsult.ch>

Le Mercredi, 24 sep 2003, =E0 23:08 Europe/Zurich, Stefano Mazzocchi a=20=

=E9crit :
> On Wednesday, Sep 24, 2003, at 20:34 Europe/Rome, Timothy Larson =
wrote:

<lots-of-snips cause=3D"agree"/>

> The above suggests one simple, but really important thing:
>
> the block 'health' metadata should *NOT* be included in the block, but=20=

> should be looked up from a centralized 'weather reporter' part of the=20=

> block librarian.

Yes - and maybe we shouldn't impose too much structure on this weather=20=

report, just require that block providers have one "block status"=20
documentation page, where they tell people about contract stability,=20
API stability, future plans, active contributors and the like.

If this is somewhat narrative rather than checkboxes, users should be=20
able to get a feel of how seriously the block authors take their work,=20=

and not finding the expected info will be a sufficiently bad sign.

> ...The best way to judge is to make a vote.
>
> And the vote should not, in any circumstance, make the block being=20
> voted bad if the vote doesn't pass.
>
> So, the answer to
>
>  3) is the community healthy?
>
> is misposed. I would like to have somethign a little less judging:=20
> something like
>
>  3) is the cocoon community officially supporting this block?

Agreed.

> The risk is to come up with something which is not really meaningful.=20=

> Because "official support" doesn't really mean anything.

Agreed as well. I still like "supported", meaning that the community=20
cares for a particular component.

Many projects use also "contributed" to mean that a piece of software=20
is distributed along with the main code but comes from outside.

How about "supported", "contributed", "experimental" and "deprecated"=20
blocks?

Here are some suggested examples with blocks that I know (more or less)=20=

about:

"supported":
Considered part of the "mainstream use" of Cocoon and supported as=20
such, documented, tested before each release: axis, batik, chaperon,=20
cron, databases, fop, hsqldb, html, itext, jfor, lucene, mail, portal,=20=

velocity, woody

"contributed":
Either one-man shows, outside contributions with no broad community=20
support or samples with no additional functionality: deli, midi, qdox,=20=

linotype, petstore

"experimental":
Either wild experiments, or use experimental technologies, or waiting=20
for feedback: slop,stx,eventcache,scratchpad,asciiart

"deprecated":
Not recommended for new projects, support will likely go away: xmlform

Please don't flame on particular classifications at this point, I'm=20
just trying to get the idea across ;-)

-Bertrand=