Whatever is done, get it on the roadmap. Get a 12 month roadmap. Start acting like a project that has a chance at making it as a poddling.
Get the code and if you don't this week, can you please explain why specifically? For those of us not in the inner circle Apache River seems to be going nowhere. I'm sure there are good reasons, but you have been saying for 2 months that you are going to have the code "any day now". It is encouraging to see some life here. We did a POC of Jini/JavaSpaces and love the tech, but put adoption (further work) on hold because River looked dead (and thus we figured that was the end of Jini/JavaSpaces). Not trying to be harsh, but as someone new to Jini/JavaSpaces (who loves the tech) it has been very disappointing to watch River so far. Just get the roadmap and hit a few singles. I liked the .1 release idea. I guess it depends if River is maintenance for Jini/JavaSpaces or if you want to grow the community. If it is the later, hit some singles and get some credibility and then swing for the fences. Mike -----Original Message----- From: Calum Shaw-Mackay [mailto:[EMAIL PROTECTED] Sent: Monday, May 21, 2007 4:03 PM To: [email protected] Subject: Re: Short term plan forward... (proposal) Just as a further note for discussion, I believe we should be engaging the community now about the next iteration of the specs (i.e. things like Executor extension for Javaspaces, et al, XA transaction manager, etc) and what wants to be seen in the next iteration of the core services (Nested Transaction Manager implementation for example), so that from that area, things can be seen to be progressing. Just a thought --Calum On 21/05/07, Mark Brouwer <[EMAIL PROTECTED]> wrote: > Jim Hurley wrote: > > Hi all- > > > > Just wanted to propose a short term conceptual plan forward for > > Apache River, and see if we're in sync. > > Thanks for starting this Jim. Below some of my initial thoughts on > your ideas. > > > Once we get the source accepted and contributed to the project > > (hopefully this week!)... I'd like to propose that we immediately > > start working on a release (v0.1). This will not only help us > > understand the paces of getting a release out through Apache, but > > also provide a release to the Community from Apache. To focus on > > getting a release out, the initial work would be targeted at > > integration stuff (for example, getting Service UI > > integrated) and some documentation rather than on very many bug > > fixes or rfes. > > > > Once we accomplish that, we can turn our focus towards another near > > term release (v0.2) which could include additional bug fixes and > > smaller rfes as well as any cleanup we learn from getting the v0.1 > > release out. This would not only provide an added value release out > > to the Community, but also give us further experience and additional > > momentum of an active project moving forward. > > I find v0.1 not ambitious enough. I think it is important to do some > bug-fixes and RFEs that have been completed and lingering around for a > very long time in some peoples workspaces. Just to release so most > people can sit on the sideline watching v0.1 being released is not > that interesting to me (I also want to get rid of a lot of fixes and > small RFEs I've been carrying for too long). Therefore I'm inclined to > merge the goals for v0.1 and v0.2 as most of it likely represents > completed work. Based on what is in Bugtraq, has been added to River > and is completed in the Sun internal version control system we can > make a selection of what to put into that first release. Whether there > is still a need for a release between the first release and the 'meat to it' > release I find hard to say at this point. > > With regard to the version numbering you used. The version numbering > between the Jini Specifications and the JTSK has been correlated to an > unhealthy degree IMHO and I think starting from zero isn't the best we > can do as likely the first releases will be something that resembles > the JTSK from Apache instead of from Sun. As long as we don't have a > clear (as perceived by our audience) separation between the specs and > the implementation/starter kit I would suggest starting at 2.2. > > The more 'meat to it' specification release could become 3.0 and > whatever products/deliverables we end up with could start using a > version number that does justice to it. > > > At that point, I think we'd be seasoned enough to focus on a release > > with some 'meat to it' ;-) (some of the more major bug fixes/rfes > > that have been discussed). > > Agreed. > > > Running in parallel to this development focus, I think there should > > be some longer range project discussions (what kind of releases do > > we eventually want to do in the project, what are we trying to > > accomplish (iterating on the core infrastructure or branching out > > into other areas), etc). > > Agreed. > > > ps. On a specific item - not sure where a package name > > (to org.apache) change would fit in this proposal. Maybe > > release v0.2 or after? > > As far as I'm concerned after v0.2. This won't be a trivial change and > probably something we should do while we try to get the question > answered about maintaining compatibility, not something for the v0.2 > to be tackled I guess. Or in other word, if we pursue a change with > major impact I think it is also the best opportunity to make some > changes that could lead to (minor) incompatibility and that will > require a significant window in which to sort that out. > > Another thing that should be discussed is the minimum J2SE version we > are going to conform us to for these initial releases. For v0.1/0.2 I > would say we should stick to J2SE 1.4 and for the 'meat to it' release > we should start the discussion about moving to 5.0. > -- > Mark >
