Re: [Ganglia-developers] [PROPOSAL] Development procedure change...

[Brad N. <BNI...@no...>]

>>> On 11/25/2008 at 2:26 AM, in message <200...@sa...>,
Carlo Marcelo Arenas Belon <ca...@sa...> wrote:
> On Thu, Nov 20, 2008 at 11:32:02AM -0700, Brad Nicholes wrote:
>> 
>> I have put together a procedure change proposal and posted it on the
>> Ganglia wiki site:
>>
>>   http://ganglia.wiki.sourceforge.net/Proposed+Release+Policy+Change)
> 
> +1
> 
> on one of those patches that can't be committed to trunk first to be
> backported will then soon present a backport proposal as an exercise.
> 
> do we have an ETA from when we could start stabilizing for the 3.1.2
> release under this new rules if approved?
> 

ASAP, I have been mostly waiting for feedback and approval from the community before making the policy official on the wiki page.  Hawson indicated that he still wanted to review the policy and provide feedback as well.  Hopefully his schedule will allow him to do that soon.

>> Please review this procedure change proposal and provide us with any
>> feedback that you have, either positive or negative.
> 
> something that is not explicitally mentioned in the wiki page is that
> since the proposals will be emailed, it is also expected that any
> discussion about them, if needed, will be done in the list.
> 

Yes, discussions about code should always happen on the list.  Status information that results from those discussions could be put in the STATUS file to help tracking.  Whether that is done or not is up to the proposal author and those engaged in the discussion.  As a guideline, all new features or enhancements should be presented on the list and discussed before backporting.  This is mainly as a courtesy to the community to let them know what is happening to the current branch and give them a chance to respond and discuss.  If within a reasonable period of time (a few days, a week, whatever) no discussions, objections, comments about the new feature are brought to the list, the developer should be free to backport the feature.

> the STATUS file will then only hold votes and serve as a tool to help
> track that proposals and that enough people had voted them for
> backporting.
> 

Yes, basically no different than before (at least for the maintenance branches).  The STATUS file is used as a tracking mechanism when needed.  For the current branch, the STATUS file will probably not be used much except to track releases and backported changes.  When a developer backports a patch to the current release, they should make a note in the "Current Release Notes" section of the STATUS file so that we can easily create the release notes for a new release without having to dredge through SVN.  And of course the STATUS file can be used for anything else we want to track about the branch as well.  

Brad