rave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: Next Steps
Date Sat, 26 Mar 2011 00:43:08 GMT

On Mar 25, 2011, at 2:37 PM, Sylvain Wallez wrote:

> Le 25/03/11 17:32, Ross Gardler a écrit :
>> On 25/03/2011 15:07, Scott Wilson wrote:
>>> On 25 Mar 2011, at 14:48, Franklin, Matthew B. wrote:
> [...]
>>>> 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.
> Well, I personally have two important rules :
> - use spaces for indentation and not tabs
> - choose a consistent coding standard that nobody is strongly against (which is very
different from "everybody agrees on") and stick with it.
> That's it :-)
>> 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
>> 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.
> You can also ready a blog post I wrote long ago about "I-will-do-it-o-cracy" that discusses
how informing that you _will_ do something before actually doing it keeps the community rolling
by allowing people to voice their opinion before too much work has been done, which can lead
both to technical problems (reverts, etc) and more harmfully community problems : http://bluxte.net/musings/2005/03/21/meritocracy-doocracy-and-iwilldoitocracy
> Note that this is a bit different from trying to constantly seek consensus and agreement,
which can lead a projet to stall.
> Sylvain
> -- 
> Sylvain Wallez - http://bluxte.net

View raw message