You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Rodent of Unusual Size <Ke...@Golux.Com> on 1998/01/11 17:10:31 UTC
[POLL] experiment with commit-then-review
I'm also calling the question on this issue so we can move forward
one way or another. If it doesn't get enough votes, or it gets
vetoed, we can stop wasting bandwidth on it for a while. We can
determine the necessary guidelines (such as when c-t-r is *not*
appropriate) later IFF we decide to try the experiment.
The question is: Shall we, as a group, experiment with allowing
commits to the source tree without prior review?
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Dean Gaudet <dg...@arctic.org>.
+1
On Sun, 11 Jan 1998, Ben Laurie wrote:
> Rodent of Unusual Size wrote:
> > The question is: Shall we, as a group, experiment with allowing
> > commits to the source tree without prior review?
>
> +1
>
> Cheers,
>
> Ben.
>
> --
> Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
> Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
> and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
> A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
> London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
>
Re: [POLL] experiment with commit-then-review
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
> The question is: Shall we, as a group, experiment with allowing
> commits to the source tree without prior review?
+1
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: [POLL] experiment with commit-then-review
Posted by Ben Laurie <be...@algroup.co.uk>.
Rodent of Unusual Size wrote:
>
> Okey, this issue has been pretty quiet for a few days.
> Is anyone unhappy with the conditions for c-t-r as specified
> in <http://dev.apache.org/guidelines.html#ctr>? (Reproduced
> below.) If no-one has any heartburn with this, can we please
> say it's a go and get on with it?
+1. Someone needs to debug the English, though...
Cheers,
Ben.
--
Ben Laurie |Phone: +44 (181) 735 0686|Apache Group member
Freelance Consultant |Fax: +44 (181) 735 0689|http://www.apache.org
and Technical Director|Email: ben@algroup.co.uk |Apache-SSL author
A.L. Digital Ltd, |http://www.algroup.co.uk/Apache-SSL
London, England. |"Apache: TDG" http://www.ora.com/catalog/apache
Re: [POLL] experiment with commit-then-review
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 19 Jan 1998, Rodent of Unusual Size wrote:
> Dean Gaudet wrote:
> >
> > On Mon, 19 Jan 1998, Rodent of Unusual Size wrote:
> >
> > > On the other hand, if you add something that works *only* on UNIX it's
> > > only fair to give the Win32 folx warning - and if it cannot be done
> > > under Win32 I think it's reasonable that they be able to veto the
> > > change. We decided long ago to maintain feature (if not bug) compatibility
> > > across platforms.
> >
> > I am absolutely against this.
>
> Which part? Letting other platform developers know you might be implementing
> something they'll have to try to winkle? Or requiring feature parity
> across platforms?
I think I explained myself clearly in the following paragraphs. I'm
against requiring feature parity across platforms. I've made it clear
several times that I had no intention of stopping communicating with
everyone, that would be insane.
> > If there's something we can't do on WIN32 that's just too bad. I'm not
> > going to cripple the unix version just because we can't do it on win32.
>
> I think both of these sentences are pitching it rather strongly. "That's
> just too bad" doesn't sound like a very team-oriented attitude to me, and
> I don't think that NOT adding a whistle is going to "cripple" the server.
> But I'll table my gut responses to those remarks for now and assume that's
> not how they were meant.
"team-oriented attitude"? Give me a break! I'm talking about taking
advantage of specific functionality on each platform we support because it
makes the server better.
> > Consider cpu time limits and other resource control stuff -- we may not be
> > able to do that on win32 yet (5.0 we should). You're saying we shouldn't
> > do that period, and I'm totally disagreeing with that.
>
> See my comment below on visibility.
>
> > I disagree that we "decided long ago to maintain feature compatibility
> > across platforms". We certainly don't have it now (consider
> > OPTIMIZE_TIMEOUT, a performance feature, consider mod_unique_id.c,
> > consider reliable USR1).
>
> I wasn't aware that mod_unique_id wasn't Win32-usable. Reliable USR1
> was there before the Win32 port, ISTR, so that doesn't count - and
> besides, Paul's working on something to make it available in Win32.
> As for OPTIMIZE_TIMEOUT.. Well, things that are user-invisible
> (as opposed to webmaster-invisible) I think have more latitude for
> platform-dependency.
No, reliable USR1 is there on any platform that has shared memory
scoreboard. If your platform is using a scoreboard file it still isn't
reliable. This is all documented in htdocs/manual/stopping.html. That's
yet another example of a feature we support on some unixes but not all of
them.
> And *I'm* totally against any developer on *any* platform charging
> along adding stuff and changing things that the people that work
> on the other platforms are going to have to interrupt their own
> work to catch up. At least not without fair warning in advance.
> I think that sort of thing falls under the "idea" review-first
> rule anyway, though, so it's a non-issue.
I already said that I've avoided breaking platforms in the past. I'm not
planning on changing that. I don't know why you're getting the idea that
I'm going to force other group members to "interrupt" their work.
Dean
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> On Mon, 19 Jan 1998, Rodent of Unusual Size wrote:
>
> > On the other hand, if you add something that works *only* on UNIX it's
> > only fair to give the Win32 folx warning - and if it cannot be done
> > under Win32 I think it's reasonable that they be able to veto the
> > change. We decided long ago to maintain feature (if not bug) compatibility
> > across platforms.
>
> I am absolutely against this.
Which part? Letting other platform developers know you might be implementing
something they'll have to try to winkle? Or requiring feature parity
across platforms?
> If there's something we can't do on WIN32 that's just too bad. I'm not
> going to cripple the unix version just because we can't do it on win32.
I think both of these sentences are pitching it rather strongly. "That's
just too bad" doesn't sound like a very team-oriented attitude to me, and
I don't think that NOT adding a whistle is going to "cripple" the server.
But I'll table my gut responses to those remarks for now and assume that's
not how they were meant.
> Consider cpu time limits and other resource control stuff -- we may not be
> able to do that on win32 yet (5.0 we should). You're saying we shouldn't
> do that period, and I'm totally disagreeing with that.
See my comment below on visibility.
> I disagree that we "decided long ago to maintain feature compatibility
> across platforms". We certainly don't have it now (consider
> OPTIMIZE_TIMEOUT, a performance feature, consider mod_unique_id.c,
> consider reliable USR1).
I wasn't aware that mod_unique_id wasn't Win32-usable. Reliable USR1
was there before the Win32 port, ISTR, so that doesn't count - and
besides, Paul's working on something to make it available in Win32.
As for OPTIMIZE_TIMEOUT.. Well, things that are user-invisible
(as opposed to webmaster-invisible) I think have more latitude for
platform-dependency.
And *I'm* totally against any developer on *any* platform charging
along adding stuff and changing things that the people that work
on the other platforms are going to have to interrupt their own
work to catch up. At least not without fair warning in advance.
I think that sort of thing falls under the "idea" review-first
rule anyway, though, so it's a non-issue.
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Alexei Kosut <ak...@leland.Stanford.EDU>.
On Mon, 19 Jan 1998, Dean Gaudet wrote:
> If there's something we can't do on WIN32 that's just too bad. I'm not
> going to cripple the unix version just because we can't do it on win32.
> Consider cpu time limits and other resource control stuff -- we may not be
> able to do that on win32 yet (5.0 we should). You're saying we shouldn't
> do that period, and I'm totally disagreeing with that.
Agreed. I think we should definitely adopt the attitude that, wherever
possible, we should try and keep code and functionality common between the
versions, so that we don't waste time and effort, and so they can be as
similar as possible, and we shouldn't deliberately break one platform with
code written for another, but I don't think it's possible, or even
desirable, to maintain complete one-to-one feature lists between *any* two
ports.
> I disagree that we "decided long ago to maintain feature compatibility
> across platforms". We certainly don't have it now (consider
> OPTIMIZE_TIMEOUT, a performance feature, consider mod_unique_id.c,
> consider reliable USR1).
Or consider that Win32 supports ISAPI extensions, and loading modules from
DLLs. Heck, Win32 does multithreading wheras Unix doesn't. That sounds
like a feature to me.
-- Alexei Kosut <ak...@stanford.edu> <http://www.stanford.edu/~akosut/>
Stanford University, Class of 2001 * Apache <http://www.apache.org> *
Re: [POLL] experiment with commit-then-review
Posted by Dean Gaudet <dg...@arctic.org>.
On Mon, 19 Jan 1998, Rodent of Unusual Size wrote:
> On the other hand, if you add something that works *only* on UNIX it's
> only fair to give the Win32 folx warning - and if it cannot be done
> under Win32 I think it's reasonable that they be able to veto the
> change. We decided long ago to maintain feature (if not bug) compatibility
> across platforms.
I am absolutely against this.
If there's something we can't do on WIN32 that's just too bad. I'm not
going to cripple the unix version just because we can't do it on win32.
Consider cpu time limits and other resource control stuff -- we may not be
able to do that on win32 yet (5.0 we should). You're saying we shouldn't
do that period, and I'm totally disagreeing with that.
I disagree that we "decided long ago to maintain feature compatibility
across platforms". We certainly don't have it now (consider
OPTIMIZE_TIMEOUT, a performance feature, consider mod_unique_id.c,
consider reliable USR1).
Dean
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> If I'm working on a bug report and fix the bug then I'm committing the fix
> right away. I'm referring to things like that recent "basic auth doesn't
> use case insensitive comparisons". I'm not about to post "oh I'm going to
> fix this bug" and then fix it... that's a waste. CVS merges just fine.
>
> But if I'm working on something more radical, like a util.c rewrite, then
> I will be posting.
The above certainly jibes with my understanding of what we're trying
to set up. The "let people know" I have been taking to mean significant
work such as your vhost rewrite or my .h #ifdef wrapping.
> > > * The CVS tree should be expected to compile at all times;
> > > if it is possible that the code will result in some platforms
> > > not compiling, notice of this should be announced.
>
> ... notice of this can be announced in the CVS commit message, especially
> when it's a trivial change (such as an added .c file).
Works for me.
> > > * Related changes should be posted at once, or very closely
> > > together; no half-baked projects in the code.
>
> Definition of "half-baked" please. Tell me if my "-p" command line switch
> that comes with listenwrap is half-baked; tell me if my mod_allowdev
> module with Dirk's changes to give it run-time config commands is
> half-baked.
Now you're being silly. It seems obvious to me that the sentence means
commit all related changes in a lump, or at least at the same time, and
not half to-day and half next week. If you're doing something big like
rewriting the command loop, or changing a data structure, you
commit all the changes to all the relevant files at once.
> > > * Any changes:
> > > + which affect semantics of arguments to directives
> > > + which would have to be implemented differently on other
> > > architectures
>
> If I want to write code that works on some unixes and provides backwards
> compatibility for other architectures I don't see what is wrong. I've
> done this in the past, and I test with and without the new feature.
> Consider OPTIMIZE_TIMEOUTS, and the half-dozen serialization directives.
On the other hand, if you add something that works *only* on UNIX it's
only fair to give the Win32 folx warning - and if it cannot be done
under Win32 I think it's reasonable that they be able to veto the
change. We decided long ago to maintain feature (if not bug) compatibility
across platforms.
You've got CVS access; Roy invited everyone to comment and make
changes. You want fine-tuning to these guidelines? Go ahead and
do it. But let's get on with it and downsize the endless go-nowhere
discussions..
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Dean Gaudet wrote:
>
> BTW, I like Rob's summarization of this: ideas are r-t-c, code is c-t-r.
> It's a lot easier to remember than a few dozen rules.
It's a lot easier to remember, but it requires a lot more in terms
of judgment calls. And judging from the discussion over the
particulars of the spelt-out details I'm not sure such wide latitude
is safe.
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Dean Gaudet <dg...@arctic.org>.
BTW, I like Rob's summarization of this: ideas are r-t-c, code is c-t-r.
It's a lot easier to remember than a few dozen rules.
Dean
Re: [POLL] experiment with commit-then-review
Posted by Dean Gaudet <dg...@arctic.org>.
On Sun, 18 Jan 1998, Rodent of Unusual Size wrote:
> Okey, this issue has been pretty quiet for a few days.
> Is anyone unhappy with the conditions for c-t-r as specified
> in <http://dev.apache.org/guidelines.html#ctr>? (Reproduced
> below.) If no-one has any heartburn with this, can we please
> say it's a go and get on with it?
>
> Here's the section from the latest guidelines:
>
> > We are exploring a new process to help speed development,
> > "commit-then-review". With a commit-then-review process, we
> > trust that committers have a high degree of confidence in their
> > committed patches --- higher than the typical [PATCH] post to the
> > mailing list.
> > * Advance notice (e.g., "I'll be working on flurgl.c") will
> > be given
If I'm working on a bug report and fix the bug then I'm committing the fix
right away. I'm referring to things like that recent "basic auth doesn't
use case insensitive comparisons". I'm not about to post "oh I'm going to
fix this bug" and then fix it... that's a waste. CVS merges just fine.
But if I'm working on something more radical, like a util.c rewrite, then
I will be posting.
This distinction should be made. Grey areas and all.
> > * The CVS tree should be expected to compile at all times;
> > if it is possible that the code will result in some platforms
> > not compiling, notice of this should be announced.
... notice of this can be announced in the CVS commit message, especially
when it's a trivial change (such as an added .c file).
> > * Experimental new features must be discussed before implemented
> > * The committer is responsible for the quality of the third-party
> > code they bring into the code.
This and the first point cover the same areas.
> > * Related changes should be posted at once, or very closely
> > together; no half-baked projects in the code.
Definition of "half-baked" please. Tell me if my "-p" command line switch
that comes with listenwrap is half-baked; tell me if my mod_allowdev
module with Dirk's changes to give it run-time config commands is
half-baked.
> > * Any changes:
> > + which affect semantics of arguments to directives
> > + which would have to be implemented differently on other
> > architectures
If I want to write code that works on some unixes and provides backwards
compatibility for other architectures I don't see what is wrong. I've
done this in the past, and I test with and without the new feature.
Consider OPTIMIZE_TIMEOUTS, and the half-dozen serialization directives.
Dean
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Okey, this issue has been pretty quiet for a few days.
Is anyone unhappy with the conditions for c-t-r as specified
in <http://dev.apache.org/guidelines.html#ctr>? (Reproduced
below.) If no-one has any heartburn with this, can we please
say it's a go and get on with it?
Here's the section from the latest guidelines:
> We are exploring a new process to help speed development,
> "commit-then-review". With a commit-then-review process, we
> trust that committers have a high degree of confidence in their
> committed patches --- higher than the typical [PATCH] post to the
> mailing list.
> * Advance notice (e.g., "I'll be working on flurgl.c") will
> be given
> * The CVS tree should be expected to compile at all times;
> if it is possible that the code will result in some platforms
> not compiling, notice of this should be announced.
> * Experimental new features must be discussed before implemented
> * The committer is responsible for the quality of the third-party
> code they bring into the code.
> * Related changes should be posted at once, or very closely
> together; no half-baked projects in the code.
> * Any changes:
> + which affect semantics of arguments to directives
> + which would have to be implemented differently on other
> architectures
> + which significantly add to the runtime size of the program
> need to be discussed on the mailing list before it gets committed.
> * A patch must be reversed if the equivalent of a "veto" comes from
> another developer with commit access.
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Randy Terbush <ra...@covalent.net>.
On Sun, Jan 11, 1998 at 11:10:31AM -0500, Rodent of Unusual Size wrote:
> I'm also calling the question on this issue so we can move forward
> one way or another. If it doesn't get enough votes, or it gets
> vetoed, we can stop wasting bandwidth on it for a while. We can
> determine the necessary guidelines (such as when c-t-r is *not*
> appropriate) later IFF we decide to try the experiment.
>
> The question is: Shall we, as a group, experiment with allowing
> commits to the source tree without prior review?
Under the conditions being outlined in the developing document, yes.
+1
Re: [POLL] experiment with commit-then-review
Posted by Martin Kraemer <Ma...@mch.sni.de>.
On Sun, Jan 11, 1998 at 11:10:31AM -0500, Rodent of Unusual Size wrote:
> The question is: Shall we, as a group, experiment with allowing
> commits to the source tree without prior review?
+1, yes. But if we, as group, find out that it fails, we can as well stop
it. But I don't relly think it will.
Martin
--
| S I E M E N S | <Ma...@mch.sni.de> | Siemens Nixdorf
| ------------- | Voice: +49-89-636-46021 | Informationssysteme AG
| N I X D O R F | FAX: +49-89-636-44994 | 81730 Munich, Germany
~~~~~~~~~~~~~~~~My opinions only, of course; pgp key available on request
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Well, with the votes tallied, it looks like we'll be trying the
commit-then-review model.
> * Ken's [POLL] experiment with commit-then-review
> Shall we permit unreviewed commits to the source tree? (Details
> of when it's [in]appropriate to be worked out later.) Vote, please.
> <34...@Golux.Com>
> Status: Ken +1, Randy +1, Ben +1, Martin +1, Dean +1, Brian +1,
> Jim +1, Rob +1, Paul 0, Ralf +1
Now for Stage 2, so we can get down to it:
Is everyone happy with Rob's pithy statement of the guidelines as
"ideas must be review-then-commit, patches can be commit-then-review"?
Dean, Jim, and Ralf have +1ed it, and I'm adding my +1 now.
Obviously, items the submitter isn't sure about or that may fire a
controversy should probably go through review first. What about
enhancements? I think the discussion resulted in their being okey
under the c-t-r method.
What about enhancements during the beta cycle (e.g., right now)?
There have been some comments aired to the effect that we may have
feature-frozen too soon.
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Rob Hartill <ro...@imdb.com>.
On Sun, 11 Jan 1998, Rodent of Unusual Size wrote:
> Rob Hartill wrote:
> >
> > I'd prefer to see an overall plan... if someone else can put it
> > together.
>
> Personally, I'd rather not have a long discussion and a lot of effort
> put into describing the details if there's no certainty we're even
> going to try it. That would be a waste, and there have already been
> some comments floated that we're too much of a debating society.
> I want us to get past the "yeah, let's try it/no, let's not" stage
> first, and work out the details later IFF.
>
> So I guess you're -0, then?
I'm +1 on the change. I just hope it's part of wider changes and
isn't deemed "enough" to settle things down in the short-term.
--
Rob Hartill Internet Movie Database (Ltd)
http://www.moviedatabase.com/ .. a site for sore eyes.
Re: [POLL] experiment with commit-then-review
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Rob Hartill wrote:
>
> I'd prefer to see an overall plan... if someone else can put it
> together.
Personally, I'd rather not have a long discussion and a lot of effort
put into describing the details if there's no certainty we're even
going to try it. That would be a waste, and there have already been
some comments floated that we're too much of a debating society.
I want us to get past the "yeah, let's try it/no, let's not" stage
first, and work out the details later IFF.
So I guess you're -0, then?
#ken P-)}
Re: [POLL] experiment with commit-then-review
Posted by Rob Hartill <ro...@imdb.com>.
On Sun, 11 Jan 1998, Rodent of Unusual Size wrote:
> I'm also calling the question on this issue so we can move forward
> one way or another. If it doesn't get enough votes, or it gets
> vetoed, we can stop wasting bandwidth on it for a while. We can
> determine the necessary guidelines (such as when c-t-r is *not*
> appropriate) later IFF we decide to try the experiment.
>
> The question is: Shall we, as a group, experiment with allowing
> commits to the source tree without prior review?
I'd prefer to see an overall plan... if someone else can put it
together.
Re: [POLL] experiment with commit-then-review
Posted by Brian Behlendorf <br...@organic.com>.
At 11:10 AM 1/11/98 -0500, Rodent of Unusual Size wrote:
>The question is: Shall we, as a group, experiment with allowing
>commits to the source tree without prior review?
+1.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
specialization is for insects brian@organic.com
Re: [POLL] experiment with commit-then-review
Posted by Paul Sutton <pa...@eu.c2.net>.
On Sun, 11 Jan 1998, Rodent of Unusual Size wrote:
> I'm also calling the question on this issue so we can move forward
> one way or another. If it doesn't get enough votes, or it gets
> vetoed, we can stop wasting bandwidth on it for a while. We can
> determine the necessary guidelines (such as when c-t-r is *not*
> appropriate) later IFF we decide to try the experiment.
>
> The question is: Shall we, as a group, experiment with allowing
> commits to the source tree without prior review?
0. I've already outlined my reservations about this.
//pcs