Stefano Mazzocchi wrote: > > There are a few things that we are doing wrong. I'll make a dump of my > random thoughts about these in order to foster a discussion. > Ah, it's time again to write an email that is larger than four lines. Hmpf. Now, I think the problems you mention have all the same source that I discribed in two emails last year (about our community being healthy), but until today noone even commented my emails. So, it will be interesting to see what this RT will do. I would like to a add one more point: Most of us do not care about releasing new versions. We *must* come back to release often - release early. But each time, we try to get a new version out, someone comes up and says: Wait XYZ is not finished/working/discussed right now, we should first get this working. Or even worse, someone starts something and leaves it in an uncompleted state, so others have to clean it up.
Now, to your points: > | never commit code that depends on non-released stuff | > I really would agree to this policy, if it is possible to follow. Now, in theory that sounds really great and easy, but in practice it's near to impossible. Think of the problems for example we had months/years ago with severe bugs in Xalan or Xerces. We had to use the latest CVS in order to get Cocoon running as the released stuff was not working. And what does released mean? One could argue that an alpha version is a released version ;) I would like to relax the policy a little bit to: Never release a stable version that depends on non-released stuff (where released version has to be at least stable in API). > Another example: the Source stuff moved to Avalon. > > Is it possible that things are marked as *deprecated* and even Cocoon > itself depends on deprecated stuff? sand on sand. > This is of course not optimal, but IMHO unavoidable - we (and others as well) make sometimes mistakes in the design or concepts that have to be cleaned-up in order to not create a mess. So, things have to be deprecated and replaced by newer/cleaner solutions. As far as I know, Cocoon does not depend on deprecated stuff. There are only some classes in the core that are now deprecated. Or am I wrong? > Huge library dependance > ----------------------- > It would be easy that Cocoon by itself depends only on some libraries, but these libraries rely on others etc. So it's, again in practice, near to impossible to remove the reference to two or three xpath or logging apis unless you can achieve that all other projects use the avalon (or log4j or...) etc. Months ago we agreed/voted that we put *all* jars in the main lib directory and do not have separate lib directories for each block. This was agreed on because if two blocks require the same jar, this jar would be otherwise two times in our repo. Now, some days ago someone changed this... So, actually this is another point, sometimes even if we as a community agree on something - someone does not know/care about this decission and is doing what he things is best. And now back to bug-fixing... Carsten
