On Sunday, Sep 21, 2003, at 12:39 Europe/Rome, Upayavira wrote:
Steven Noels wrote:
Joerg Heinicke wrote:
IMO this is difficult to maintain. If someone wants to look on the code base of a block he has to search for its dependencies first or search for the code at different places. Can't we extract the blocks from 2.1 "as they are" at the moment and move them to cocoon-blocks module, so that they are collected at one place.
I like this: +1
+1 I like this too. Minimal changes to 2.1 to make it work with the new blocks repository, and we can then get on with 2.2 core.
to be clear: I'm not against this, but only after people realize the problems that might come up and we come up with consensus on how we are going to deal with those problems *when* they come up
Not if, because you can bet that over-blockization is going to happen... or, at least, asked for.
As it is today, blocks are not only modular packages to extend cocoon (as fop and batik, for example, who triggered the creation of the fake block system), but also a way to propose new stuff as one-man-shows.
I fear one-man-shows.
May I guess where this fear comes from... Avalon? ;-)
I have the same fear.
At the same time, we need 'sort-of incubation' practices for blocks, as it is impractical to think that a cocoon committer would develop his/her code outside and submit it only when there is a community around a block.
Yes, I agree.
This is why I had proposed to keep scratchpad blocks in the scratchpad and not mix them with released ones. This makes one-man shows easier to do and more difficult to manage.
the block system will work effectively *ONLY* if there is strong cross-pollination between blocks and if the cocoon community keeps strong oversight over what happens.
this hasn't been so for many blocks so far and I see this as a potential problem.
It's just the beginning. I would suggest to:
1) keep the voting system and responsibility over blocks as now, that is
open to all Cocoon committers
2) make a scratchpad-incubaton-callitwhatyouwant directory or even
better CVS module where alpha blocks or features are done
3) partition commit acces like this:
1) only core cocoon committers can commit to the core
2) all committers have access to Lenya, Forrest and Blocks
(when/is Forrest going to actually move?)--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------