RE: Bumping tags
> From: Roy T. Fielding [mailto:[EMAIL PROTECTED]] > Sent: 01 May 2002 00:09 > >> Well then why are the patches in the tree??? I'm not sure I like the > >> idea of > >> tagging and then tagging just some files. Seems like if we haven't got a > >> stable HEAD we shouldn't be tagging. We got into this whole business of > >> tagging often as a way of avoiding having this sort of thing. Ifw e > >> tagged > >> and it wasn't stable, who cares. Just retag when it is and move on... > >> > >> This seems to be a growing trend and one I think we should stop. > > > > I disagree. I see a lot of value in managing a release by tagging then > > selectively > > picking up showstopper fixes. And the RM should make the decision if this > > is the way he > > wants to get the release out. > > I strongly dislike the action of tagging the tree with a version number > and then moving that tag. If we aren't sure about the version, then the > RM should use a personal tag and only replace it with the real version tag Should we invent an RM prerelease tag which will be removed after the final tag with the version number? > when we are sure. If people aren't willing to run up the version numbers, > then they shouldn't tag them as such until the version is ready for > tarball. > > Justin already showed that an RM can do it this way effectively. Point taken. I'll remember that for my next RM adventure. For this release I'd like to continue like I started (one last bump), so we can get 2.0.36 out the door. And yes, I liked justins method aswell. /me slaps himself for not tagging with STRIKER first... > .Roy Sander
Re: Bumping tags
> >> Well then why are the patches in the tree??? I'm not sure I like the > >> idea of > >> tagging and then tagging just some files. Seems like if we haven't got a > >> stable HEAD we shouldn't be tagging. We got into this whole business of > >> tagging often as a way of avoiding having this sort of thing. Ifw e > >> tagged > >> and it wasn't stable, who cares. Just retag when it is and move on... > >> > >> This seems to be a growing trend and one I think we should stop. > > > > I disagree. I see a lot of value in managing a release by tagging then > > selectively > > picking up showstopper fixes. And the RM should make the decision if this > > is the way he > > wants to get the release out. > > I strongly dislike the action of tagging the tree with a version number > and then moving that tag. If we aren't sure about the version, then the > RM should use a personal tag and only replace it with the real version tag > when we are sure. +1 Running up the version number is not the issue (al least for me). Getting a stable release tagged and rolled is. Enabling the RM to tag then selectively bump the tag to fix showstoppers is proving to be an effective way to get good releases out. Bill
Re: Bumping tags
>> Well then why are the patches in the tree??? I'm not sure I like the >> idea of >> tagging and then tagging just some files. Seems like if we haven't got a >> stable HEAD we shouldn't be tagging. We got into this whole business of >> tagging often as a way of avoiding having this sort of thing. Ifw e >> tagged >> and it wasn't stable, who cares. Just retag when it is and move on... >> >> This seems to be a growing trend and one I think we should stop. > > I disagree. I see a lot of value in managing a release by tagging then > selectively > picking up showstopper fixes. And the RM should make the decision if this > is the way he > wants to get the release out. I strongly dislike the action of tagging the tree with a version number and then moving that tag. If we aren't sure about the version, then the RM should use a personal tag and only replace it with the real version tag when we are sure. If people aren't willing to run up the version numbers, then they shouldn't tag them as such until the version is ready for tarball. Justin already showed that an RM can do it this way effectively. Roy
Re: Bumping tags
> > > It looks like you picked up practically all the changes. Why not just > > > retag 2.0.37? > > I'm +1 for this... > > > You mean, tag HEAD as 2.0.37? > > I didn't want to do that since there were changes I didn't want in there. > > Practically all the changes is just about right ;) > > Well then why are the patches in the tree??? I'm not sure I like the idea of > tagging and then tagging just some files. Seems like if we haven't got a > stable HEAD we shouldn't be tagging. We got into this whole business of > tagging often as a way of avoiding having this sort of thing. Ifw e tagged > and it wasn't stable, who cares. Just retag when it is and move on... > > This seems to be a growing trend and one I think we should stop. I disagree. I see a lot of value in managing a release by tagging then selectively picking up showstopper fixes. And the RM should make the decision if this is the way he wants to get the release out. Bill > > david > >
RE: Bumping tags
> From: David Reid [mailto:[EMAIL PROTECTED]] > Sent: 30 April 2002 10:31 >>> It looks like you picked up practically all the changes. Why not just >>> retag 2.0.37? > > I'm +1 for this... > >> You mean, tag HEAD as 2.0.37? >> I didn't want to do that since there were changes I didn't want in there. >> Practically all the changes is just about right ;) > > Well then why are the patches in the tree??? Because someone committed them. The group hasn't come around dealing with it (which we see all the time). > I'm not sure I like the idea of > tagging and then tagging just some files. Seems like if we haven't got a > stable HEAD we shouldn't be tagging. We got into this whole business of > tagging often as a way of avoiding having this sort of thing. Ifw e tagged > and it wasn't stable, who cares. Just retag when it is and move on... This is exactly why there is an RM IMO. If the HEAD were always stable we wouldn't even need a RM, just running the httpd_roll_release script would be enough then. > This seems to be a growing trend and one I think we should stop. There are only 2 files that have changes since the tag that haven't gone in. One is because the committer advised against including it (apr/configure.in). The second is because there hasn't been group concensus on it, but a flag was raised. In the latter (the ab versioning thing), I thought it better not to burden the public with changing version schemes twice, if that should happen. > david Sander
Re: Bumping tags
> > It looks like you picked up practically all the changes. Why not just > > retag 2.0.37? I'm +1 for this... > You mean, tag HEAD as 2.0.37? > I didn't want to do that since there were changes I didn't want in there. > Practically all the changes is just about right ;) Well then why are the patches in the tree??? I'm not sure I like the idea of tagging and then tagging just some files. Seems like if we haven't got a stable HEAD we shouldn't be tagging. We got into this whole business of tagging often as a way of avoiding having this sort of thing. Ifw e tagged and it wasn't stable, who cares. Just retag when it is and move on... This seems to be a growing trend and one I think we should stop. david
Re: Bumping tags
* Jeff Trawick ([EMAIL PROTECTED]) wrote : > Thom May <[EMAIL PROTECTED]> writes: > > > * Jeff Trawick ([EMAIL PROTECTED]) wrote : > > > I hope to finish testing and commit a change to apxs.in (patch posted > > > Friday) to finish up a set of fixes to allow apxs to work from a > > > binary build. It would be nice if that works in the next release. > > > I may not be done until 1600GMT. > > > > > Could you possibly have a look at the patch that Pier and I sent to the list > > a few times for apxs? I think it ought to fix most of what you are looking > > at... > > I think I see what you meant by your suggestion that the patch would > fix what I was looking at... I'm playing with the one Pier posted > (April 27), but it doesn't seem to have a fix to make "httpd -l" work > with a binary distribution install. I see an earlier patch you posted > (April 9) that set LD_LIBRARY_PATH, but LD_LIBRARY_PATH isn't portable > (the envvars file owns that problem, so it is best to source the > envvars file). Also, I don't see the need to set the > LD_LIBRARY_PATH-type variable unless it is a binbuild. Did you > encounter another situation where it is needed? > We were needing LD_LIBRARY_PATH to allow httpd to run when it had been relocated. cheers, -Thom -- Thom May -> [EMAIL PROTECTED] US elections: For those of you fearing that the rest of the world might be making fun of the US because of this: Rest assured, we are.
Re: Bumping tags
Sander Striker wrote: > > Hi, > > I am bumping tags today. There have been a number of commits since > the tag that should make it to release IMO. Actually, most of them > should go in. [...] > It would be nice if we could bump daedalus to the new tag and give > this another 1-2 days on there. OK. I'll assume the tag is reasonable stable, and start building it. Greg
Re: Bumping tags
Thom May <[EMAIL PROTECTED]> writes: > * Jeff Trawick ([EMAIL PROTECTED]) wrote : > > I hope to finish testing and commit a change to apxs.in (patch posted > > Friday) to finish up a set of fixes to allow apxs to work from a > > binary build. It would be nice if that works in the next release. > > I may not be done until 1600GMT. > > > Could you possibly have a look at the patch that Pier and I sent to the list > a few times for apxs? I think it ought to fix most of what you are looking > at... I think I see what you meant by your suggestion that the patch would fix what I was looking at... I'm playing with the one Pier posted (April 27), but it doesn't seem to have a fix to make "httpd -l" work with a binary distribution install. I see an earlier patch you posted (April 9) that set LD_LIBRARY_PATH, but LD_LIBRARY_PATH isn't portable (the envvars file owns that problem, so it is best to source the envvars file). Also, I don't see the need to set the LD_LIBRARY_PATH-type variable unless it is a binbuild. Did you encounter another situation where it is needed? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Bumping tags
"Sander Striker" <[EMAIL PROTECTED]> writes: > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > > Sent: 29 April 2002 13:23 > > > "Sander Striker" <[EMAIL PROTECTED]> writes: > > > > > I am bumping tags today. There have been a number of commits since > > > the tag that should make it to release IMO. > > > > I hope to finish testing and commit a change to apxs.in (patch posted > > Friday) to finish up a set of fixes to allow apxs to work from a > > binary build. It would be nice if that works in the next release. > > I may not be done until 1600GMT. > > Drop me a line when it is in place. Right now it looks like my apxs.in patch is queued up behind Thom Mays' & Pier's patch. I withdraw my previous time target :) > > It looks like you picked up practically all the changes. Why not just > > retag 2.0.37? > > You mean, tag HEAD as 2.0.37? yes -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Bumping tags
Thom May <[EMAIL PROTECTED]> writes: > * Jeff Trawick ([EMAIL PROTECTED]) wrote : > > "Sander Striker" <[EMAIL PROTECTED]> writes: > > > > > I am bumping tags today. There have been a number of commits since > > > the tag that should make it to release IMO. > > > > I hope to finish testing and commit a change to apxs.in (patch posted > > Friday) to finish up a set of fixes to allow apxs to work from a > > binary build. It would be nice if that works in the next release. > > I may not be done until 1600GMT. > > > Could you possibly have a look at the patch that Pier and I sent to the list > a few times for apxs? I think it ought to fix most of what you are looking > at... I don't see the connection, other than that our patches probably conflict :) Your patch looks reasonable at first glance, but I haven't played with it enough to feel comfortable committing it. All I can promise at the moment is that I'll defer committing mine until I or somebody else has a chance to review and commit your patch. -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Re: Bumping tags
* Jeff Trawick ([EMAIL PROTECTED]) wrote : > "Sander Striker" <[EMAIL PROTECTED]> writes: > > > I am bumping tags today. There have been a number of commits since > > the tag that should make it to release IMO. > > I hope to finish testing and commit a change to apxs.in (patch posted > Friday) to finish up a set of fixes to allow apxs to work from a > binary build. It would be nice if that works in the next release. > I may not be done until 1600GMT. > Could you possibly have a look at the patch that Pier and I sent to the list a few times for apxs? I think it ought to fix most of what you are looking at... Cheers, -Thom -- Thom May -> [EMAIL PROTECTED] * edward just installed gbuffy (mail notifier) Dang. How disappointing. not the GNU Vampire Slayer? I was hoping for some sort of Sarah Michelle Gellar thing. :) infinity: you wanted a vampire slayer on your desktop? (female version of gblade I guess) shouldn't gbuffy deal with zombie processes or something? ok joey you beat us all :P
RE: Bumping tags
> From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Jeff Trawick > Sent: 29 April 2002 13:23 > "Sander Striker" <[EMAIL PROTECTED]> writes: > > > I am bumping tags today. There have been a number of commits since > > the tag that should make it to release IMO. > > I hope to finish testing and commit a change to apxs.in (patch posted > Friday) to finish up a set of fixes to allow apxs to work from a > binary build. It would be nice if that works in the next release. > I may not be done until 1600GMT. Drop me a line when it is in place. > It looks like you picked up practically all the changes. Why not just > retag 2.0.37? You mean, tag HEAD as 2.0.37? I didn't want to do that since there were changes I didn't want in there. Practically all the changes is just about right ;) Sander
Re: Bumping tags
"Sander Striker" <[EMAIL PROTECTED]> writes: > I am bumping tags today. There have been a number of commits since > the tag that should make it to release IMO. I hope to finish testing and commit a change to apxs.in (patch posted Friday) to finish up a set of fixes to allow apxs to work from a binary build. It would be nice if that works in the next release. I may not be done until 1600GMT. It looks like you picked up practically all the changes. Why not just retag 2.0.37? -- Jeff Trawick | [EMAIL PROTECTED] Born in Roswell... married an alien...
Bumping tags
Hi, I am bumping tags today. There have been a number of commits since the tag that should make it to release IMO. Actually, most of them should go in. Files marked with a [T] will have their tag bumped. Files marked with [-] won't. I have included the logs of the changes for your convenience. Lines marked RM: are lines with my commentary. It would be nice if we could bump daedalus to the new tag and give this another 1-2 days on there. I am aiming for release on wednesday. By then it should be possible to have made a decission/have a solution on the atomics issue. Sander = httpd-2.0 = [T] CHANGES RM: Will be updated prior to retagging. - [T] Makefile.in (1.107) aaron Log: Don't install *.in config files. - [T] STATUS RM: Quite a few updates. I see no harm in bumping the tag on this. - [T] build/install-bindist.sh.in (1.7) trawick Log: get closer to having apxs work from a binary distribution we need to copy libtool and instdso.sh verbatim, and we need to edit config_vars.mk and apxs still broken: "httpd -l" as invoked by apxs can fail since support libraries (apr, aprutil, etc.) are probably not findable - [T] docs/manual/howto/ssi.html.en(1.11) [T] docs/manual/mod/mod_alias.xml(1.5) [T] docs/manual/vhosts/examples.html (1.10) RM: documentation changes always have to go in IMO. - [T] include/http_config.h (1.97) aaron Log: Style cleanup (remove tabs, fix alignment). - [T] modules/aaa/mod_auth_digest.c (1.62) fielding Log: kill a warning on Darwin for NONCE_LEN becoming a long int by math. - [T] modules/arch/win32/mod_isapi.c (1.64) wrowe Log: After review and testing against all of the PSDK examples (see http://www.apache.org/~wrowe/ for commentary on building the examples and making them work) ... this disable-optimization should no longer be required. - [T] modules/experimental/mod_ext_filter.c (1.27) wrowe Log: Trade one signedness mismatch for another, but choose the one that is known to be a positive value. - [T] modules/http/http_request.c (1.141) jerenkrantz Log: If a subreq added a filter (say INCLUDES) and the subreq was promoted via fast_redirect, the filter would still point at the subreq - rather than the original r. So, we must update any filters pointing at rr to be r. This would cause lots of problems with mod_include with mod_dir requests such as seen in PR 7966. mod_include would be unsetting the headers_out of rr instead of r. But, we disassociate rr->headers_out and r->headers_out. Therefore, the C-L header in r->headers_out would remain - even though it bears no relation to what we will be outputting - causing problems. This also now permits chunked-encoding of mod_dir/mod_include requests which could never happen before and fixes the content-length problem seen in PR 7966. As hinted at in PR 7966, there is a race condition - if for some reason the server stalls reading an included file (or even better, placing a sleep in the cgi-bin script!), the invalid C-L may get propogated to the client. (Note that internal_internal_redirect has this same code fragment.) PR: 7966 - [T] modules/mappers/mod_imap.c (1.39) stoddard Log: Fix spelling/typo brianp Log: Because mod_imap's handler runs on every request in the default configuration, rearrange the code to keep it from allocating a few pages worth of local variables on the stack on requests that don't use imagemaps - [T] modules/mappers/mod_userdir.c (1.46) brianp Log: Short-circuit out of mod_userdir's translation handler faster on non "/~*" requests - [T] modules/metadata/mod_unique_id.c (1.37) trawick Log: Allow mod_unique_id to work on systems with no IPv4 address corresponding to their host name. trawick Log: fix a compiler error with picky compilers that (correctly) don't let you add to void * - [T] modules/proxy/mod
