apache group process

["Roy T. Fielding" <fi...@kiwi.ics.uci.edu>]

The funny thing is that, on my way to the movie last night, I went
through the same basic reasoning that RobH did on why things are slow,
and came to pretty much the same conclusions.

First, regarding the apache-core private list.  Regardless of the
impression given by Dean's announcement, we had already decided to
make it public.  What we lacked was the words for doing it, which Dean
could have provided just as easily.  There has always been a private
apache core discussion list, even before we created new-httpd.  The old
list used to be just a list of CC addresses whenever something private
needed to be discussed, but we often found that new people would be
accidentally left off the CC list.  So, we created a real mailing list,
but then had one hell of a time deciding whether the list should remain
"focused" or "inclusive" (even though it was neither at the time).
That led to delays, which made it even harder to invite people to join,
even though missing people was the original problem with the CC list.
The only difference was that, with the old CC list, the decision
of who was in the core was decided by whomever posted the first message.

>What system can work ?
>
> Who knows until we experiment and find out.

My thoughts exactly. *WE* put this project together. *WE* kept it going.
We have almost reached our third birthday, so there's no reason why we
can't revisit the way we do things. We have done it before (in fact, we've
done it every 11-12 months -- maybe it is a side-effect of the holidays).

The real problem is that people don't know how to change the process.
For that matter, we seem to have a hard time dealing with the notion
of proposing a course of action and then carrying it through.  For some
reason, many of us seem to think that whining about the current state of
affairs is equivalent to proposing a solution, or that just reaching a
decision is sufficient to get something done -- that it will somehow 
get done by itself.

I have only one response to that: Grow Up!  Yes, this is about politics.
Political science is the study of how policy is made, adapted, and
sometimes ignored.  I know some people have adverse reactions to such
things, but there is nothing disreputable about setting policy, and
we need to get beyond the TV mentality of politics being "somebody else's
business."  The real difference between a democracy and other forms of
government is that politics *is* your business, whether you like it or not.
But now I'm getting sidetracked ...

In order to make a change to how the Apache Group works, someone in
the group needs to propose a change.  That doesn't mean a simplified
one-line summary.  It means a well-thought and thorough summary of the
process we should follow in making decisions, and how the decisions
should get implemented once they are made.  It should consider things
like the difference between bug fixes and features (and yes, it is
easy to define what a feature is when you think about it), when and how
does someone gain commit access (plus how and why they might lose access),
when and how we do releases, and how our CVS tools can be used to make
all the above easier.

Before anyone says "that takes too long" or "I'm just a hacker", please
consider for once how much of MY time you have already wasted by
whining about the current process.  If you are willing to waste MY time,
why is it unfair for me to ask for something more substantial in return.
I am fully aware of how much effort is involved.  I do appreciate it.
I am, however, two years behind in my PhD work, so I have little compassion
for other people's time right now.  It is time for someone else to be
the new champion for the new process.

Both RobH and Brian have made some good proposals, or, I should say, at
least the start of some good proposals.  How about committing them to
files in the apache-dev repository?  That way we can fill them out,
explore alternatives, and ultimately vote on which way to go.  You might
want to start with the not-so-current guidelines document and edit from
there to something that matches each proposal.  We can then vote on it.
The same thing can happen later, if it doesn't work as well as expected.

For once, I don't want to hear anything from "The Devil's Advocate".
If folks can't be their own advocate, I don't want to hear from them.
The Devil doesn't get a vote unless he starts doing the work.

This is not a code decision, so no vetos apply.  A vote means you are
willing to do the work of the project, whether that means maintaining
our project stuff, documentation, code, testing, bugdb, whatever.
I won't be voting, unless there is a tie.

I am personally in favor of a two-repository system with commit-at-will
on the 1.3 repository and a release manager on 1.2.  I have no interest
in a release manager on 1.3 until 2.0 begins, since the code in 1.3 will
not be stable enough to manage until 2.0 is the focus of new features.
I also think that the current beta numbering scheme does not work
(remember, we didn't use that system pre-1.0) and that we should just
number things consecutively and simply change their filename from "beta"
when we know they are robust.  Note that this paragraph is not sufficient
to be considered a proposal -- I just wanted to let you know how I feel
about the current process.

Please note that I never "lost interest" in the review process, and
I never gave a patch a +1 without seriously reviewing it.  I haven't
been voting lately because I have no spare time to give the project.
That doesn't mean I don't care about it.

....Roy

Re: apache group process

[Brian Behlendorf <br...@organic.com>]

At 10:34 AM 1/9/98 -0800, Roy T. Fielding wrote:
>The real problem is that people don't know how to change the process.
>For that matter, we seem to have a hard time dealing with the notion
>of proposing a course of action and then carrying it through.  For some
>reason, many of us seem to think that whining about the current state of
>affairs is equivalent to proposing a solution, or that just reaching a
>decision is sufficient to get something done -- that it will somehow 
>get done by itself.
>
>I have only one response to that: Grow Up!  Yes, this is about politics.
>Political science is the study of how policy is made, adapted, and
>sometimes ignored.  I know some people have adverse reactions to such
>things, but there is nothing disreputable about setting policy, and
>we need to get beyond the TV mentality of politics being "somebody else's
>business."  The real difference between a democracy and other forms of
>government is that politics *is* your business, whether you like it or not.
>But now I'm getting sidetracked ...

I 100% agree.

>Both RobH and Brian have made some good proposals, or, I should say, at
>least the start of some good proposals.  How about committing them to
>files in the apache-dev repository?  That way we can fill them out,
>explore alternatives, and ultimately vote on which way to go.  You might
>want to start with the not-so-current guidelines document and edit from
>there to something that matches each proposal.  We can then vote on it.
>The same thing can happen later, if it doesn't work as well as expected.

I've created a new doc in the apache-devsite tree, "commitpolicies.html",
which is available at http://dev.apache.org/commitpolicies.html.  Comments
on it are welcome.

	Brian


--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects				  brian@organic.com