cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: on better release and version management
Date Tue, 23 Sep 2003 14:31:26 GMT

On Tuesday, Sep 23, 2003, at 14:46 Europe/Rome, Bertrand Delacretaz 
wrote:

> Le Mardi, 23 sep 2003, à 14:33 Europe/Zurich, Nicola Ken Barozzi a 
> écrit :
>
>> Bertrand Delacretaz wrote:
>>
>>> Le Mardi, 23 sep 2003, à 14:26 Europe/Zurich, Nicola Ken Barozzi a 
>>> écrit :
>>>> ...And maybe also use a low-tech way of adding a 
>>>> WARNING_BETA_BLOCK.txt or WARNING_SCRATCHPAD_BLOCK.txt file in the 
>>>> block source dir to make it clear to CVS browsers and coders of the 
>>>> status of the code.
>>> Or rather an XML block description file?
>>> The upcoming block descriptor could include meta-information 
>>> relating to the block's "stamping" status.
>>
>> The problem I see with having only a descriptor is that one hat to 
>> open the file to see the status, and few will do, as the current 
>> situation shows.
>>
>> That's why a file with a descriptive name can initially alert users 
>> better...
>
> Why not, I see your point.
>
> But I also think blocks "quality descriptors" need to move beyond just 
> "marked alpha", to more precise descriptions of how 
> mature/usable/certified a block is.
>
> This info should also be used by the block deployer for warnings when 
> installing non-certified, alpha or unstable blocks.

Say we had a rating system like this:

  1) Development status:
   a) design
   b) under operation
   c) maintainance

  2) API status:
   a) unstable
   b) stable

  3) Community level:
   a) open individual effort
   b) open plural effort from same affiliation
   c) open diverse community
   d) closed effort

Now, for example, you want to deploy

   http://mycompany.com/blocks/myblock/1.0

in your system. This block depends on the block behavior

   http://apache.org/cocoon/block/pdf/1.2

so, after you have deployed your block, the block deployer will ask the 
block librarian:

Request:
   who implements http://apache.org/cocoon/block/pdf/1.2?

Response:
a) http://apache.org/cocoon/block/FOP/2.3.343
     implements http://apache.org/cocoon/block/pdf/1.4
     has rating [1c,2b,3c]

b) http://apache.org/cocoon/block/FOP/3.0.24
     implements http://apache.org/cocoon/block/pdf/1.12
     has rating [1b,2b,3a]

c) http://apache.org/cocoon/block/iText/1.0.3
     implements http://apache.org/cocoon/block/pdf/1.3
     has rating [1c,2b,3b]

and prompts the user for a choice.

                                 - o -

The system I outlined above seems really nice, but, IMO, has a few 
serious drawbacks:

  1) it requires a central authorithy of certification
  2) it creates an incredible amount of friction

If we use http: block-id URI, the block librarian will, probably, be 
connected to the URI used as a URL to localize a service that provides:

  1) description of what that behavior does
  2) list of available implementations of that behavior

This means that if the behavior is 
http://mycompany.com/block/whatever/1.0, we don't have control (nor 
should!) on what they say. It is entirely possible that they pretend 
that they have blocks which are developped by a diverse community when 
they do not.... and, if questioned, they would simply say that "diverse 
community" doesn't have an objective meaning and they used their own.

But such quality metering would disturb even here: there are situations 
(even today on our current blocks!) where the "diversity" of the 
community around a single block is not so easy to measure and might 
very well be considered "marketing" by some people that are investing 
in the blocks... thus creating friction between blocks that perform 
similar implementations.

                                  - o -

I propose a much simpler scheme. A block can be:

  1) certified
  2) not certified

A certified block is said to be guaranteed by the certifier (not only 
the Apache Cocoon project, but any organization willing to certify 
their blocks) that this block is usable in production and will be 
maintained in the future.

In short, it's safe.

NOTE: this certification process does *NOT* imply that not-certified 
blocks are unsafe and might contain viral code or spyware. not at all. 
the block deployment mechanism will do a signature verification with 
the block librarian even for uncertified blocks. certification is meant 
to guarantee the "backup" of a community or company behind the block.

So, the new librarian response would be

Request:
   who implements http://apache.org/cocoon/block/pdf/1.2?

Response:
a) http://apache.org/cocoon/block/FOP/2.3.343
     implements http://apache.org/cocoon/block/pdf/1.4
     certified by: Apache Cocoon

b) http://apache.org/cocoon/block/FOP/3.0.24
     implements http://apache.org/cocoon/block/pdf/1.12

c) http://apache.org/cocoon/block/iText/1.0.3
     implements http://apache.org/cocoon/block/pdf/1.3
     certified by: Apache Cocoon

NOTE: if a block is not maintained anymore, the librarian should not 
list it up front.

This allows other entities to do certification (and this would mean 
that *they* provide support and community/company backup of future 
development) [if they lie, well, users will know and news will spread], 
but, more important, it will require a single 'all encompassing' vote 
from the community which would be: "are we ready to support this from 
now on?"

Which, IMO, is a much easier question to ask than a myriad of small 
non-objective questions like the above.

Thoughts?

--
Stefano.


Mime
View raw message