rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: Next Steps
Date Sun, 27 Mar 2011 00:43:25 GMT
On 26/03/2011 23:38, Upayavira wrote:
> I'll try to do a karma grant for Rave folks tomorrow, meaning you can
> all start committing to your hearts content :-)

I just did it.

If anyone on the initial committer list cannot now write to the Rave svn 
then I did something wrong. Please mail this list with your availid and 
ask us to check it.

How do you know if you have access? you could add your name, in 
alphabetic order, to the list of contributors on our "in progress" web 
site. To do so follow these instructions:

- install CMS bookmarklet from the bottom of https://cms.apache.org/
- http://rave.staging.apache.org/rave/people.html
- click the CMS bookmarklet
- click edit
- make your edit
- tick the "quick commit" checkbox and enter a log message

Since you ticked "quick commit" you will have triggered a staging build 
with this commit (without it you commit but no staging build is carried 
out - handy if you know you have more to do).

View your work by clicking "staged"

If this process fails at any point then let us know.

If it did work, feel free to improve the very rough skeleton site I've 
put together. Note that you can checkout the site files using SVN and 
work on them locally.

There's some info on the CMS at http://www.apache.org/dev/cmsref.html

There's a new committer guide at 

and a FAQ at http://www.apache.org/dev/committers.html

you know where we are if you need help

> Upayavira
> On Fri, 25 Mar 2011 16:32 +0000, "Ross Gardler"<rgardler@apache.org>
> wrote:
>> 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

View raw message