On Mon, 11 Jul 2005, Felipe Leme wrote:
[X] +1 - merge Jakarta Taglibs Project into this new project
[ ] -1 - no, let's keep Jakarta Taglibs Project as is
[ ] -1 - let's wait the new project be officially created/incubated
[ ] +0 - whatever
[ ] ?? - <<put your comment here>>
[X] +1 let's create a new [Jakarta sub-]project for these taglibs
[ ] -1 please, leave it with us wherever we go
[ ] -0 dude, the +1 didn't win the first vote, so we are not merging
[ ] ?? - <<put your comment here>>
2.1 [ ] migrate all of them
2.2 [X] leave them behind (on a read-only SVN access, with the latest
releases, etc..) and let's create new ones from scratch - that would give us
a chance to refactor the existing code.
2.3 [ ] it's too early to decide that
2.? [ ] <<put your comment here>>
[ ] +1 release a final version for each existing taglib (and a 1.0 for those
never released) before "closing the doors"
[X] -1 no, leave them as is - we better do the new releases in the new
projects
[ ] ?? - explain why
The problem I have with doing "final" releases before moving them is that
such releases would be entirely artificial. There may not be any coherent
set of functionality to define such a release. Worse, creating a release
for taglibs that have not been released before sets a precedent, and nails
down an API we might not want to keep. Finally, it involves work for not
good reason.
Nothing will be lost in moving from Taglibs to the new project, since it
will almost certainly be accomplished via an 'svn move', so I see no good
reason to insert this artificial step into the process.
--
Martin Cooper
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
