James Carman wrote: > Suppose we do want to further pursue this (I think we should). How would > you recommend we set up the project? Should we branch commons-collections > off and start doing releases off of the JDK5 branch along side the main > branch?
With a nod to "Rules for Revolutionaries" [1] I think it makes the most sense to branch commons-collections. This should be a lot easier process now that the repository is in subversion. The biggest obstacle to overcome is the lack of interested commons committers to coordinate non-Apache developers, to merge different implementations (there is a second 1.5 collections implementation at collections15.sourceforge.net), and address some of the problem areas in the generic conversion process, e.g. MultiMap. michael [1] http://incubator.apache.org/learn/rules-for-revolutionaries.html > -----Original Message----- > From: Simon Kitching [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 24, 2005 11:12 AM > To: Jakarta Commons Developers List > Subject: Re: Commons-Collections enhanced with Java Generics Support > > On Tue, 2005-05-24 at 16:05 +0200, Thomas Dudziak wrote: > > On 5/24/05, James Carman <[EMAIL PROTECTED]> wrote: > > > Why can't we host this project at ASF? Couldn't we create a new branch > for > > > JDK5 collections or something? > > > > +1, though I'd prefer the simple solution of two jars, one for pre-1.5 > > and one for 1.5 which contains the generics-support (either version or > > add-on jar). This would prevent divergences in future versions as only > > one codebase has to be supported. > > The major reason the project was developed on sourceforge is that the > people who wanted to do the implementation were not commons committers, > and no commons committers had time to manage the project. > > I don't know whether the developers (John/Matt) are even interested in > the project being merged back into apache at the moment. > > But if they were, then in order for it to become a commons project > (including being a branch of the existing collections project) either > some existing commons committers would need to volunteer to commit > patches submitted (including being responsible for the quality, > licensing, and ensuring longterm support etc) or some/all of the > generics project developers would need to be elected as commons > committers. > > But we can't just elect someone as a commons committer without knowing > the quality of their work or their ability to work well within commons > (esp. having plenty of patience ;-). I think it very likely that > Matt/John would be fine additions to the commons team, but we just don't > know them yet (at least I don't). If someone had the time to check the > collections.sf.net project mail list and review the existing code > thoroughly this might be enough to give a +1 on this issue. Or if they > have a track record with some other large open-source project. Otherwise > the project really needs a few commons committers to work with them for > a month or two until we can feel comfortable about electing them. > > There is also the question of how large the generic collections > community will be. There aren't yet a whole lot of projects coding to > 1.5 as far as I know. That would mean that it might be hard to ensure a > pool of interested developers for this project that would continue > maintenance. And that would be bad - commons doesn't need any more > zombie projects than it already has. Then again I may be wrong; there > might be huge demand for this. Or Matt/John may be enthusiastic enough > to provide maintenance over the next year or two until java 1.5 becomes > more prevalent. Checking the sf project forums should provide some > evidence of whether there is a solid user community for this project or > not. Certainly a pool of only two developers is a little fragile for > long-term support if there is only a small user pool to draw new > developers from. > > Note that I'm not saying it's impossible to bring this project into > commons if Matt/John want to. And I certainly don't mean any offence to > Matt/John, who have clearly put a lot of effort into writing code that > is available for free and are therefore "good guys" by any definition. > But these are issues that need to be addressed before adopting this code > into commons. > > In the meantime, though, I see no harm in making sure we have plenty of > references from commons to the collections.sf.net project (see, there's > one!) from the commons site, wiki, etc. We can make sure people who > might visit commons-collections are made aware of the generics version > and then those people can make up their own minds about which code base > they want to use. That's just being friendly and helpful. > > And there's nothing *wrong* with projects on sourceforge anyway. > > If you want to address some of these issues and push for generic > collections in commons then go ahead and put a case that addresses the > above issues. > > > Regards, > > Simon > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
