2010/9/1 Patricia Shanahan <[email protected]> > Peter Firmstone wrote: > >> Well I must say the recent participation is very encouraging, this project >> had a record number of emails to the development mailing list last month, >> but I don't come from a Programming background, I'm not an expert and don't >> have any merging experience. >> > > Regardless of whether you have formal programming education, you seem to me > to be a very talented and capable programmer. Organization of complex > multi-person software projects is a different subject. > > It requires quite some programming knowledge and experience to take on the things you have ... Jini technology has a very steep learning curve. I've been dealing with it on and off over the last 10 years and there are still many areas I do not completely understand. However, digging in the code is the best way to learn, as you've shown. This is actually a good example that someone with the right mindset, dedication and common sense can become a River developer (hint to anybody on this list hesitant to contribute ..). The ideas you are working on are certainly interesting, so I would encourage you to continue them!
> Checking everything directly into the trunk works well on a reasonably > small single person project, but I do not think it is a good plan for River > with multiple active developers. > > There are situations where a commit to the trunk may be appropriate though: - trivial fixes/changes (creating a branch for each of these would be overkill) - emergencies - security fixes? It's the big, experimental changes that should be developed and tested in a skunk branch, IMO. Keep in mind that branching automatically also means merging with the trunk, which can be a tedious exercise, depending on how much the two have diverted from each other over time. > Therefore in this case I'd prefer to observe rather than vote for any >> particular methodology or risk letting my own wants or ego stand in the way >> of what River needs, which is increasing participation and innovation. >> >> I have no objections to you reverting the changes. >> > > For what it is worth, I strongly agree with the plan Jonathan proposes. > > I would like to get ASAP to a head trunk revision that runs all known > tests, then spawn off at least one branch for your work, possibly more than > one if it splits into separate threads that you want to push in parallel, > and a NewTaskManager branch with a solid basis. I hope Jonathan will > continue the excellent work he is doing on getting the tests organized and > running regularly. > > Like you, I need to learn branching and merging in SVN. I've done it in > other revision control systems, and the general idea is hand merging only > for those files that have been modified since your branch was spawned off. > > Perhaps someone can recommend a tutorial that covers SVN the way it is used > in Apache? > The following links may be of interest: http://www.apache.org/dev/contributors.html http://svnbook.red-bean.com/
