On 25/03/2011 15:07, Scott Wilson wrote:
On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote:
It looks like accounts for us new committers are being created. As
we prepare to commit the donated code bases, I thought it would be
good to lay out some of the next steps. The last few weeks seem to
have been busy for everyone, and we haven't had many discussions
regarding what we need to do to get Rave moving forward. The
following is a list of things I think we need to accomplish in the
near term. The list is by no means comprehensive and there is
probably a better place for it to live, but it is intended to spark
discussion.
Looks like a good start - thanks for starting the ball rolling!
1. Commit donated code bases 2. Finish public website on CMS (think
Ross started this?)
Not yet. It's getting closer to the top of my todo list. now you are All
getting your logins I will keep it moving up. My intention is to put a
skeleton in place for you and you can take it from there.
4. Discuss working agreements for coding practices, quality, unit
testing, coverage, CI, sandbox environments, etc (Some of this is
probably standard Apache practice)
I don't think there is such a thing as a standard Apache coding
practice :-)
Scott is correct. There is no "standard" but there are a whole bunch of
common practices that you'll find here. I'm not sure how the other
mentors plan to tackle this issue. My own style is to let you get on
with it and pipe up if I believe either a) something is potentially
harmful to an ASF project or b) there is a way to do something that I
believe will help.
For your mentors to do this effectively you need to discuss everything
here on the list. I don't think there will be much of a problem with
that in these team.
7. Agree on process for "cherry picking" features and
integrating them into the Rave code base
Well, we can pick things we want to work on and mail the list to say
we're doing it, but beyond that I don't think we can have that much
of a process - anyone can implement any features they want and submit
patches for them, its up to committers whether to commit them.
Yes, this is probably the best approach.
1) say I'm going to work on getting feature X implemented I know how the
code in foo does that so I'm going to use that as a starting point. This
means I will implement it like this [pseudo code/UML/whatever]
2) community sits back and lets it happen or shouts "no - bar does it
better because.."
3) regular, frequent and early commits to give people chance to sound a
word of caution early
One of the approaches I like in some of our projects is for someone to
post a "Random Thought". This is a very early stage proposal for a
solution. The fact that it is a Random Thought means that people know it
is not supposed to be fully thought out and so constructive criticism
and enhancements are welcome.
These are posed to the list with [RT] in the subject and will typically
define a use case, a problem preventing the use case from being carried
out today, a rough idea that will satisfy the use case, a rough proposal
for how it might be implemented
Often such an RT can start the above 1-2-3 cycle going.
Ross
