OK, looks like we have agreement. I'll try to at least initiate my proposal later today. Thanks Jonathan
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. > > 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. > > > 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? > > Also, maybe we should do some branching and merging in the skunk area to > build confidence that we can do it right, and familiarity with what happens > during a merge. > > > I expect that you'll continue participating and perhaps blaze the trail as >> leading developers, so that I can watch and learn, I'm interested to see >> what you have in mind. >> >> River needs people willing to do the leg work necessary to succeed. >> > > Agreed. > > > >> Best Regards, >> >> Peter. >> >> Jonathan Costers wrote: >> >>> I have to agree with Sim here ... >>> >>> I'd say (if it were entirely up to me): >>> 1. backout the changes >>> 2. make sure the current QA tests run >>> 3. add categories servicediscovery,discoveryservice,io and security to >>> the >>> QA test categories to run by Hudson, one by one >>> 4. make sure these QA tests run as well >>> 5. piece by piece, restore the changes and keep an eye on any tests >>> failing. >>> In parallel, keep validating and adding more QA test categories. >>> >>> This would allow us to work in a more structured manner, and to perform >>> peer >>> reviews on bite size changes. >>> We have to better organize ourselves, considering the limited resources >>> we >>> have. >>> >>> To summarize: >>> - the changes to RemoteEvent etc. caused many discovery related tests to >>> fail >>> - the changes to ClassLoading caused some classloading / io related tests >>> to >>> fail >>> - the changes to DynamicPolicyProvider caused security (and other) tests >>> to >>> fail >>> >>> And that's what I found after going through it very quickly and backing >>> out >>> some obvious things. >>> These actually look more like experiments than actual tested changes. >>> IMO, this kind of experimentation should probably be done in a skunk >>> branch, >>> not the trunk. >>> >>> If for any reason, my understanding is incorrect, and backing out is not >>> an >>> option, then I would suggest to at least create a JIRA issue for each of >>> the >>> above topics. >>> >>> Thanks >>> Jonathan >>> >>> 2010/9/1 Peter Firmstone <[email protected]> >>> >>> >>> >>>> Sim IJskes - QCG wrote: >>>> >>>> >>>> >>>>> On 09/01/2010 01:16 AM, Jonathan Costers wrote: >>>>> >>>>> >>>>> >>>>>> Similarly, having backed out the RemoteEvent changes, and running the >>>>>> "discoveryservice" category: >>>>>> >>>>>> >>>>>> >>>>> It looks to me, that the code in the trunk was not completely ready. >>>>> >>>>> >>>>> >>>> It looks that way. >>>> >>>> >>>> Would it be a good idea to revert the changes until the unit tests run >>>> >>>> >>>>> again, and build a branch in svn to continue the work? >>>>> >>>>> >>>>> >>>> Let me get my head around understanding the failures first before we >>>> revert. >>>> >>>> >>>> >>>> >>>> >>>> >>>>> If a committer (with svn access) needs help, i can offer some >>>>> assistance. >>>>> >>>>> >>>>> >>>> Thanks ;) much appreciated. >>>> >>>> >>>> >>>>> Gr. Sim >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> >> >> >
