> [ ] +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 > [X] +0 - whatever > [ ] ?? - <<put your comment here>> <snip/>
Since whatever doesn't quite sum up my sentiment here, some clarification: I'm sold on the virtues of the proposal, most importantly a larger, more active community. I also believe the devil is in the details, which are mostly murky at this point. I would like to advocate that in order to reap the proposed benefits and gain increased visibility, each taglib that we decide to migrate retain a sub-project status within the new/proposed project (AFAIK, this has not been discussed yet). In this context, I would like to point to Sam's note about flatter hierarchies here [ http://marc.theaimsgroup.com/?l=taglibs-dev&m=111961163907548&w=2 ]. For this vote, in particular, I also think it is quite appropriate to expect some votes to be recast as more details come through. > In case the +1s win, we have do decide some issues, such as: > > [X] +1 let's create a new project for these taglibs <snap/> > 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. <snip/> +1 to migrating only the active taglibs. Does anyone want to take a stab at defining "active"? Is this going to be based on some objective criteria? I'm equally happy to take the word of the relevant committers for each taglib. Finally, while this is a good chance to refactor, some taglibs might be content with just a svn move (or copy). > 2.2.1 Last releases > [X] -1 no, leave them as is - we better do the new releases in the new > projects <snap/> Agree with Martin on the artifical nature of such releases [ http://marc.theaimsgroup.com/?l=taglibs-dev&m=112110599514947&w=2 ]. And, I'll take a stab at the rest too: > 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, <snip/> IMO, it would be ironic not to. > what to do with the taglibs that are overlapped by JSTL, <snap/> We might have to think about this further if one or more of the taglibs deemed redundant are also deemed active. > should we > change the way the documentation and TLDs are generated, etc <snip/> Did you have any specific changes / improvements in mind? -Rahul
