voting

[Dean Gaudet <dg...@arctic.org>]

Oh P.S. Insert Dean's standard rant about how much a waste of time
preparing patches for voting, waiting for votes, and then committing them
is.  And how much it detracts from the productivity of the project as a
whole.  This has as much to do with the whole voting concept as it does
with the lack of active people who have "voting rights". 

Lately I'm moderately happy because a lot of folks are just giving my
stuff +1 on a once-over read, especially when it's for the 1.3 tree.  But
I still have to prepare patches to post, wait for votes, and then commit.
Whereas CVS is designed to be used in a commit-then-review fashion, and
we've got that wonderful cvs-to-mail gateway thing that lets us all see
the commits as they happen. 

I know for a fact there's a shitload more I would have done over the
summer if we didn't work in this manner.  Big patches are just not welcome
here, every time I post a non-trivial large patch I get complaints "wow
that's big, it's scary" and getting votes for them is like extracting
teeth.  So instead I waste time incrementally approaching a goal, or I
just don't do the work I want to do.  For a current example of this see
Martin's large EBCDIC patch which only I've voted on, and now it's out of
date and Martin will have to update it again before anyone else will vote
on it, and then folks will delay several weeks again, and it'll be out of
date again... 

We're the only free software project I'm aware of that works in this
braindead fashion.  I am completely envious of the freedom that folks on
other projects experience.  (In particular I track linux, squid, and some
freebsd development.  For linux and squid they have frequently development
releases, bugs are fixed quickly in the releases, features go in by the
bucketloads.) 

Yes, if you move to this model then the current CVS HEAD doesn't always
work.  But, uh, so what?  If it doesn't work then fix it, or bitch at the
author and stick with out of date code for a day or two.  That's how every
other software project I've worked on behaves. 

You know, in those cases where I've complained about aspects of other
people's patches that bother me.  If we were in a commit-then-review
situation I would have just fixed what bothered me after you committed.
This saves time.  Words are not exact, code is exact. 

Whatever. 

Dean

On Wed, 7 Jan 1998, Dean Gaudet wrote:

> Me.  I never include myself on the Reviewed by line in commits of my own
> code.  That's implicit.  And yes, I forgot to include the reviewed by
> line.  But the votes all happened.
> 
> Dean
> 
> On Wed, 7 Jan 1998, Rodent of Unusual Size wrote:
> 
> > dgaudet@hyperreal.org wrote:
> > > 
> > > dgaudet     98/01/07 19:16:50
> > > 
> > >   Modified:    src/modules/standard mod_include.c
> > >   Log:
> > >   switch from safe_copy to ap_cpystrn
> > > 
> > >   Revision  Changes    Path
> > 
> > I don't see the "reviewed by" line in this commit record, and I
> > only saw two votes in STATUS.  If we're not in lazy voting mode
> > (and Jim, the 1.3 RM, says we're note), I'm assuming I must have
> > missed something.  Who was the third +1?
> > 
> > #ken	P-)}
> > 
> 
> 

Re: voting

[Ben Hyde <bh...@gensym.com>]

Observations (old man blathering):

In my shop we use a "voting" procedure near releases.
We call it witnessing, not voting.  I've used this
device since the late 1970s so I've got some experience
under my belt (or is that just beer?).

As the release approachs the quality must get very
tight and the problems tend to be the most subtle and
architectual.  Sleep depravation causes team IQ to
plumet.  Customers have no sympathy.

Things are different in my world, somebody is usually
in charge.  I've usually had the burden of being the
that person, or his lawyer, so I could decide when to
move in and out of the witness mode.

Witnessing is the consequence of a "successful" code
freeze.  It's something project managers want, badly.
That's a slippery beast and I've had to back up when I
mandated it too soon.

There are always named parts of the project that need
to have witnessing postponed, they just aren't ready
yet.  I like to say: "you nail the lid on the coffin on
nail at a time."

New complex ports are almost always late to the party.

Performance tuning is usually done late in projects.
Managing it's risk against the stablization is always
difficult.  Particularly difficult if the guy doing it
is too clever and hence bits off big archetectual
changes.  It's great if you can get one really
competent person to focus on it and then give him a
single witness to guard against sleep and enthusiasm
problems.

I find that there are always individuals who's stature
fogs the judgement of the witness, it's occationally a
serious problem.

Suggestions:

I think the group could adopt some refinements to 
the voting rules.
  1. Named projects can be voted to have temporary 
     lower voting requirements.
  2. Commits that trigger regressions maybe fixed
     with NO voting - the coder should be prepared
     to ask forgiveness when he makes things worse.
  3. The release manager - in exchange for doing
     the damn job - is allowed to grant temporary
     wavers.

I'd propose that both the performance work and the
window's porting work be reduced to requiring only
a single witness for the next few weeks.

 - ben hyde

Re: voting

[Michael Douglass <mi...@texas.net>]

On Wed, Jan 07, 1998 at 09:17:19PM -0800, Dean Gaudet said:

I know I have no real say here; and sameer would prolly rather have me
shot anyway... :)  Hi sameer!  But I think Dean has a very good point,
I've worked with CVS for a while now, and only recently have we switched
to the mail-on-commit method (some may recall my off-topic post about
your scripts a while back) and since doing this, tracking not only the
changes to our source code, but what each employee is doing has helped
us significantly in our ability to get items coded and reviewed correctly.

Just my $0.02.

-- 
Michael Douglass
Texas Networking, Inc.

<tnet admin> anyway, I'm off, perl code is making me [a] crosseyed toady