[ X] +1 - merge Jakarta Taglibs Project into this new project
[X ] +1 let's create a new project for these taglibs
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
[X ] +1 release a final version for each existing taglib (and a 1.0
for those never released) before "closing the doors"
If there are any changes to the taglibs since the last release then we
should do one final release before "closing the doors". If we don't do
so then these updates may be lost. We should also do the 1.0 release
for unreleased taglibs since that will allow us to use that release as
a basis from when the migration to the new project occurred.
I agree with Henri about moving only the active projects at first. That
way we would make sure that we have the community support for those
projects. We can then move other taglibs on an interest and support
basis.
Thanks,
Justyna
On Jul 10, 2005, at 8:01 PM, Felipe Leme wrote:
Hi all,
As you know, there's been a proposal on [EMAIL PROTECTED] to create a
Jakarta sub-project (whose name haven't been decided yet) to provide
web-related Java components (such as filters, servlets and taglibs).
Given the current status of the Jakarta Taglibs Project - where there
isn't much going on by the committers, most of the activities are
JSTL-related user questions or issues with the sandbox taglibs - it
has been also discussed if the Taglibs project should be merged with
this new project.
So, I'd like to officially call that vote:
[ ] +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>>
In case the +1s win, we have do decide some issues, such as:
1.Jakarta Standard Taglibs should be a project of its own, given the
fact that it produces standard, JCP-compliant taglibs and as such have
peculiar characteristics.
[ ] +1 let's create a new 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.What about the other taglibs? Should we migrate them as is to the
new project or should we leave them behind and create new taglibs from
scratch (reusing existing code, of course)?
2.1 [ ] migrate all of them
2.2 [ ] 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>>
If 2.1 wins, I guess we can just move the SVN code to the new project
(once it's created) and evolve from there. But if 2.2 wins, we still
have at least one more issue to decide (I hope that won't be a bias
for people to vote on 2.1 :-):
2.2.1 Last releases
[ ] +1 release a final version for each existing taglib (and a 1.0 for
those never released) before "closing the doors"
[ ] -1 no, leave them as is - we better do the new releases in the new
projects
[ ] ?? - explain why
Finally, there are other issues that we will need to handle after the
merge (*if* we merge), such as if the committers will be 'migrated' as
well, what to do with the taglibs that are overlapped by JSTL, should
we change the way the documentation and TLDs are generated, etc - but
let's focus on the issues above for now.
-- Felipe
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
