You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@jaguNET.com> on 2007/08/13 02:03:00 UTC
Notice of Intent: T&R 2.0.61
Just a FYI: I'm planning on doing a T&R of 2.0.61 tomorrow (Aug 13);
It's a retag of 2.0.60 (plus the version bump, 'natch), and a reroll
with the singular exception of bundling APR 0.9.12, instead of 0.9.14.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: new mime type needed?
Posted by Arturo 'Buanzo' Busleiman <bu...@buanzo.com.ar>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Guenter Knauf wrote:
> application/x-7-zip 7z
Some GNU/Linux distributions already add it!
- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
Servicios Ofrecidos: http://www.buanzo.com.ar/pro/
Unase a los Foros GNU/Buanzo - La palabra Comunidad en su maxima expresion.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHMdz0AlpOsGhXcE0RCg6SAKCCB7SZP/GB4N4TTUugWgf2swxOqACdG5Fz
QoGVBluTJrKRmxc5AyUIgvc=
=H836
-----END PGP SIGNATURE-----
Re: new mime type needed?
Posted by Nikolas Coukouma <at...@atrus.org>.
Julian Reschke wrote:
> Guenter Knauf wrote:
>> Hi,
>> just another compression utility is going to become very popular:
>> http://www.7-zip.org/
>> and there's also a commandline for Unix / Win32:
>> http://sourceforge.net/projects/p7zip/
>>
>> maybe we should add the .7z extension to the httpd mime.types file?
>> perhaps something like:
>>
>> application/x-7-zip 7z
>
> ...pointing out the obvious: the mime type should be registered with
> IANA first.
IANA registration would certainly be nice and proper. I'll note,
however, that many of the types already in mime.types are in the same
unofficial boat as 7zip (e.g. application/x-bzip2). I'm more concerned
with whether or not the suggested entry is already in use or serving
application/x-7-zip would be helpful (compared to
application/octet-stream). Some searching indicates that the following
is the de-facto standard:
application/x-7z-compressed 7z
More on x- types:
RFC 4288:
3.4. Special x. Tree
For convenience and symmetry with this registration scheme, subtype
names with "x." as the first facet may be used for the same purposes
for which names starting in "x-" are used. These types are
unregistered, experimental, and for use only with the active
agreement of the parties exchanging them.
However, with the simplified registration procedures described above
for vendor and personal trees, it should rarely, if ever, be
necessary to use unregistered experimental types. Therefore, use of
both "x-" and "x." forms is discouraged.
Types in this tree MUST NOT be registered.
Cheers,
-Nikolas
Re: new mime type needed?
Posted by Julian Reschke <ju...@gmx.de>.
Guenter Knauf wrote:
> Hi,
> just another compression utility is going to become very popular:
> http://www.7-zip.org/
> and there's also a commandline for Unix / Win32:
> http://sourceforge.net/projects/p7zip/
>
> maybe we should add the .7z extension to the httpd mime.types file?
> perhaps something like:
>
> application/x-7-zip 7z
>
>
> Guen.
...pointing out the obvious: the mime type should be registered with
IANA first.
BR, Julian
new mime type needed?
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
just another compression utility is going to become very popular:
http://www.7-zip.org/
and there's also a commandline for Unix / Win32:
http://sourceforge.net/projects/p7zip/
maybe we should add the .7z extension to the httpd mime.types file?
perhaps something like:
application/x-7-zip 7z
Guen.
Re: update for http://www.apache.org/dist/httpd needed... /resend
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Closed the bug so nobody else goes to 'fix' this ;-)
Jim Jagielski wrote:
> Thanks... changed on people so it'll update at the next rsync
>
> On Nov 7, 2007, at 9:31 AM, Guenter Knauf wrote:
>
>> Hi,
>> the file / link:
>> http://www.apache.org/dist/httpd/CURRENT-IS-2.2.4
>> seems no longer correct.....
>>
>> Guen.
Re: update for http://www.apache.org/dist/httpd needed... /resend
Posted by Jim Jagielski <ji...@jaguNET.com>.
Thanks... changed on people so it'll update at the next rsync
On Nov 7, 2007, at 9:31 AM, Guenter Knauf wrote:
> Hi,
> the file / link:
> http://www.apache.org/dist/httpd/CURRENT-IS-2.2.4
> seems no longer correct.....
>
> Guen.
>
>
update for http://www.apache.org/dist/httpd needed... /resend
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
the file / link:
http://www.apache.org/dist/httpd/CURRENT-IS-2.2.4
seems no longer correct.....
Guen.
Re: [PROPOSAL] introduce a global define for including unixd.h
Posted by Jeff Trawick <tr...@gmail.com>.
On Dec 7, 2007 2:43 PM, Guenter Knauf <fu...@apache.org> wrote:
> Hi,
> I came a couple of times already over the ifdefs to avoid the inclusion of unixd.h;
> also many 3rd party modules have this problem;
> therefore I would like to see a global define somewhere for that, f.e.
> AP(R?)_NEEDS_UNIXD_H or such; can we perhaps introduce that?
> This would in future avoid such platform-ifdefs like this:
> http://svn.apache.org/viewvc?view=rev&revision=522933
Backing up a little, the interesting part that requires that header file is
#if !defined(OS2) && !defined(WIN32) && !defined(BEOS) && !defined(NETWARE)
if (geteuid() == 0) {
chown(fsc->limitdbfile, unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc->limitdbfile, ".LoCK", NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc->limitdbfile, ".db", NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc->limitdbfile, ".dir", NULL),
unixd_config.user_id, -1);
chown(apr_pstrcat(p, fsc->limitdbfile, ".pag", NULL),
unixd_config.user_id, -1);
}
#endif
Consider providing a function in core that sets ownership of a file to
the user id of web server child processes when appropriate, and let
the file that implements that function worry about whether or not
unixd.h is needed. All platforms can implement the function, no-op or
not.
ssl_scache_dbm.c has chown() logic like that above. I don't know if
there are slight variations which should be accommodated.
[PROPOSAL] introduce a global define for including unixd.h
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
I came a couple of times already over the ifdefs to avoid the inclusion of unixd.h;
also many 3rd party modules have this problem;
therefore I would like to see a global define somewhere for that, f.e.
AP(R?)_NEEDS_UNIXD_H or such; can we perhaps introduce that?
This would in future avoid such platform-ifdefs like this:
http://svn.apache.org/viewvc?view=rev&revision=522933
thanks, Guen.
update for http://www.apache.org/dist/httpd needed...
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
the file / link:
http://www.apache.org/dist/httpd/CURRENT-IS-2.2.4
seems no longer correct.....
Guen.
Re: Most likely 1.3 1st then 2.x
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 24, 2007, at 7:47 PM, Sander Temme wrote:
> Ruediger Pluem wrote:
>
>> On 08/24/2007 02:54 PM, Jim Jagielski wrote:
>>> To be honest, I can't see holding off the 1.3 release any longer
>>> while we're waiting on APR as well as stuff is being added
>>> to the 2.x trees... It's kind of embarrassing.
>
> +1.
>
>> As far as I understand this "downgrade" scenario is one of the
>> reasons
>> why we aim to release all stable branches at the same point of time.
>
> It might help to keep the release quiet: put the code out there and
> update the page, but keep it off the front page and out of the public
> channels.
>
> We can even do the same for 2.0.x once we have our regression
> fixed, and
> then make a splash for all three when 2.2.x is done.
>
This is all well and good, except, to be honest, how confident
are we that 2.x will be released any time soon? If they
were, I'd say wait and release/announce all 3 together.
We've pushed back the releases at least 3 times already;
1.3 is ready; 2.0 and 2.2 aren't, yet, and we have no
real idea when then will be. Like I said, I can't
see keeping 1.3.38 from our 1.3 users simply because
2.x isn't ready....
Re: Most likely 1.3 1st then 2.x
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sander Temme wrote:
>
> We can even do the same for 2.0.x once we have our regression fixed, and
> then make a splash for all three when 2.2.x is done.
2.0 and 2.2 both have piped log issues.
For 2.0 this is slightly more critical, we still invoke the log pipe app
directly, and then pid_kill the thing on plog teardown. This means
there is a lag between now-dead logger and new open_logs hook, which
is especially uncool. On 2.2 it's not quite so bad, since we pid_kill
bin/sh leaving bin/sh's invoked process running.
r569535 doesn't quite clean on either 2.0 or 2.2, so I'll post up the link
a bit later to tweaked patches.
Re: Most likely 1.3 1st then 2.x
Posted by Sander Temme <sc...@apache.org>.
Ruediger Pluem wrote:
> On 08/24/2007 02:54 PM, Jim Jagielski wrote:
>> To be honest, I can't see holding off the 1.3 release any longer
>> while we're waiting on APR as well as stuff is being added
>> to the 2.x trees... It's kind of embarrassing.
+1.
> As far as I understand this "downgrade" scenario is one of the reasons
> why we aim to release all stable branches at the same point of time.
It might help to keep the release quiet: put the code out there and
update the page, but keep it off the front page and out of the public
channels.
We can even do the same for 2.0.x once we have our regression fixed, and
then make a splash for all three when 2.2.x is done.
S.
Re: Most likely 1.3 1st then 2.x
Posted by Ruediger Pluem <rp...@apache.org>.
On 08/24/2007 02:54 PM, Jim Jagielski wrote:
>
> To be honest, I can't see holding off the 1.3 release any longer
> while we're waiting on APR as well as stuff is being added
> to the 2.x trees... It's kind of embarrassing.
>
> So even though I have most of the files setup for triple
> release, I think next week I'll just release 1.3 and we
> can the release 2.x when ready and not continue to hold
> our 1.3 users hostage.
+1. I think the number of people going back to 1.3 from 2.0 / 2.2
because this 1.3 release is "newer" than the latest 2.0 / 2.2 release
is comparable low.
As far as I understand this "downgrade" scenario is one of the reasons
why we aim to release all stable branches at the same point of time.
Regards
Rüdiger
Most likely 1.3 1st then 2.x
Posted by Jim Jagielski <ji...@jaguNET.com>.
To be honest, I can't see holding off the 1.3 release any longer
while we're waiting on APR as well as stuff is being added
to the 2.x trees... It's kind of embarrassing.
So even though I have most of the files setup for triple
release, I think next week I'll just release 1.3 and we
can the release 2.x when ready and not continue to hold
our 1.3 users hostage.
Hopefully soon...
Posted by Jim Jagielski <ji...@jaguNET.com>.
Sorry for the delay, but we are still held up with the APR
release and some piped logging regressions... Hopefully
once APR is released, it will be stable enough to allow
us to do some quicker turn-arounds for T&Rs...
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Rainer Jung <ra...@kippdata.de>.
Guenter Knauf wrote:
> may I ask a question on this topic: why is piped logging so
> important, and why dont we add f.e. mod_log_rotate which does the job
> of rotating logs more nicerly on every platform? That would avoid 95%
> usage of piped logging:
> http://www.hexten.net/wiki/index.php/Mod-log-rotate
piped logging enables rotation for any kind of log file (at least log
files of the modules that use the piped logging API). Examples:
- SSL log
- rewrite log
- mod_jk log
So it's not only about access logging.
> sure, maybe there are other implementations like mysqllog or
> pgsqllog, and such which use piped logging; however I've tried
> already a lot, and none of all these 'solutions' work really
> reliable...
>
> Guen.
Regards,
Rainer
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Guenter Knauf <fu...@apache.org>.
Hi,
> The fact that the apr_proc* API is so horribly convoluted yet still
> broken on Win32 is kind of ironic. If it's not fixable can we just
> abandon it? The code to implement piped loggers can be much simpler and
> more efficient on Unix if implemented natively.
may I ask a question on this topic:
why is piped logging so important, and why dont we add f.e. mod_log_rotate which does the job of rotating logs more nicerly on every platform? That would avoid 95% usage of piped logging:
http://www.hexten.net/wiki/index.php/Mod-log-rotate
sure, maybe there are other implementations like mysqllog or pgsqllog, and such which use piped logging; however I've tried already a lot, and none of all these 'solutions' work really reliable...
Guen.
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
William A. Rowe, Jr. wrote:
>
> Jim Jagielski wrote:
> >
> > Of course, releases can't be vetoed, but doing further research
> > indicates that Bill looks to be spot on with this issue...
>
> The point is, this was released. Iteratively. I'm just not in a mood
> to keep +1'ing releases while the code remains in this broken state.
>
In case I wasn't clear, as RM I'm cool with holding off on 2.2.6
until this is fixed. But as a matter of policy, one cannot veto
a release; that was the only point I was making.
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
>
> Of course, releases can't be vetoed, but doing further research
> indicates that Bill looks to be spot on with this issue...
The point is, this was released. Iteratively. I'm just not in a mood
to keep +1'ing releases while the code remains in this broken state.
It becomes more complex when you factor in the issue that on restart
today we are losing stderr before we go through the process of the
next restart loop. The recent patch sort-of-half fixed things, and
they understood the issue, but at least on windows the stderr pipe
was still inherited, so the logprocess still would not die until the
last generation had been killed.
It looks that leaving plog alone until we've run the new open log
phase, then closing the older plog, combined with setting the old
stderr pipe as not-inherited before we launch the new stderr pipe
and replace stderr, we go a significant distance to fix this error.
If my understanding on the dev@apr thread is correct, the issue further
resolves itself with better win (os2? netware?) apr create_process
changes. If not, it's another flaw in log.c to correct.
My current stomach ache is mpm_winnt, which is also leaving inherited
resources around long enough to be picked up by the logging processes.
Once I'm done isolating those, it's a matter of ensuring what still
goes on with launching cgi processes, and then the situation should
be much better all the way around.
Bill
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 20, 2007, at 4:36 PM, William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>> Status Update:
>> There are issues in the current shipping version of
>> APR 0.9 that must be resolved before we can reroll 2.0.x.
>> Furthermore, there are issues in APR 1.2 that should be
>> fixed (although not regression related) before we redo
>> 2.2.x... Once APR is tagged and rolled, we will use
>> that to T&R 2.0.x and 2.2.x.
>>
>> If APR takes too much longer I may reconsider going
>> ahead and releasing the 2.2.5 tarball anyway,
>> since I don't want to delay 1.3/2.2 much further.
>> We *need* to wait for 0.9 for 2.0 because of
>> the regression...
>
> It turns out that in 2.2, we have a regression 8 mos old.
> Unfortunately
> we didn't pick up on it, because piped logs aren't something that the
> perl-framework understands.
>
> The crux of the problem is that we create processes without a full
> host
> of three fd's. Then we inflict them against sh. Linux/bash
> doesn't seem
> to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/
> sh are
> not going to like this situation either. Obviously win32 minded,
> but this
> is an artifact of how we assembled things.
>
> We need three fd's to each logger process, but it's not as simple
> as that.
> We've collectively tacked on so much bubblegum and bailing wire
> trying to
> make the piped logger behave that it's missing any sensibility :) I'm
> trying to restore that back to a working state.
>
> I'd be +1 to releasing 2.2.6 today if we simply wanted to back out the
> entire pile of cruft added since we started invoking /bin/sh to launch
> log pipes. Till it behaves sensibly, I'll be -1 on release.
Of course, releases can't be vetoed, but doing further research
indicates that Bill looks to be spot on with this issue...
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Joe Orton <jo...@redhat.com>.
On Mon, Aug 20, 2007 at 03:36:59PM -0500, William Rowe wrote:
> The crux of the problem is that we create processes without a full host
> of three fd's. Then we inflict them against sh. Linux/bash doesn't seem
> to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are
> not going to like this situation either.
Why not? This is not unusual behaviour for Unix.
> Obviously win32 minded, but this is an artifact of how we assembled
> things.
As I mentioned before, why not just fix the apr_proc* implementation on
Win32?
The fact that the apr_proc* API is so horribly convoluted yet still
broken on Win32 is kind of ironic. If it's not fixable can we just
abandon it? The code to implement piped loggers can be much simpler and
more efficient on Unix if implemented natively.
joe
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Status Update:
> There are issues in the current shipping version of
> APR 0.9 that must be resolved before we can reroll 2.0.x.
> Furthermore, there are issues in APR 1.2 that should be
> fixed (although not regression related) before we redo
> 2.2.x... Once APR is tagged and rolled, we will use
> that to T&R 2.0.x and 2.2.x.
>
> If APR takes too much longer I may reconsider going
> ahead and releasing the 2.2.5 tarball anyway,
> since I don't want to delay 1.3/2.2 much further.
> We *need* to wait for 0.9 for 2.0 because of
> the regression...
It turns out that in 2.2, we have a regression 8 mos old. Unfortunately
we didn't pick up on it, because piped logs aren't something that the
perl-framework understands.
The crux of the problem is that we create processes without a full host
of three fd's. Then we inflict them against sh. Linux/bash doesn't seem
to mind, but solaris sh, and I'm guessing aix and hpux stock /bin/sh are
not going to like this situation either. Obviously win32 minded, but this
is an artifact of how we assembled things.
We need three fd's to each logger process, but it's not as simple as that.
We've collectively tacked on so much bubblegum and bailing wire trying to
make the piped logger behave that it's missing any sensibility :) I'm
trying to restore that back to a working state.
I'd be +1 to releasing 2.2.6 today if we simply wanted to back out the
entire pile of cruft added since we started invoking /bin/sh to launch
log pipes. Till it behaves sensibly, I'll be -1 on release.
Bill
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
Status Update:
There are issues in the current shipping version of
APR 0.9 that must be resolved before we can reroll 2.0.x.
Furthermore, there are issues in APR 1.2 that should be
fixed (although not regression related) before we redo
2.2.x... Once APR is tagged and rolled, we will use
that to T&R 2.0.x and 2.2.x.
If APR takes too much longer I may reconsider going
ahead and releasing the 2.2.5 tarball anyway,
since I don't want to delay 1.3/2.2 much further.
We *need* to wait for 0.9 for 2.0 because of
the regression...
Re: And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Sander Temme <sc...@apache.org>.
Jim Jagielski wrote:
> Once Bill tags APR, I'll do more pre-tag regressions,
> re-roll 2.x and then look at releasing next week.
+1 I'll be looking out for the tarball.
I did have a configure failure on netbsd 3.1 where it failed a sed
script looking for APR... this was a regression from 2.2.4.
I'll look to throw that on the list tonight when I get home.
S.
And 2.2.6 Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 13, 2007, at 3:59 PM, Jim Jagielski wrote:
> William A. Rowe, Jr. wrote:
>>
>> Sander Temme wrote:
>>>
>>> On Aug 13, 2007, at 11:37 AM, Roy T. Fielding wrote:
>>>
>>>> It is mostly the same people, regardless. Bill could tag 0.9.15
>>>> and start a release vote on APR while Jim rebuilds 2.0.x based
>>>> on that tag and starts another release vote here. That way, lazy
>>>> folks like me can test both at once.
>>
>> I'm rolling APR snaps no later than first thing Wed a.m.
>>
>> No issue if Jim combines an apr release candidate with an httpd
>> candidate, as long as everyone is ok that if apr goes boom, httpd
>> would need to be rerolled.
>>
>> This is pretty stable code, so I'm not worried.
>>
>> With the Darwin fixes, I'd almost like to see 2.2.6 rerolled, with
>> no change to httpd. Does anyone else find an objection to that?
>> Jim, would it inflict too much pain to do this wed/thus?
>>
>
> I've no problem with 2.0 and 2.2 being re-tagged and re-rolled
> to incorporate the latest APR fixes... Wed/Thurs is fine
> with me :)
Just a FYI... 2.2.6 (httpd-2.2 head) with apr 1.2.10 (apr-1.2 head)
show no regressions from the 2.2.5 tarball, so even though we
don't need to reroll 2.2.5, I think it's best to do
so, since we need to redo 2.0.x anyway...
Once Bill tags APR, I'll do more pre-tag regressions,
re-roll 2.x and then look at releasing next week.
Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
William A. Rowe, Jr. wrote:
>
> Sander Temme wrote:
> >
> > On Aug 13, 2007, at 11:37 AM, Roy T. Fielding wrote:
> >
> >> It is mostly the same people, regardless. Bill could tag 0.9.15
> >> and start a release vote on APR while Jim rebuilds 2.0.x based
> >> on that tag and starts another release vote here. That way, lazy
> >> folks like me can test both at once.
>
> I'm rolling APR snaps no later than first thing Wed a.m.
>
> No issue if Jim combines an apr release candidate with an httpd
> candidate, as long as everyone is ok that if apr goes boom, httpd
> would need to be rerolled.
>
> This is pretty stable code, so I'm not worried.
>
> With the Darwin fixes, I'd almost like to see 2.2.6 rerolled, with
> no change to httpd. Does anyone else find an objection to that?
> Jim, would it inflict too much pain to do this wed/thus?
>
I've no problem with 2.0 and 2.2 being re-tagged and re-rolled
to incorporate the latest APR fixes... Wed/Thurs is fine
with me :)
--
===========================================================================
Jim Jagielski [|] jim@jaguNET.com [|] http://www.jaguNET.com/
"If you can dodge a wrench, you can dodge a ball."
Re: Notice of Intent: T&R 2.0.61
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Sander Temme wrote:
>
> On Aug 13, 2007, at 11:37 AM, Roy T. Fielding wrote:
>
>> It is mostly the same people, regardless. Bill could tag 0.9.15
>> and start a release vote on APR while Jim rebuilds 2.0.x based
>> on that tag and starts another release vote here. That way, lazy
>> folks like me can test both at once.
I'm rolling APR snaps no later than first thing Wed a.m.
No issue if Jim combines an apr release candidate with an httpd
candidate, as long as everyone is ok that if apr goes boom, httpd
would need to be rerolled.
This is pretty stable code, so I'm not worried.
With the Darwin fixes, I'd almost like to see 2.2.6 rerolled, with
no change to httpd. Does anyone else find an objection to that?
Jim, would it inflict too much pain to do this wed/thus?
If y'all say we want it, I'll add APR 1.2.x to the list of things
to roll by Wed a.m.
Bill
Re: Notice of Intent: T&R 2.0.61
Posted by Sander Temme <sc...@apache.org>.
On Aug 13, 2007, at 11:37 AM, Roy T. Fielding wrote:
> It is mostly the same people, regardless. Bill could tag 0.9.15
> and start a release vote on APR while Jim rebuilds 2.0.x based
> on that tag and starts another release vote here. That way, lazy
> folks like me can test both at once.
+1
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Notice of Intent: T&R 2.0.61
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Aug 13, 2007, at 4:59 AM, Jim Jagielski wrote:
> On Aug 13, 2007, at 1:08 AM, William A. Rowe, Jr. wrote:
>
>> Jim Jagielski wrote:
>>> Just a FYI: I'm planning on doing a T&R of 2.0.61 tomorrow (Aug 13);
>>> It's a retag of 2.0.60 (plus the version bump, 'natch), and a reroll
>>> with the singular exception of bundling APR 0.9.12, instead of
>>> 0.9.14.
>>
>> Just a quick note; I'll definitely find that objectionable.
>> Particularly
>> from 0.9.13
>>
>> *) Provide folding in autogenerated .manifest files for Win32
>> builders
>>
>> which provided our Windows users the ability to use the "Free"
>> Studio 2005
>> to build their own Apache. I'm always happy to help ensure we
>> have binaries,
>> but not at the expense of encouraging users to "roll their own".
>> Also
>>
>> *) Fix detection of pthread cross-process robust mutexes.
>>
>> would also likely impact us negatively on some platforms with
>> respect to
>> ssl cache and accept mutexes, no?
>>
>> So I can hazard a guess that I'd be -1 on such a tarball.
>>
>
> In which case, we will need to wait to release 2.0.61 until APR 0.9.15
> is released... I see no reason for 1.3.38 and 2.2.5 to be
> held up while this is done, although it *does* make it more
> difficult, what with the website changes, etc...
Right, I don't think there is any big hurry on 2.0.x. However,
there is also no reason why it would take so long for APR to
release 0.9.15 (aside from the usual volunteer time issues).
It is mostly the same people, regardless. Bill could tag 0.9.15
and start a release vote on APR while Jim rebuilds 2.0.x based
on that tag and starts another release vote here. That way, lazy
folks like me can test both at once.
....Roy
Re: Notice of Intent: T&R 2.0.61
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 13, 2007, at 1:08 AM, William A. Rowe, Jr. wrote:
> Jim Jagielski wrote:
>> Just a FYI: I'm planning on doing a T&R of 2.0.61 tomorrow (Aug 13);
>> It's a retag of 2.0.60 (plus the version bump, 'natch), and a reroll
>> with the singular exception of bundling APR 0.9.12, instead of
>> 0.9.14.
>
> Just a quick note; I'll definitely find that objectionable.
> Particularly
> from 0.9.13
>
> *) Provide folding in autogenerated .manifest files for Win32
> builders
>
> which provided our Windows users the ability to use the "Free"
> Studio 2005
> to build their own Apache. I'm always happy to help ensure we have
> binaries,
> but not at the expense of encouraging users to "roll their own". Also
>
> *) Fix detection of pthread cross-process robust mutexes.
>
> would also likely impact us negatively on some platforms with
> respect to
> ssl cache and accept mutexes, no?
>
> So I can hazard a guess that I'd be -1 on such a tarball.
>
In which case, we will need to wait to release 2.0.61 until APR 0.9.15
is released... I see no reason for 1.3.38 and 2.2.5 to be
held up while this is done, although it *does* make it more
difficult, what with the website changes, etc...
Re: Notice of Intent: T&R 2.0.61
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> Just a FYI: I'm planning on doing a T&R of 2.0.61 tomorrow (Aug 13);
> It's a retag of 2.0.60 (plus the version bump, 'natch), and a reroll
> with the singular exception of bundling APR 0.9.12, instead of 0.9.14.
Just a quick note; I'll definitely find that objectionable. Particularly
from 0.9.13
*) Provide folding in autogenerated .manifest files for Win32 builders
which provided our Windows users the ability to use the "Free" Studio 2005
to build their own Apache. I'm always happy to help ensure we have binaries,
but not at the expense of encouraging users to "roll their own". Also
*) Fix detection of pthread cross-process robust mutexes.
would also likely impact us negatively on some platforms with respect to
ssl cache and accept mutexes, no?
So I can hazard a guess that I'd be -1 on such a tarball.
Bill