river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <phil.ste...@gmail.com>
Subject Re: development process
Date Sat, 01 Sep 2007 22:50:04 GMT
On 8/27/07, Jim Hurley <Jim.Hurley@sun.com> wrote:
> (Note: we made good progress on the first question... but
> just leaving room for anyone else to add in before I summarized).
> Meanwhile... on to the next)
> As we continue discussing the "AR1" release questions/tasks...
> here's the next:
> > * What kind of development process do we need?  JIRA issues for
> >    all changes?  code reviews?
> There's also a testing issue here (for example, do you need to
> supply tests?  if so, which framework or just unit tests).  This
> is somewhat tied into:
> > * What kind of testing do we need?
> It would probably be easier to tackle these (dev process and
> testing process) separately.... but if they spill into one another,
> than so be it.
> So, regarding development process -- what do you think?
> In looking around, I didn't see a norm for things (for example,
> not sure if projects use JIRA for everything).  We've used code
> reviews inside our group at Sun for the starter kit, and it's proved
> immensely valuable.  I'd vote to continue it - both as a quality
> measure as well as a way to get more people involved and
> knowledgeable about the different pieces of code.
> Please share your thoughts.

Sorry to be "late to the party" on this.  Based on the discussion on
this thread and how things work elsewhere at the ASF, here are my

You are correct, Jim, when you state that the project has wide
latitude in defining its own policies and RTC is "allowed".  This is
an important principle that we all need to keep in mind - it is up to
the community to decide how it operates.  The mentors, incubator PMC
members and other interested parties at the ASF can comment, make
recommendations, share opinions and raise concerns, but it is up to
you, the community, to decide.

Open development is the one non-negotiable requirement at Apache - so
private code-related decision-making, private f2f reviews where
decisions are made, off-list communications, etc., cannot be an
essential part of the development process.  It is certainly fine for
people to get together and look at, play with, brainstorm code-related
issues; but decisions have to be public and the entire community - not
just committers or PMC members - need to be allowed and encouraged to
participate in the discussion and review.  One way to look at this is
to say that the thought process behind all changes needs to make sense
to, and be influenceable by, any iterested member of the community who
is willing to invest the time to dig into the code.  This is the key
to growing the community and a big challenge for complex projects like
River.  Documentation and test suites requiring no special setups are
key to this (an area where I would like to help).

Ron and others succinctly make the point that the complexity of the
River codebase and potential for changes to introduce subtle bugs
argues for careful review as part of the development process.  On
this, all seem to agree.  Open development, even using CTR, does not
have to mean "shooting from the hip" or "commit then crash" or
anything of the sort, though.  We have other similarly complex
codebases at the ASF that use lots of discussion, tests and eyeballs
to ensure commit quality.

It seems reasonable that RTC could "force" the necessary review.  I
agree with that from a practical standpoint, especially if formal
votes are required for each commit.  I have to agree with the other
mentors, however, that this is an extreme measure and the same effect
could be accomplished by just agreeing that non-trivial code changes
start with list discussion, then JIRA tickets with patches, and then a
reasonable lazy consensus period before commit.

To get "the same effect" without the formal "rules" of RTC and commit
votes requires trust and cooperation.  I have seen nothing on this
list to indicate that there is a real reason to worry about that.

To put this matter to rest and get moving on community-building and
cutting a release, I think it is a good idea to pull together a
proposal and put it to a VOTE.  In general, we like to avoid too many
VOTEs, but in this case to move forward I think it is a good idea.  I
am happy to write up a proposal along the lines above, but would be
heppier still if Jim or one of the initial committers proposed
something that we could agree on.

Once again, as I said at the beginning, it is up to the community how
we want to operate and we can always change down the road.  The only
requirement - and the objective to keep our eyes on - is that we
remain open and inclusive.


View raw message