Gerhard Froehlich wrote: > > 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! > Yes, definitly!
<OT> Are it really 600 classes? Wow, I just heard someone who claims himself to be a Cocoon expert say, Cocoon consists of only a few classes, most work is done with stylesheets! Believe me, at that moment I was totally shocked and wondered what we all have done in the last month.... So, now after hearing this number I begin to get back my faith in the work we all done in the last months. </OT> > 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! > +1 > 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 ;-). > I agree, if this is a bugfix, but I don't agree if the patch adds new functionality. Does someone of you remember the early days of Cocoon 2 back in summer of 2000? There were weeks where anything did work; the sitemap didn't compile, XSP wasn't working etc. And actually as Cocoon was in alpha state this wasn't really a problem. There came a lot of patches in fixing something here and there and finally after some days everything worked again as most patches were applied immediatly. The developers were flooded with patches and didn't have time to do the real work because of looking at the patches. Which lead them to propose some of the "heavy patchers" to become Cocoon committers... > >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/> > Nice comparison: tax office :) > >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. > -1 for scratchpad Without really wanting to repeat myself: I still advice to take one single and simple step at a time. The first approach must not be the best. It can be adjusted and adjusted and adjusted until it works perfectly. Carsten Carsten Ziegeler S&N AG, Germany - Open Source Group ================================================================== mailto:[EMAIL PROTECTED] http://www.s-und-n.de ================================================================== The Cocoon Book: http://www.amazon.com/exec/obidos/ASIN/0735712352/apachecocoona-20 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
