forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: [Proposal] Refining our Development Process
Date Thu, 11 May 2006 07:30:13 GMT

Thanks for your comments, David.

David Crossley wrote:

> Ferdinand Soethe wrote:
>> Since the debate on this seems to have died down, I have changed and
>> extended some parts of this paper to address the points raised by
>> David and Ross.
>> Now I would like to invite all for a last round of refinement before I
>> put this to a vote on Friday.

> When you do, please change the Subject line so that
> it explictly says "whiteboard".

I'd rather not do that because the changes go beyond the whiteboard
process and so a change in subject line might be misleading.

> There are many other
> aspects that have not been addressed by this proposal,
> so it does not apply to other development (non-whiteboard).

I thought "refining" reflected my attempt to improve on some parts
rather than re-writing it completely.
Perhaps we can find a better wording for this.

> e.g. define how we add new functionality to plugins that
> have already emerged from the whiteboard and how to
> maintain a trunk that is "always usable".

> Another thing that i would like to say up front is that
> i find myself repeating stuff said in the last major
> discussions. I would encourage people to read this
> whole thread:
> [A]
>  [Proposal] Development process and a stable trunk

I'm certainly guilty of ignoring that thread when I wrote this
proposal. One of the reasons being that I got the impression that some
of the responses then were written on the bases of misunderstandings,
so that I wanted to get a fresh start.

> What is it that stops group 2 from operating?
> Why can't they use a particular SVN revision number
> of trunk that they know works?

[Sorry Thorsten, I know this will sound like Structurer-bashing
 again but it is such a good example. ]

The problem is that our 'stable trunk policy' _solved_
the problem of projects failing to work for broken code reasons

but it _did not solve_ the problem of projects breaking because of
repeated changes in the architecture of new features.

And it also did not solve the problem of people investing a lot of
time and effort in understanding an quickly evolving architectural

In other words I todays think that I'm glad that I didn't even
try and learn views or earlier structurer versions because I would
have wasted my time and others (by asking detailed questions like I do
ask now about the locationmaps).

But since this not always obvious at the time it was trying to
establish a process that more clearly marks a borderline between wild
creative hacking style development and a mature concept.

> As i said in the recent discussion, "whiteboard" is already
> in the "trunk". I think that you mean "move out of whiteboard".

Yes, sorry, I missed that sentence when I edited my paper.

> Tim, and all other respondents, raised some very
> important concerns in the previous proposal [A].

Sorry, I'm not very good at deciding which ones of those comments are
still valid for the current proposal. But since you pointed to Tims
concerns I'm happy to requote and address them here:

Tim wrote:

> We've talked about this before and last time the only thing I had
> heartburn with was "always releasable" trunk as it implies an "Always
> Branch" system and I think that's overly rigid and runs counter to our
> community goals.  A reasonably stable trunk is a good goal.  Well
> documented to the extent possible - if something is still under heavy
> development then time shouldn't be wasted documenting yet (beyond that
> which would allow other devs to check it out).  Heavy development in
> the trunk?  Yes, if it's not causing the trunk to be unstable, then
> yes.

One reason that I wrote the new proposal was the impression that we
needed to reconsider our position in the light of last years

> Heavy development in the trunk? Yes, if it's not causing the trunk
> to be unstable, then yes.

In my view this rule has already lead to some type 1.5 and 2
developers to opt out of using trunk in the last year. Something that
I feel we cannot ignore.

> As written, I think this would lead to fracturing in a couple ways.
> 1) devs wouldn't check-out all the other branches and new stuff
> would be sole-developed even more so than some things are now; 2)
> bleeding-edge users won't get into checking out multiple branches to
> checkout new functionality (i.e. no patches).

I (still) agree that this may be an effect. But in my view it is
_already happening today_ and I'm merely trying to establish a system
that will make sure that fractures are put back together at a certain
point in the process.

> Encouraging such on the project would lead, in my opinion, to a
> fractured community.  People naturally tend to prioritize email based
> on the subject line, but supporting that through branch prefixes or
> the like would lead to several "mini-projects".  Heck, people might
> even set up email filters to only look at "their" branch -- not good. 
> I think instead we need folks periodically reminding everyone to write
> good archive/mailbox-friendly subject lines.

Perhaps I'm stuck too much in my old ways of thinking. But in all the
organizations I have ever belonged to, it was an accepted and common
practice to branch into working-groups that report back to the plenum.
And I can't see why this should be wrong for Forrest.

Of course it would be ideal if we all had the time to follow all the
discussions in detail but face it, the last year has shown that we
don't, that people do filter and opt out already.

Back to David's message

> We already know that many people do not use a sensible
> subject line for their email messages. So trying to
> get them to add a prefix will be difficult too.

Agreed. And it will probably not always work. But wouldn't it be
useful even if it only worked 80% of the time?

> Another issue is that discussions often fork into
> some very important new general topic and people
> do not change the subject line.

So one community effort - as I see it - would be to help and correct
such mistakes.

> So important topics
> will tend to be ignored.

Why are you saying 'will be'. This is ignoring the fact that it
already happens to day. Just scan the list for Ross writing 'I really
need to re-read this or that'. And I take that to be just the tip of
the iceberg because Ross is very honest about this.

Doing a more detailed analysis of list interaction I could probably
point out many many instances where people have completely ignored or
misunderstood important parts of a thread.

And while this has many reasons (that we talked about recently), one
big factor to me seems our attempts to cut corners by speed-reading,
skipping, filtering (add your own ...) just to maintain this utopia
of being able to do it all.

(Now you know why Germans are called the most pessimistic people in
Europe :-))

> Another issue is that prefixes will enable people
> to automatically filter mail out-of-sight. This would
> lead to a fragmented community.

> If we just continually encourage the use of descriptive
> email Subject lines and new ones for new topics,
> then the main aim of your proposal is accomplished.
> So there is no need to explictly talk about ignoring
> some topics.

I disagree because I still wouldn't know when a new topic on
structurer is so close to maturity that it makes sense for me to
follow it.

> As Ross said in [A], one can peek into the first
> posting of a thread, and then follow it or not.

Well, joining this project rather late, my experience is that this
does not work at all. Quite often threads develop in all kinds of
directions so you really have to read it all. My proposal won't fix
that but it aims at improving this situation.

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

Perhaps we could call it "more safely ignore" or something else.

> It totally
> goes against the Apache projects' PMC oversight principles.

Does it? If you think so I'd suggest that we do a reality check and
test how many of our current committers are actually up to date on all
current developments and discussion.

I may be wrong but me guess is that I would not be the only one to
fail miserably ... wdyt

And if I'm right, aren't we paying lip service to these rules by
ignoring this?

> 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 disagree. By choosing to ignore structurer/dispatcher topics today I
miss the important explanations of architecture and concept as well as
not so important issues. So I don't see that choice.

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

Thanks for adding that. Wouldn't hurt to put that in there because it
probably isn't always the same. And it should be important to us.

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

If you mean as soon as the architecture is mature and stable I agree.
Did you mean it this way?

>> 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".

Why is that? And what would you recommend?

> There is already a concept about "deployed" plugins
> and "released" plugins. I cannot see where this is
> defined in our docs.

I take it this would be a new discussion?

> 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 also would be a new topic?

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

I have the same problem (needing to trust the judgement of my fellow
committers) today.

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

I'd be just as happy to exclude whiteboard from official releases.
What are the factors against doing it?

Ferdinand Soethe

View raw message