Stephan Michels wrote:
On Thu, 17 Jul 2003, Joerg Heinicke wrote:
Reinhard Pötz wrote:
As I have been confused by all those suggestions you can find a summary here: http://wiki.cocoondev.org/Wiki.jsp?page=FlowSitemapIntegration
Cool summary, really helps a lot. And here the cool voting matrix :)
| A | B | C | D | E | ----|-------|-------|-------|-------|-------| | | | | | | V1 | -1 | +0 | +0 | +.5 | +1 | | | | | | | V2 | +1 | -1 | -0 | +.5 | -1 | | | | | | | V3 | ?? | +.5 | -1 | \ | \ | | | | | | | V4 | \ | -1 | -0 | \ | \ | | | | | | | V5 | \ | +1 | +.5 | \ | \ | | | | | | | V6 | \ | \ | -1 | \ | \ | | | | | | | V7 | \ | \ | +1 | \ | \ | | | | | | | ----|-------|-------|-------|-------|-------|
What is the difference between A V1 and A V2? Only the <map:flows/>? And what does it mean?
B V5 was missing. From Marc's answer I guess he meant this, but chooses V1.
Don't you think that this makes the voting really difficult ;-)
I think the roundup and visualization really helps
it's just that the voting _is_ complex since there have been a lot of arguments on the table
the alternative would be to go into the meta-level of discussing which arguments are valid and which not (hardly easier since a lot of this is personal perception and not to be black/white or true/false)
A: V1 B: V2 C: V1 with flow instead of type
D: V2 E: V2
BTW, I think it too early to vote on this. If I must decide now, all will be carved in stone. I think we should leave A-C as it is for 2.1. And postpone the discussion to the post-2.1-era. For my part, I must have first two implementations to find more generalized contract, which we don't have at this point.
So my vote would like: Should we postpone the generalisation to the post-2.1-era, and hazard with the consequences, that we maybe change the sitemap syntax of a released version of Cocoon?
+1
I partially agree:
- refactoring and continuous design is the reality of this world: pretending to 'carve in stone' is close to telling lies
- the stress on getting the abstract level right without the insight of enough detail in the multiple implementations feels unnatural (given that refactoring has become so easy)
But I also see the other side of things:
- refactoring and change can be a give to those that know the internals and live by the laws of cvs-head, the same level of flexibility eagerness might not be found in settings where upgrading to the latest stable cocoon release is something that is scheduled at best once a year
- it might be a challenge to abstract things upfront, but brave man like us do not fear challenges ;-)
So maybe the consensus getting us into beta stage can maybe be reached by splitting up
- vote on A-C now, carve in 'sand-stone': these are related to non-coding end-users of flow, transition from one to the other costs more
- decide on D-E _for_ now, carve in 'yoghurt': this is related to developer decisions, dependent developers would probably less mind if changes occur, their refactoring IDE's would help them out a great deal...
in both cases we (must realize that we) are making a best estimate on what we know now, that is just how life is...
the remaining argument to actually decide here and now is it gets us out of the catch-22: it enables more nicely the alternative implementations that will get us the deeper insight we're missing to date
what do others think?
(I might be missing the complete point of release management here, I don't mind if someone points that out to me)
Stephan.
-marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
