jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul P Akolkar <akol...@us.ibm.com>
Subject Re: [VOTE] Future of the Jakarta Taglibs Project
Date Fri, 15 Jul 2005 20:29:15 GMT
> [ ] +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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message