Jim Hurley wrote:
To that end, I've gone back through the ~200 list messages, and tried to pull out a main list of topics. Would it help to have this on a wiki to help us track?
I have no preference, a simple page with the items and the status would do for me too, but if you think a Wiki is more handy I'm fine.
If ya'll think this (organization) is a good idea -- I'd
Organization is a must, even if we do it a bit wrong the first time. We have mentors that will keep us from screwing up totally I guess.
like to agree on the initial list, where to put it, and how best to attack it. Let me know what you think.
The organizational guidelines (how thin they might be) should be on the River website where people willing to participate can find them. As you can see your/our list is rather large and will likely grow in the future. I think we should pick the most important ones first so people can start doing what they tend to like and that is coding and discussing changes. So I would suggest, get the code and issues in first. Steps required are: 0) policy of how to deal with code changes (as in RIVER-2), also I think your point 5) should be discussed first; 1) setup of JIRA with components and proper permissions for developers, at least to the extend it makes sense; 2) we have a group of people that have actual access to SVN, meaning the ICLA and CCLA are fine and accounts are created; 3) merge ServiceUI and JTSK for the time being so we have one build process, I agree with Bob that separation complicate things. Although I hope this agreement only lasts for a few months ;-) 4) work towards an initial (internal) release that in all aspects compatible with the current JTSK, this means that fixes from Sun internally could get in as well as improvements lingering around the world. This would mean we assign issues to a new version and this allows those willing to participate to pick tasks in a way that is beneficial to the whole community on the short term; 5) setup of test infrastructure to validate the outcome of 4 It is my expectation working towards an initial release takes at least a few months, depending on how much improvements we want in it. This buys us time to sort out the longer term roadmap issues, of which some of them can have a huge impact. If some of the roadmap issues are tackled in an early stage we could even start parallel development, although given the fact SVN has no merge history tracking I'm personally very reluctant to have any significant development going on in what is not the trunk branch. Thanks for picking up the gauntlet Jim! -- Mark
