Hi,
>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 swear! 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 cathdreal. <http://www.tuxedo.org/~esr/writings/cathedral-bazaar/> >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. Greets Gerhard ------------------------------------------------------------------ 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 e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
