cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gerhard Froehlich" <>
Subject Re: [docs] opensource and quality control
Date Wed, 15 May 2002 10:00:49 GMT


>I think that we already have this. It is the duty of the
>committer to undertake initial quality control when they
>accept the patch from Bugzilla and prepare for their
>commit. If they do not know anything about the topic, then
>they should not be taking on the patch - let someone else
>do it.

Who is someone else? Patches in bugzilla are very lonely in
the moment. There are simply not applied. Why? Because there
about 600 classes in Cocoon, about 10 active committers and
nobody feels responsible. It's easy to say, oh I didn't
wrote this code, therefor I can't apply this patch. But
patches like NPE fixes, can be applied by every committer, I

IMO it's very bad for the community process, when interested
developers are sending patches to Cocoon and they aren't
(re-viewed and) applied, because nobody feels responsible. I
would loose the interest to participate, when nobody cares
about my suggestions. It doesn't matter how tiny and simple
the patch is. Somebody spend some time -often in free time
after work- and it's our reponsibility to appreciate this!

Just apply them, when the code is unstable, there will be a
patch. That's how OSS develops software. We have the luck to
do develop software not under time/deadline pressure. Ok the
code will be unstable for some weeks, but it's a good
motivation to make it better ;-).

>There will certainly be occasions where a single committer
>does not have the expertise to do a review. For these cases
>we should have a Draft documentation directory under the
>normal src/documentation/xdocs/ (... we already have a
>drafts/ directory but it is not linked in). However, for
>this to work, we would need to have the website updated far
>more often than what currently happens.

True and under the current size and the fluctuation of
active developers in Cocoon, this will be the normal
process. Why as xdoc? We have this mailing list. Just mail
your concerns about the applied patches and make a note
-with a short description- in changes.xml.

People I have the feeling that you try to install many
bureaucratic processes in Cocoon. Why, when I want
bureaucracy then I go to the tax office or somewhere else.
Over bureaucracy always destroys creativ and chaotic
processes, like OSS development. Please remember the
cathdreal and the bazaar. We are the bazarr and NOT the

>After the initial commit, then a notice should be sent to
>cocoon-dev to give a chance for review before release. If
>there are no comments or fixes, then too bad - it all just
>gets released with the authors fixme notes embedded. The
>other alternative is to try to set up an area in the CVS
>scratchpad to hold any documents with obvious problems.
>However, it seems hard to configure the build procedures
>for the scratchpad so that "build docs" can prepare them
>too. There is a tendency for stuff to languish in the
>scratchpad and never see light, so we would probably just
>have a different issue. Also, the scratchpad docs would not
>get published to the website, so no opportunity for review
>by a wider audience.

No not in the scratchpad. There they will be forgotten,
believe me.


Gerhard Fröhlich
IBM Account Austria - 00/627
BIS e-business integration services
IBM Austria / Vienna
A-1020 Vienna, Obere Donaustrasse 95
Tel: ++43 1 21145 4818
Fax: ++43 1 21145 4191

To unsubscribe, e-mail:
For additional commands, email:

View raw message