Thanks for the compliment.
I'm looking forward to having some help, programming alone isn't much
fun, I've been quite busy, so a short break to let others show off their
skills while I get some much needed rest is all good.
This is probably also a very good opportunity to finally get some much
needed peer review.
Welcome aboard,
Peter.
N.B. I'd probably break the work up into three items:
1. Concurrent policy providers. - should be an easy quick merge.
2. RevokeableDynamicPolicy and Security delegates. - experimental,
this could take some time, how to avoid divergence? Can we merge
trunk into skunk periodically to keep it up to date?
3. StreamingServiceRegistrar, delayed unmarshalling and maven
provisioning support - this really needs everybody's input, it's a
core change we'll have to live with for a long time.
Patricia Shanahan wrote:
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
