You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by "William A. Rowe, Jr." <wr...@rowe-clan.net> on 2001/02/11 22:01:32 UTC
Re: cvs commit: apr/include apr.hw
> wrowe 01/02/11 12:34:54
>
> Modified: include apr.hw
> Log:
> Fix the broken support utilities (htdigest/htpasswd) on Win32. Won't
> strictly put this on [signals hacker] since we should have defined this
> HAVE_SIGNAL_H symbol, and not simply -included- the header in the first
> place. Note that win32 begs for a complete replacement of their clib
> signal support, I'll put that on my 'short' list and look at the old
> win32 signal code hiding in the attic.
As this commit implies, Win32 doesn't work from the last tag :-(
BTW ... Ryan, I agree a numeric tag, rather than date, makes more sense.
Win32 is building again [as of this moment.]
Re: cvs commit: apr/include apr.hw
Posted by rb...@covalent.net.
> > This is what was scaring me BTW. I have rolled three times this week, and
> > each time there has been some OS that didn't work. The first time it was
> > OS/2, then BeOS, now Windows. It seems to me that because we aren't
> > freezing the tree and asking people to work on stabilizing the code, we
> > are likely to continue to hit this problem. The big problem is that we
> > have four very different platforms, and it is too easy to accidentally
> > break one when fixing another. That is a problem, but it is a problem
> > that we aren't fixing right now, so not asking for some sort of code
> > freeze is going to continue to cause these problems IMHO.
>
> Ryan, the problem is that you are making significant changes that
> effect builds (moving prototypes and creating new header files) and then
> tagging the tree before verifying that it builds on the major platforms.
Take a second look. The first tag was three days after the scoreboard
change that broke OS/2. The second was almost a week after (the same
scoreboard change is what broke BeOS), the third change is the only one
that was done immediately following a major change, and that was only
after I had two people tell me to go ahead and tag, and since I wanted to
test my script, I did.
> What not freezing does affect is the probability that someone *other*
> than the RM may make a significant change just prior to the tag.
> Personally, I never encountered that problem as RM.
>
> BTW, when I said that we needed to build more often, I meant once a week
> at most. Otherwise, people won't feel it is important to test the
> last build.
As I said when I started this, I was going to roll multiple times, to help
get the process correct. If I had tagged and rolled once a week, then the
process would have taken three weeks to get down. As it is, I believe we
have got the process after one week.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/include apr.hw
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> This is what was scaring me BTW. I have rolled three times this week, and
> each time there has been some OS that didn't work. The first time it was
> OS/2, then BeOS, now Windows. It seems to me that because we aren't
> freezing the tree and asking people to work on stabilizing the code, we
> are likely to continue to hit this problem. The big problem is that we
> have four very different platforms, and it is too easy to accidentally
> break one when fixing another. That is a problem, but it is a problem
> that we aren't fixing right now, so not asking for some sort of code
> freeze is going to continue to cause these problems IMHO.
Ryan, the problem is that you are making significant changes that
effect builds (moving prototypes and creating new header files) and then
tagging the tree before verifying that it builds on the major platforms.
Of course that isn't going to work. Freezing the tree won't help.
There is no reason to tag the tree just after you have made a change
that is likely to affect other platforms. Wait until after it has been
built by others, or get Sam to make his tinderbox software available for
automated build checks.
What not freezing does affect is the probability that someone *other*
than the RM may make a significant change just prior to the tag.
Personally, I never encountered that problem as RM.
BTW, when I said that we needed to build more often, I meant once a week
at most. Otherwise, people won't feel it is important to test the
last build.
....Roy
Re: cvs commit: apr/include apr.hw
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 12, 2001 at 01:00:17PM -0500, Bill Stoddard wrote:
> > rbb@covalent.net wrote:
> > >
> > > This is not the model being used currently. This is in fact the
> > > model I am asking for. What is currently being proposed however,
> > > is no code freezes, ever.
> >
> > I am with Roy on that; code freezes have never worked well for us
> > (probably because the RM has no authority), and they have
> > been nothing but PITAs.
I'm with Roy and Ken.
> I generally agree but an exception should be made for the first (few?) Apache
> 2.0 beta release.
>
> We are looking to get as much feedback from our early beta releases as
> possible. If we release a beta that only compiles on, say, OS390, what have we
> accomplished? Oh, you want to make sure Apache on Linux/FreeBSD builds before
> you do the beta? Well isn't that effectively a freeze :-) ? That is why I
> advocated a small freeze window (I recommended two days, could be a little as
> 12 hours) that is fixed and non-negotiable.
But if it doesn't compile on a lot of platforms, then it won't be called
"beta", now will it?
We snap a copy when it "feels good" and then begin testing it as a candidate
for beta. We do one of three things with it:
1) dump it as just too broken
2) release it as an alpha
3) release it as a beta
Code freezes aren't needed. Personally, I know that we're shooting for a
beta. I'm not going to be revamping the functionality of the code. Sure,
I've done some breakage the past few days, but that has all been
compile-time rather than run-time. i.e. easily solvable
There are two camps: those that require rules to enforce discipline, and
those that require trust to enforce discipline. I prefer the latter.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs commit: apr/include apr.hw
Posted by Bill Stoddard <bi...@wstoddard.com>.
> rbb@covalent.net wrote:
> >
> > This is not the model being used currently. This is in fact the
> > model I am asking for. What is currently being proposed however,
> > is no code freezes, ever.
>
> I am with Roy on that; code freezes have never worked well for us
> (probably because the RM has no authority), and they have
> been nothing but PITAs.
I generally agree but an exception should be made for the first (few?) Apache
2.0 beta release.
We are looking to get as much feedback from our early beta releases as
possible. If we release a beta that only compiles on, say, OS390, what have we
accomplished? Oh, you want to make sure Apache on Linux/FreeBSD builds before
you do the beta? Well isn't that effectively a freeze :-) ? That is why I
advocated a small freeze window (I recommended two days, could be a little as
12 hours) that is fixed and non-negotiable.
Bill
Re: cvs commit: apr/include apr.hw
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
rbb@covalent.net wrote:
>
> This is not the model being used currently. This is in fact the
> model I am asking for. What is currently being proposed however,
> is no code freezes, ever.
I am with Roy on that; code freezes have never worked well for us
(probably because the RM has no authority), and they have
been nothing but PITAs.
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: cvs commit: apr/include apr.hw
Posted by rb...@covalent.net.
> > This is what was scaring me BTW. I have rolled three times this week, and
> > each time there has been some OS that didn't work. The first time it was
> > OS/2, then BeOS, now Windows. It seems to me that because we aren't
> > freezing the tree and asking people to work on stabilizing the code, we
> > are likely to continue to hit this problem. The big problem is that we
> > have four very different platforms, and it is too easy to accidentally
> > break one when fixing another. That is a problem, but it is a problem
> > that we aren't fixing right now, so not asking for some sort of code
> > freeze is going to continue to cause these problems IMHO.
> >
>
> The build breaks are a temporary problem (I hope :-) and should become less
> and less frequent over time as we eliminate OS specific code paths & include
> trees in Apache proper. When we decide to begin driving for a beta release,
> we should freeze commits not required to get all the OSes building for
> a -short- period of time, perhaps 2 days max. Announce the intent to tag a
> beta candidate, give everyone a couple of days to get all the builds working,
> then tag and roll and unfreeze. If you miss the window, then catch it next
> time around. "Release early & release often"!
This is not the model being used currently. This is in fact the model I
am asking for. What is currently being proposed however, is no code
freezes, ever.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: cvs commit: apr/include apr.hw
Posted by Bill Stoddard <bi...@wstoddard.com>.
> On Sun, 11 Feb 2001, William A. Rowe, Jr. wrote:
>
> > > Fix the broken support utilities (htdigest/htpasswd) on Win32.
Won't
> > > strictly put this on [signals hacker] since we should have defined
this
> > > HAVE_SIGNAL_H symbol, and not simply -included- the header in the
first
> > > place. Note that win32 begs for a complete replacement of their
clib
> > > signal support, I'll put that on my 'short' list and look at the old
> > > win32 signal code hiding in the attic.
> >
> > As this commit implies, Win32 doesn't work from the last tag :-(
> >
> > BTW ... Ryan, I agree a numeric tag, rather than date, makes more sense.
> >
> > Win32 is building again [as of this moment.]
>
> This is what was scaring me BTW. I have rolled three times this week, and
> each time there has been some OS that didn't work. The first time it was
> OS/2, then BeOS, now Windows. It seems to me that because we aren't
> freezing the tree and asking people to work on stabilizing the code, we
> are likely to continue to hit this problem. The big problem is that we
> have four very different platforms, and it is too easy to accidentally
> break one when fixing another. That is a problem, but it is a problem
> that we aren't fixing right now, so not asking for some sort of code
> freeze is going to continue to cause these problems IMHO.
>
The build breaks are a temporary problem (I hope :-) and should become less
and less frequent over time as we eliminate OS specific code paths & include
trees in Apache proper. When we decide to begin driving for a beta release,
we should freeze commits not required to get all the OSes building for
a -short- period of time, perhaps 2 days max. Announce the intent to tag a
beta candidate, give everyone a couple of days to get all the builds working,
then tag and roll and unfreeze. If you miss the window, then catch it next
time around. "Release early & release often"!
Bill
Re: cvs commit: apr/include apr.hw
Posted by rb...@covalent.net.
On Sun, 11 Feb 2001, William A. Rowe, Jr. wrote:
> > Fix the broken support utilities (htdigest/htpasswd) on Win32. Won't
> > strictly put this on [signals hacker] since we should have defined this
> > HAVE_SIGNAL_H symbol, and not simply -included- the header in the first
> > place. Note that win32 begs for a complete replacement of their clib
> > signal support, I'll put that on my 'short' list and look at the old
> > win32 signal code hiding in the attic.
>
> As this commit implies, Win32 doesn't work from the last tag :-(
>
> BTW ... Ryan, I agree a numeric tag, rather than date, makes more sense.
>
> Win32 is building again [as of this moment.]
This is what was scaring me BTW. I have rolled three times this week, and
each time there has been some OS that didn't work. The first time it was
OS/2, then BeOS, now Windows. It seems to me that because we aren't
freezing the tree and asking people to work on stabilizing the code, we
are likely to continue to hit this problem. The big problem is that we
have four very different platforms, and it is too easy to accidentally
break one when fixing another. That is a problem, but it is a problem
that we aren't fixing right now, so not asking for some sort of code
freeze is going to continue to cause these problems IMHO.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------