Bertrand Delacretaz wrote:
Le 16 mars 05, à 09:29, Reinhard Poetz a écrit :

...Remains the question: What shall we do with and call "unsupported/unverified" blocks?...


Why not put them in a "contributed" area? We'd make no guarantees about them (not even that they compile), and over time they might move elsewhere or be abandoned. More or less like the scratchpad of today.

The initial move would be to put as many blocks there as possible, and maybe move them back to "higher ground" later if there is actual support for them in the community.

My second search was more successful and I found http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106443770412993&w=2 which already contains an excellent proposal by Stefano:


              +------------------(rebirth)-----------------+
              v                                            |
-(birth)-> [contributed] ----------(death)---------> [deprecated]
              |                                            ^
              +--(maturity)-> [supported] --(retirement)---+



So we have following lifecycle states:

 - contributed
 - supported
 - deprecated

blocks.

The "verified" status could be orthogonal to these lifecycle-states and is an indicator of a (to be definded) block's quality (tested, stable interfaces, stable implementation, supported by community, ...)


Addtionally I like Betrands idea (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106447275008760&w=2) of a narrative status description:


"Yes - and maybe we shouldn't impose too much structure on this weather
report, just require that block providers have one "block status"
documentation page, where they tell people about contract stability,
API stability, future plans, active contributors and the like."

I think we should provide some structure by providing a template that has some mandatory parts and a free text part.

                             - o -

I propose to reflect these lifecycle-states in our SVN directory structure. Additionally we should add the directories "samples" and "core".

/cocoon/blocks/contributed
/cocoon/blocks/supported
/cocoon/blocks/deprecated
/cocoon/blocks/core
/cocoon/blocks/samples

Remains the question, where do "mini-apps" like the querybean fit in? In contrary to sample-blocks they have a lifecycle IMO. I'm not sure whether a distinction between "functional blocks" and "mini-apps" on SVN directory level really makes sense. For now I propose to put mini-apps into "contributed", "supported" or "deprecated" and if we get swamped with "mini-apps" we can find another solution if it is necessary.

WDOT?

--
Reinhard Pötz Independant Consultant, Trainer & (IT)-Coach


{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                       web(log): http://www.poetz.cc
--------------------------------------------------------------------

Reply via email to