forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@apache.org>
Subject Re: [Proposal] Refining our Development Process
Date Thu, 11 May 2006 16:35:04 GMT
Ferdinand Soethe wrote:
> 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.

I was happier when this current proposal was
limited to just the whiteboard. It was a manageable
chunk and the rest could be addressed later.
http://forrest.apache.org/guidelines.html#development

So i suppose that i agree with your next point
about "refining".

The trouble is, if you are going to call a vote
then we need something specific to vote on.

> > 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.
> 
> > http://forrest.apache.org/guidelines.html#development
> > 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
> >  http://marc.theaimsgroup.com/?t=112504310100005
> 
> 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.

I read that thread and didn't see fundamental
misunderstandings. I will try again.

I thought that everything was clarified and we
just needed to document it. We didn't, so here we
go again.
 
> > 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
> concept.
> 
> 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.

Ah, thanks for explaining that. It helps a lot.

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

The main thing that i was referring to was our
previous comments about "safely ignoring". The
responses where emphatic.

But yes, as usual the rest of Tim's comments were
important too.

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

Hmmm, apart from Dispatcher which was necessarily
changing (but still within the whiteboard) i cannot
see what would be a problem.

I agree, we need to address any such possibility.

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

Yes already happening.

We probably need to approach it from many angles, e.g.
encourage divisions not to happen, fix fractures,
ease the load of discussion, better email subjects, etc.

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

I know that. I struggle to keep some control of my
dev@cocoon inbox. But i do manage to do it.

Yes by ignoring some messages and by not committing
patches when i feel compelled. I do not do it because
of some sanctioned practice at Cocoon, but by deciding
for myself what to let pass.

Yes we all feel guilty for doing so, but that is
how it is. We cannot hope to cover everything,
but we can as a group.

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

My main concern is potential fragmentation of
the community. So my answer is: i don't know.

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

I meant "So important topics tend to be ignored."
i.e. apply to both today and the future. If people
are more careful about using sensible email subjects
then the problem becomes less.

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

I agree. We cannot even expect 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 am not saying that anyone can possibly keep up
with everything.

What i am saying is that to encourage people not to
look at discussion (and putting such terms in project
guidelines) goes against the principle of oversight.

If the PMC is big enough and active enough, then
with those many sets of eyes, we should be able
to cover it in general.

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

I don't see why it will be any different
six months down the track. Those explanations
will be long gone and no-one will be able to
summarise them all at the time of moving a
particular plugin out of the whiteboard.

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

Yes. However some of my reply got snipped.
I also said it is difficult to define when some
functionality is mature, stable, complete.
So i don't see how it can become a rule. As a vague
guideline it is okay.

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

Oh, i think that i might have misunderstood
your proposal. Are you suggesting this? ...
Someone makes a Proposal to move something out of
the whiteboard, then we let it run for a while
(how long?), and if no-one says anything then
the normal "Lazy consensus" kicks in and they
just do it.

One problem i see though. The proposal takes
away the "oversight" and so normal ASF development
process is gone. So i wonder how Lazy consensus
can work.

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

I think so.

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

Perhaps. It was intended as a lead-in to the next paragraph.

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

Once thing that i was trying to say was if we deliberately
encourage people not to look at stuff in the whiteboard
then we probably should not be releasing it. So far i have
been working on the assumption that we are looking at it.

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

That should not be a problem. That is how it works.
We trust the PMC to do their best. If we each do our
little bit, then the whole will succeed.

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

I already said them earlier in this current thread.
No time to find them now.

-David

Mime
View raw message