httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Change
Date Fri, 09 Jan 1998 03:23:25 GMT
Dean Gaudet wrote:
> On Thu, 8 Jan 1998, Jim Jagielski wrote:
> > Change is good.
> > 
> > Example 1: The current process of posting patches and then having
> > M-ID in status. A nice change IMO would be to place the patches
> > somewhere under the CVS tree to allow easy and consistant access
> > to the patches. Change-type: Evolutionary. As far as I can recall,
> > Dean thought this sucked, even though it helped some people out.
> Dean thinks this sucks because it was presented as an additional duty to
> perform while patching the code as opposed to replacing the duty of
> posting the patch to new-httpd.

Actually, it was either the reduction of a duty (not having to
post a whole seperate message to new-httpd and then wait for the
message to pop up before one could edit STATUS) to make it easier for
anyone with access to the CVS tree to have access to all the patches
in their up-to-date form

> If the proposal is really to replace the
> posting of the patch then say so, and get rid of apache-cvs and direct all
> cvs commits to new-httpd.  It seems foolish for folks to subscribe to both
> lists, and if they don't subscribe to apache-cvs they may wonder what's
> going on.  It's not like apache-cvs is high volume. 

Under commit-and-review it sure would be :) :) :)

> > Example 2: The current review-and-commit process, which has been
> > used since Day 1 is slow. A nice change would be to instead
> > have commit-and-review. Change-type: Revolutionary. Dean liked it
> > cause it made things easier for him.
> ... and makes things easier for other developers.

and some possible costs... No free ride on anything unfortunately :/

> It's far less work than
> the current or the example 1 or my modified example 1.

Agreed 100%! It's much much easier. Never said it wasn't. It's
a coders utopia. Hell, I'm surprised I'm on this side of the
discussion! All I'm saying is that it's a major change to
how things are being done, as well as more "risky" in that
it much easier for people to be totally clueless about what
the hell is going on with this setup. That's it. That's my
whole point. If we can't "force" people to review code to be
committed first, I can almost guarantee that they won't _after_
it's committed. Esp. when you consider that once code it committed,
it's inertia grows by about 10x and it's tough backing it out.
It'll be tuned and touched and updated but there is real resistance
_from all sides_ to take it out.

> I dunno.  There seems to be a lot more room for error and frustration
> with the current system -- both leading to apathy.

I think the apathy resides on the reviewing side mostly... I can
appreciate that you're in a coding frenzy and anything that slows
that down is frustrating. Hell, I'd even consider having
Lazy voting be a sort of norm instead of a special case. But see,
that's just me... I like to compromise.

That's sorely lacking around these parts. People get a bug up their
ass and "that's that!" "I don't like it because I don't" and that's
all she wrote.

      Jim Jagielski            |       jaguNET Access Services           |
            "Look at me! I'm wearing a cardboard belt!"

View raw message