On 6/3/07, Mark Brouwer <[EMAIL PROTECTED]> wrote:
I started a new thread for I was under the impression it was policy not to have discussions on a vote thread as it complicates tallying.
Absolutely, thanks for this.
I agree with the recollection of John. It would be good if those with a more in depth knowledge of the rules here could explain the possibilities with regard to releasing in the com.sun.jini namespace.
Best thing to do is bringing this on the general incubator list once we have a set of clear questions to ask and one or two possibilities ahead.
The comparison with Wicket came up, and although I don't think it was the intention of Gianugo to compare River with Wicket I believe Wicket is a complete different project.
Absolutely agreed. On the other hand, consider how they were all in all namespace neutral (they were using wicket.*).
It is my expectation that River will be much longer in Incubation due to the fact this was a completely Sun driven effort in terms of coding. Although estimations are hard to give I won't be surprised as it would be in line with a project such as Derby.
Agreed, that's likely to happen.
For me moving to org.apache.river in the first releases (if these have to be soon) while having no sight of a graduation is something I consider a bridge too far.
I see your point, and I understand how backward compatibility matters. On the other hand, my main issue is about branding, which has to deal with diversity as well. More specifically: a) from a branding perspective, it should be clear to users that this is Apache River, not Sun's Jini (or possibly the Apache implementation of Sun's Jini specs). This is a clear Incubator requirement. b) I believe that diversity builds mainly upon neutrality: it's harder to find people willing to work on com.sun.* (think competitors), as they'd feel they'll be working on Sun stuff, not ASF's. c) while I can see your point in changing packages as jumping the cliff, sometimes you just have to burn your boats. Yes, River might fail incubation, which would mean a mess to the Jini community. On the other hand, playing safe with package names might be a sign of missing commitment to the community.
Not only do I have a lot of patches in the com.sun.jini namespace that needs to be integrated,
I assume this can be easily done once code lands in SVN?
I also have a lot of derivative work based on the com.sun.jini namespace that is in production at places and that needs ongoing support.
Good point, but there is a clear trade-off with branding and community building. I'm sure there is a sweet spot somewhere which might be satisfactory. Maybe a compatibility package (no idea whether it's feasible at all) that bridges/proxies com.sun.* to org.apache.*? Or some other idea we could come up with.
For me switching is something I really would like to postpone until the larger outlines for this project are clear, e.g. are we going to make incompatible API changes in the com.sun.jini API, etc.
I see your point, and I fundamentally agree. All I'm asking is that package renaming sits somewhere high in the priority list.
Personally I have no problem with no official release in com.sun.jini and let people build one from SVN themselves [1] and postpone an official release in the org.apache.river namespace if we have some signs we are heading the right way, but I believe others do. [1] I realize this comes to the expense of user satisfaction, but I also believe this way they become a little bit more involved and get a bit more understanding of the project. As I believe incubation is also meant for building a developer community I don't consider this 'bad'. A proper explanation near the download section will do fine I guess.
Yes, that could be an option. Ciao, -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
