Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Fri, 12 May 2006 14:07:48 +1000
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: [Proposal] Refining our Development Process
Message-ID: <20060512040748.GB24519@igg.indexgeo.com.au>
References: <838319937.20060503183031@soethe.net>
 <1332709952.20060510105747@soethe.net>
 <20060511060642.GV24519@igg.indexgeo.com.au> <44635C3C.1000408@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44635C3C.1000408@apache.org>
User-Agent: Mutt/1.4.2.1i

Ross Gardler wrote:
> David Crossley wrote:
> >Ferdinand Soethe wrote:
> >>  Whiteboard and Peer Review Priciples
> >>    
> >>  It's important to point out that this way of using the whiteboard
> >>  is an attempt to deal with limited resources in a realistic way by
> >>  allowing committers with limited time, to 'savely ignore' the
> >>  discussions of early development stages and focus on paticipation
> >>  in later stages (or when they are explicitly asked for an opinion).
> >
> >I, for one, am not prepared to add the concept of
> >"safely ignore" to our project guidelines. It totally
> >goes against the Apache projects' PMC oversight principles.
> >
> >People can make up their own mind about what they follow
> >and what they don't follow. I don't see a need to explictly
> >sanction the ignoring of topics. KISS.
> 
> I think I also voiced my dislike of "safely ignore" in response to the 
> first draft. It is the duty of the PMC to provide oversight. In my 
> previous response I acknowledged that the reality is that not every PMC 
> member reads every mail and commit but, we have enough eyes to ensure 
> nothing is ignored. There is no such thing as "safely ignoring" within a 
> community project - only freedom of choice.
> 
> Why are the words important - because it removes the responsability, and 
> it is that responsability that ensures we find what time we can to 
> provide the necessary oversight.
> 
> -1 to "safely ignore"
> +1 to freedom to choose
> 
> >> Minimum Requirements for internal release are:
> >> (this may need further discussion)
> >
> >
> >Also needs to gain "community". If the code is a
> >one-person affair then we will get into trouble.
> >I suppose that an actual Vote would express that,
> >because +1 also indicates a willingness to assist.
> 
> Yes, and we need to stress that in the vote. +0 will help assist a 
> projects "release" but not provide false promises of contribuions, or 
> indicate false support.
> 
> One thing I am guilty of is saying +1 when I should be saying +0. I (and 
> we) must stop this.

This would work if we are "voting". However, IIUC
this current proposal uses Lazy Consensus, i.e. no vote.

More and more i like the idea of doing an explicit
vote for moving plugins out of the whiteboard.

> >It should be stressed that stuff should move out of
> >the whiteboard as soon as possible (similar to how
> >branches should merge ASAP). Don't stay there until
> >it is complete.
> >
> >What level of functionality is required? Just basic
> >i presume.
> 
> I would say, "just basic". A community of support is more important. 
> Look at the Daisy plugin as an example. It is feature rich and very 
> complete. However, to maintain it requries a fairly in-depth knowledge 
> of Daisy. I don't think anyone here has that knowledge.
> 
> On the other hand, something like the photogallery isn't very feature 
> rich but it has had three different commiters and at least one other is 
> using it. That should probably come out of the whiteboard.
> 
> >>The outcome of the application can be one of the following (decided by
> >>a Lazy approval [1] after discussing the proposal):
> >
> >
> >Using "Lazy approval" is intended for the normal
> >development process, i.e. just do it, and if someone
> >raises a alarm bell then we backtrack/fix/decide.
> >This encourages efficient development and is used
> >as often as possible.
> >
> >With your proposed change of process i do not see how
> >it will work.
> >
> >Using lazy approval makes it hard to get the beast
> >back into the whiteboard in the case of "Postponement"
> >or "Rejection".
> 
> yes, given the need for community we need a minimum number of "+1" votes.
> 
> ...
> 
> >There are some other things that need considering ...
> >
> >There is already a concept about "deployed" plugins
> >and "released" plugins. I cannot see where this is
> >defined in our docs.
> 
> It is not defined in our docs. I won'r go into it here, but we need to 
> define them

There is already discussion about it in the archives,
and in plugins/build.xml
deploy - Deploy the unversioned plugin to the website SVN
release - Release the versioned plugin to the website SVN

> (and indeed decide if we still need deployed plugins now we 
> have auto deployment from the src directory).

Interesting idea. Lets talk about that in a separate topic.

> >Also we haven't yet defined a process for official releases
> >of plugins as separate from the release of a whole package
> >of trunk (e.g. forrest-0.7) which includes all plugins
> >(including whiteboard) in their current state. Official
> >releases of any product requires a PMC vote.
> 
> This should not be a blocker for Ferdinands proposal. As I see it this 
> proposal is about moving from whiteboard. It is not really about 
> releasing a versin of a plugin. That is, it could still be an unreleased 
> plugin, just one that is in core.

That is one reason i said that, so that we 
clearly state that there are various steps for
developing and releasing a plugin.

> >That leads to another problem with the current proposal.
> >When it comes time for a release of Forrest (e.g. 0.8)
> >then the PMC needs to vote on what is packaged with that
> >release. Currently that includes $FORREST_HOME/whiteboard/.
> >PMC members who have not been watching what is happening
> >would have difficulty with voting.
> 
> As I proposed befor the last release, we shoould leave all plugins out 
> of the binary release. Plugins are auto-downloaded when they are need, 
> why distribute them?

Wow, sorry i missed that suggestion.
Lets talk about that separately.

-David

> We can provide separate pacakges for whiteboard and plugins to assist 
> those trying to work offline.
>
> >I wondered earlier in this thread if whiteboard should
> >be moved outside of our trunk. That might solve some
> >problems, but there are other factors against doing it.
> 
> There you go ;-) (replying as I read - my previous para takes this idea 
> one step further)
> 
> Ross