forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: [Proposal] Refining our Development Process
Date Thu, 11 May 2006 15:46:04 GMT
David Crossley 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.

> 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 (and indeed decide if we still need deployed plugins now we 
have auto deployment from the src directory).

> 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 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?

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

Mime
View raw message