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.
I'm doing refactoring because I want to release, not the opposite.
Removing dependencies will improve our ability to REaO (Release Early and Often)
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).
Ok, that's good enough.
Also, I would add that we should not put code in HEAD that depends on a unreleased software that *NEVER* made a 1.0 release. This will keep the contracts shaped up.
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?
Moving the SourceFactory to Avalon made a mess. This is what I'm mostly concerned at the moment. What is the status of this?
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.
I asked a vote for this and the lazy consensus was that libraries that depend on *ONE* block will go into the block/lib directory, the libraries shared by blocks will remain in /lib/optional.
Did I overlook something?
Do others believe that I acted on my personal behalf against community decisions?
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
