You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Paul Querna <pa...@querna.org> on 2009/12/03 22:52:51 UTC
[RESULTS] [VOTE] Release httpd 2.3.4-alpha
Vote Results:
+1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
+1: Gregg Smith
+/-0: Rainer Jung
-1: William A. Rowe, Jr.
Vote passes.
I'll push out the tarballs to start getting mirrors, and hack on an
announcement email for tomorrow.
On Wed, Nov 25, 2009 at 2:43 PM, Paul Querna <pa...@querna.org> wrote:
> Test tarballs for Apache httpd 2.3.4-alpha are available at:
> <http://httpd.apache.org/dev/dist/>
>
> Your votes please;
>
> +/- 1
> [ ] Release httpd-2.3.4 as Alpha
>
> Vote closes at 18:00 UTC on Monday November 30 2009.
>
> May your Thanksgiving be filled with Turkey and httpd testing,
>
> Thanks,
>
> Paul
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
it is a script, r-x in all locations.
On Wed, Dec 9, 2009 at 9:24 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Dec 9, 2009 at 3:01 PM, Michael Felt <ma...@gmail.com> wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> pcre
> > issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
>
> Did your pcre-config get installed as non-executable?
>
> --
> Eric Covener
> covener@gmail.com
>
michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config -ls
164079 2 -rwxrwx--x 1 michael www 1249 Dec 5 07:57
./pcre-config
executing as michael, not other.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Eric Covener <co...@gmail.com>.
On Wed, Dec 9, 2009 at 3:01 PM, Michael Felt <ma...@gmail.com> wrote:
> I confess to being a bit lost in all of this. I am still stuck with the pcre
> issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
Did your pcre-config get installed as non-executable?
--
Eric Covener
covener@gmail.com
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]*grep -i pcre config.log*
$ ./configure --prefix=/usr/local/apache2 --enable-layout=Apache
--enable-module=so --enable-mods-shared=most --with-pcre=/data/prj/pcre-8.00
--with-z=/data/prj/zlib-1.2.3
configure:5490: checking for pcre-config
configure:5537: error: Did not find pcre-config script at
/data/prj/pcre-8.00
ac_cv_path_PCRE_CONFIG=false
PCRE_CONFIG='/data/prj/pcre-8.00'
PCRE_LIBS=''
On Thu, Dec 10, 2009 at 2:44 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
> Michael Felt wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> > pcre issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > Suggestions? And I hope I am not just being blind...
>
> config.log? What does it say about pcre detection?
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Michael Felt wrote:
> I confess to being a bit lost in all of this. I am still stuck with the
> pcre issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
>
> Suggestions? And I hope I am not just being blind...
config.log? What does it say about pcre detection?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
Tom, thanks. Please check my new post. I made a new build system after all.
On Thu, Dec 10, 2009 at 3:53 PM, Tom Evans <te...@googlemail.com> wrote:
> On Thu, Dec 10, 2009 at 12:45 PM, Michael Felt <ma...@gmail.com> wrote:
> > well, for an alpha build I dont want to modify my standard build system
> too
> > much.
> >
> > So, if I understand you correctly I will have to run a make install for
> pcre
> > before this will have any chance to work.
> >
> > On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com>
> wrote:
> >>
> >> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com>
> wrote:
> >> > michael@x054:[/data/prj/pcre-8.00]ls bin
> >> > ls: 0653-341 The file bin does not exist.
> >> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
> >> > michael@x054:[/data/prj/pcre-8.00]ls *config
> >> > pcre-config
> >> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
> >> > michael@x054:[/data/prj/pcre-8.00]
> >> >
> >> > * that seems to have solved the ./configure problem, but I suspect the
> >> > build
> >> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at
> >> > best, in
> >> > the directory area of the project source.
> >> >
> >> > What does the --with-pcre=.... actually mean? I would hope it is not
> >> > just to
> >> > find the config program, that is no (longer?) stored in the ./bin/
> >> > directory
> >> > as expected.
> >> >
> >> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> >> > checking for pcre-config... false
> >> > configure: Using external PCRE library from
> >> > /data/prj/pcre-8.00/bin/pcre-config
> >> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> >> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> >> > /data/prj/pcre* | grep libpcre
> >> > /data/prj/pcre-8.00/libpcreposix.la
> >> > /data/prj/pcre-8.00/libpcrecpp.pc.in
> >> > /data/prj/pcre-8.00/libpcre.pc.in
> >> > /data/prj/pcre-8.00/libpcreposix.pc.in
> >> > /data/prj/pcre-8.00/.libs/libpcre.exp
> >> > /data/prj/pcre-8.00/.libs/libpcre.so.0
> >> > /data/prj/pcre-8.00/.libs/libpcre.a
> >> > /data/prj/pcre-8.00/.libs/libpcre.lai
> >> > /data/prj/pcre-8.00/.libs/libpcre.la
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.a
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
> >> > /data/prj/pcre-8.00/.libs/libpcreposix.la
> >> > /data/prj/pcre-8.00/libpcre.pc
> >> > /data/prj/pcre-8.00/libpcreposix.pc
> >> > /data/prj/pcre-8.00/libpcrecpp.pc
> >> > /data/prj/pcre-8.00/libpcre.la
> >> >
> >>
> >> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
> >> Typically, if you want to install/use software that is not part of
> >> your os, you would configure pcre with something like:
> >>
> >> ./configure --prefix=/opt
> >> make all install
> >>
> >> and then configuring apache is simply ./configure --with-pcre=/opt
> >>
> >> HTH
> >>
> >> Tom
> >
> >
>
> Only if you want --with-pcre to work in configure. You could also
> specify the include paths for pcre by setting the CFLAGS environment
> variable, the linker flags for pcre in LDFLAGS, etc.
>
> I would just install it tbh.
>
> Cheers
>
> Tom
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Dec 10, 2009 at 12:45 PM, Michael Felt <ma...@gmail.com> wrote:
> well, for an alpha build I dont want to modify my standard build system too
> much.
>
> So, if I understand you correctly I will have to run a make install for pcre
> before this will have any chance to work.
>
> On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com> wrote:
>>
>> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
>> > michael@x054:[/data/prj/pcre-8.00]ls bin
>> > ls: 0653-341 The file bin does not exist.
>> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
>> > michael@x054:[/data/prj/pcre-8.00]ls *config
>> > pcre-config
>> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
>> > michael@x054:[/data/prj/pcre-8.00]
>> >
>> > * that seems to have solved the ./configure problem, but I suspect the
>> > build
>> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at
>> > best, in
>> > the directory area of the project source.
>> >
>> > What does the --with-pcre=.... actually mean? I would hope it is not
>> > just to
>> > find the config program, that is no (longer?) stored in the ./bin/
>> > directory
>> > as expected.
>> >
>> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
>> > checking for pcre-config... false
>> > configure: Using external PCRE library from
>> > /data/prj/pcre-8.00/bin/pcre-config
>> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
>> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
>> > /data/prj/pcre* | grep libpcre
>> > /data/prj/pcre-8.00/libpcreposix.la
>> > /data/prj/pcre-8.00/libpcrecpp.pc.in
>> > /data/prj/pcre-8.00/libpcre.pc.in
>> > /data/prj/pcre-8.00/libpcreposix.pc.in
>> > /data/prj/pcre-8.00/.libs/libpcre.exp
>> > /data/prj/pcre-8.00/.libs/libpcre.so.0
>> > /data/prj/pcre-8.00/.libs/libpcre.a
>> > /data/prj/pcre-8.00/.libs/libpcre.lai
>> > /data/prj/pcre-8.00/.libs/libpcre.la
>> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
>> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
>> > /data/prj/pcre-8.00/.libs/libpcreposix.a
>> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
>> > /data/prj/pcre-8.00/.libs/libpcreposix.la
>> > /data/prj/pcre-8.00/libpcre.pc
>> > /data/prj/pcre-8.00/libpcreposix.pc
>> > /data/prj/pcre-8.00/libpcrecpp.pc
>> > /data/prj/pcre-8.00/libpcre.la
>> >
>>
>> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
>> Typically, if you want to install/use software that is not part of
>> your os, you would configure pcre with something like:
>>
>> ./configure --prefix=/opt
>> make all install
>>
>> and then configuring apache is simply ./configure --with-pcre=/opt
>>
>> HTH
>>
>> Tom
>
>
Only if you want --with-pcre to work in configure. You could also
specify the include paths for pcre by setting the CFLAGS environment
variable, the linker flags for pcre in LDFLAGS, etc.
I would just install it tbh.
Cheers
Tom
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
well, for an alpha build I dont want to modify my standard build system too
much.
So, if I understand you correctly I will have to run a make install for pcre
before this will have any chance to work.
On Thu, Dec 10, 2009 at 2:38 PM, Tom Evans <te...@googlemail.com> wrote:
> On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
> > michael@x054:[/data/prj/pcre-8.00]ls bin
> > ls: 0653-341 The file bin does not exist.
> > michael@x054:[/data/prj/pcre-8.00]mkdir bin
> > michael@x054:[/data/prj/pcre-8.00]ls *config
> > pcre-config
> > michael@x054:[/data/prj/pcre-8.00]ln *config bin
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > * that seems to have solved the ./configure problem, but I suspect the
> build
> > will not succeed. -lpcre is not in /usr/local/lib - it is still, at best,
> in
> > the directory area of the project source.
> >
> > What does the --with-pcre=.... actually mean? I would hope it is not just
> to
> > find the config program, that is no (longer?) stored in the ./bin/
> directory
> > as expected.
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> > checking for pcre-config... false
> > configure: Using external PCRE library from
> > /data/prj/pcre-8.00/bin/pcre-config
> > setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> > /data/prj/pcre* | grep libpcre
> > /data/prj/pcre-8.00/libpcreposix.la
> > /data/prj/pcre-8.00/libpcrecpp.pc.in
> > /data/prj/pcre-8.00/libpcre.pc.in
> > /data/prj/pcre-8.00/libpcreposix.pc.in
> > /data/prj/pcre-8.00/.libs/libpcre.exp
> > /data/prj/pcre-8.00/.libs/libpcre.so.0
> > /data/prj/pcre-8.00/.libs/libpcre.a
> > /data/prj/pcre-8.00/.libs/libpcre.lai
> > /data/prj/pcre-8.00/.libs/libpcre.la
> > /data/prj/pcre-8.00/.libs/libpcreposix.exp
> > /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> > /data/prj/pcre-8.00/.libs/libpcreposix.a
> > /data/prj/pcre-8.00/.libs/libpcreposix.lai
> > /data/prj/pcre-8.00/.libs/libpcreposix.la
> > /data/prj/pcre-8.00/libpcre.pc
> > /data/prj/pcre-8.00/libpcreposix.pc
> > /data/prj/pcre-8.00/libpcrecpp.pc
> > /data/prj/pcre-8.00/libpcre.la
> >
>
> --with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
> Typically, if you want to install/use software that is not part of
> your os, you would configure pcre with something like:
>
> ./configure --prefix=/opt
> make all install
>
> and then configuring apache is simply ./configure --with-pcre=/opt
>
> HTH
>
> Tom
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Tom Evans <te...@googlemail.com>.
On Thu, Dec 10, 2009 at 12:26 PM, Michael Felt <ma...@gmail.com> wrote:
> michael@x054:[/data/prj/pcre-8.00]ls bin
> ls: 0653-341 The file bin does not exist.
> michael@x054:[/data/prj/pcre-8.00]mkdir bin
> michael@x054:[/data/prj/pcre-8.00]ls *config
> pcre-config
> michael@x054:[/data/prj/pcre-8.00]ln *config bin
> michael@x054:[/data/prj/pcre-8.00]
>
> * that seems to have solved the ./configure problem, but I suspect the build
> will not succeed. -lpcre is not in /usr/local/lib - it is still, at best, in
> the directory area of the project source.
>
> What does the --with-pcre=.... actually mean? I would hope it is not just to
> find the config program, that is no (longer?) stored in the ./bin/ directory
> as expected.
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]grep pcre nohup.out
> checking for pcre-config... false
> configure: Using external PCRE library from
> /data/prj/pcre-8.00/bin/pcre-config
> setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]find /usr/local/lib
> /data/prj/pcre* | grep libpcre
> /data/prj/pcre-8.00/libpcreposix.la
> /data/prj/pcre-8.00/libpcrecpp.pc.in
> /data/prj/pcre-8.00/libpcre.pc.in
> /data/prj/pcre-8.00/libpcreposix.pc.in
> /data/prj/pcre-8.00/.libs/libpcre.exp
> /data/prj/pcre-8.00/.libs/libpcre.so.0
> /data/prj/pcre-8.00/.libs/libpcre.a
> /data/prj/pcre-8.00/.libs/libpcre.lai
> /data/prj/pcre-8.00/.libs/libpcre.la
> /data/prj/pcre-8.00/.libs/libpcreposix.exp
> /data/prj/pcre-8.00/.libs/libpcreposix.so.0
> /data/prj/pcre-8.00/.libs/libpcreposix.a
> /data/prj/pcre-8.00/.libs/libpcreposix.lai
> /data/prj/pcre-8.00/.libs/libpcreposix.la
> /data/prj/pcre-8.00/libpcre.pc
> /data/prj/pcre-8.00/libpcreposix.pc
> /data/prj/pcre-8.00/libpcrecpp.pc
> /data/prj/pcre-8.00/libpcre.la
>
--with-pcre=<arg> is expecting pcre to be installed to the prefix arg.
Typically, if you want to install/use software that is not part of
your os, you would configure pcre with something like:
./configure --prefix=/opt
make all install
and then configuring apache is simply ./configure --with-pcre=/opt
HTH
Tom
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
michael@x054:[/data/prj/pcre-8.00]ls bin
ls: 0653-341 The file bin does not exist.
michael@x054:[/data/prj/pcre-8.00]mkdir bin
michael@x054:[/data/prj/pcre-8.00]ls *config
pcre-config
michael@x054:[/data/prj/pcre-8.00]ln *config bin
michael@x054:[/data/prj/pcre-8.00]
* that seems to have solved the ./configure problem, but I suspect the build
will not succeed. -lpcre is not in /usr/local/lib - it is still, at best, in
the directory area of the project source.
What does the --with-pcre=.... actually mean? I would hope it is not just to
find the config program, that is no (longer?) stored in the ./bin/ directory
as expected.
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]*grep pcre nohup.out*
checking for pcre-config... false
configure: Using external PCRE library from
/data/prj/pcre-8.00/bin/pcre-config
setting PCRE_LIBS to "-L/usr/local/lib -lpcre"
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]f*ind /usr/local/lib
/data/prj/pcre* | grep libpcre*
/data/prj/pcre-8.00/libpcreposix.la
/data/prj/pcre-8.00/libpcrecpp.pc.in
/data/prj/pcre-8.00/libpcre.pc.in
/data/prj/pcre-8.00/libpcreposix.pc.in
/data/prj/pcre-8.00/.libs/libpcre.exp
/data/prj/pcre-8.00/.libs/libpcre.so.0
/data/prj/pcre-8.00/.libs/libpcre.a
/data/prj/pcre-8.00/.libs/libpcre.lai
/data/prj/pcre-8.00/.libs/libpcre.la
/data/prj/pcre-8.00/.libs/libpcreposix.exp
/data/prj/pcre-8.00/.libs/libpcreposix.so.0
/data/prj/pcre-8.00/.libs/libpcreposix.a
/data/prj/pcre-8.00/.libs/libpcreposix.lai
/data/prj/pcre-8.00/.libs/libpcreposix.la
/data/prj/pcre-8.00/libpcre.pc
/data/prj/pcre-8.00/libpcreposix.pc
/data/prj/pcre-8.00/libpcrecpp.pc
/data/prj/pcre-8.00/libpcre.la
On Thu, Dec 10, 2009 at 1:49 PM, Bart van der Schans <
b.vanderschans@onehippo.com> wrote:
> On Wed, Dec 9, 2009 at 9:01 PM, Michael Felt <ma...@gmail.com> wrote:
> > I confess to being a bit lost in all of this. I am still stuck with the
> pcre
> > issue, even after adding:
> > --with-pcre=/data/prj/pcre-8.00 \
> >
> > checking for pcre-config... false
> > configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
> >
> > michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> > michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> > ./pcre-config
> > michael@x054:[/data/prj/pcre-8.00]
> >
> > Suggestions? And I hope I am not just being blind...
>
> Doesn't configure check for -x "$with_pcre/bin/pcre-config"? Then you
> should have the pcre-config script in a bin sub folder.
>
> Bart
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Bart van der Schans <b....@onehippo.com>.
On Wed, Dec 9, 2009 at 9:01 PM, Michael Felt <ma...@gmail.com> wrote:
> I confess to being a bit lost in all of this. I am still stuck with the pcre
> issue, even after adding:
> --with-pcre=/data/prj/pcre-8.00 \
>
> checking for pcre-config... false
> configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
>
> michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
> michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
> ./pcre-config
> michael@x054:[/data/prj/pcre-8.00]
>
> Suggestions? And I hope I am not just being blind...
Doesn't configure check for -x "$with_pcre/bin/pcre-config"? Then you
should have the pcre-config script in a bin sub folder.
Bart
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Michael Felt <ma...@gmail.com>.
I confess to being a bit lost in all of this. I am still stuck with the pcre
issue, even after adding:
--with-pcre=/data/prj/pcre-8.00 \
checking for pcre-config... false
configure: error: Did not find pcre-config script at /data/prj/pcre-8.00
michael@x054:[/data/prj/alpha/httpd-2.3.4-alpha]cd /data/prj/pcre-8.00
michael@x054:[/data/prj/pcre-8.00]find . -name pcre-config
./pcre-config
michael@x054:[/data/prj/pcre-8.00]
Suggestions? And I hope I am not just being blind...
On Tue, Dec 8, 2009 at 5:18 AM, William A. Rowe Jr. <wr...@rowe-clan.net>wrote:
>
>
> Anyway, 2.3.4 is done and waiting for your announce text, and is in no real
> hurry for that message since many of the people who would further review
> that
> alpha follow this list. But it would be helpful on the web site and
> especially
> in the /dist/ directory, for people who stumble upon 2.3.4-alpha and wonder
> what
> exactly it is.
>
>
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Niklas Edmundsson wrote:
> On Thu, 3 Dec 2009, Paul Querna wrote:
>
>> Vote Results:
>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>> +1: Gregg Smith
>> +/-0: Rainer Jung
>> -1: William A. Rowe, Jr.
>>
>> Vote passes.
>
> Ehrm. I obviously should have changed the subject when I agreed to
> wrowe's statement about including PCRE in the deps tarball.
>
> It was not my intention to vote on the Alpha-release, but to concur with
> wrowe's statement, as can be seen in the archive at:
> http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/<Pi...@hatchepsut.acc.umu.se>
>
> So, my vote is to be considered a false positive I'm afraid. I'll
> definitely be more careful about this in the future so automated voting
> counts don't get confused.
As it turns out, Jeff had also voted +1, so the vote count was previously;
+1 (binding): Sander Temme, Paul Querna, Joe Orton, Jeff Trawick
+1: Gregg Smith
+/-0: Rainer Jung
-1: William A. Rowe, Jr.
As my vote was against releasing -deps, and with -deps released, I was otherwise
+1 to the httpd-2.3.4-alpha.tar packages. Packages are not unreleased once they
have been released to the mirrors, and it's not like I haven't been criticized
for that in the past (thus there are a few -r2.msi packages floating around).
I apologize for perhaps not detailing my objections clearly enough when the
issues were first up, e.g. the way I put them in response to Joe Orton's post,
today. And I was equally dismayed that the release was shoved at /dist/, but
once that happened, my objections are entirely moot.
Paul, you prefer that I'm not so overbearing and pedantic, while I'd prefer
that you are more attentive to objections that are raised when they are first
raised, and probe for more information to solve them. There's plenty of room
to agree to disagree, and even more room to come up with agreeable resolutions.
If you need fewer emails, and faster bandwidth, I'm always happy to pound through
an entire disagreement with anyone on the irc httpd-dev channel in realtime, and
bring our thoughts back to this discussion list.
Anyway, 2.3.4 is done and waiting for your announce text, and is in no real
hurry for that message since many of the people who would further review that
alpha follow this list. But it would be helpful on the web site and especially
in the /dist/ directory, for people who stumble upon 2.3.4-alpha and wonder what
exactly it is.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Thu, 3 Dec 2009, Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
Ehrm. I obviously should have changed the subject when I agreed to
wrowe's statement about including PCRE in the deps tarball.
It was not my intention to vote on the Alpha-release, but to concur
with wrowe's statement, as can be seen in the archive at:
http://mail-archives.apache.org/mod_mbox/httpd-dev/200912.mbox/<Pi...@hatchepsut.acc.umu.se>
So, my vote is to be considered a false positive I'm afraid. I'll
definitely be more careful about this in the future so automated
voting counts don't get confused.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
Mr Garibaldi, it's a big universe.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> Jeff Trawick wrote:
>>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>>
>>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>>> forwards.
>>> The APR versioning rules are hopelessly broken if a tarball snapshot
>>> of the 1.4.x branch before a GA release casts the API in stone.
>>>
>>> Surely I misunderstood you.
>> Is there a README indicating that the MAJOR/MINOR version tests for this
>> particular tarball are not relevant/complete? No.
>>
>> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
>> You surely don't misunderstand what I said.
>
> Why is something with version x.y.z-dev a release and not a snapshot?
Because snapshots don't live at http://www.apache.org/dist/, those are releases.
The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside
at http://svn.apache.org/snapshots/
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
>
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Not sufficient, IMHO, unless we add the appropriate indicators to allow
feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1
&& VERSION_MINOR >= 4 and the APR versioning contract says that test is
always sufficient.
This dialog reads like folks may assume the httpd MMN feature tests
work for APR functions, but there isn't such a feature test in APR.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
> <wr...@rowe-clan.net> wrote:
>> Jeff Trawick wrote:
>>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>>
>>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>>> forwards.
>>> The APR versioning rules are hopelessly broken if a tarball snapshot
>>> of the 1.4.x branch before a GA release casts the API in stone.
>>>
>>> Surely I misunderstood you.
>> Is there a README indicating that the MAJOR/MINOR version tests for this
>> particular tarball are not relevant/complete? No.
>>
>> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
>> You surely don't misunderstand what I said.
>
> Why is something with version x.y.z-dev a release and not a snapshot?
Because snapshots don't live at http://www.apache.org/dist/, those are releases.
The trigger didn't occur until Paul svn mv'ed it into there. Snapshots reside
at http://svn.apache.org/snapshots/
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
>
>> As for broken versioning rules, please take that to APR.
>>
>> Perhaps in retrospect, APR would consider an even/odds approach as httpd
>> has for adding (even eliminating) interfaces during a development cycle.
>
> IMO the determination could be as simple as whether or not a release
> in the maj.min series has yet been declared GA.
Not sufficient, IMHO, unless we add the appropriate indicators to allow
feature tests in apr 2.0. E.g. the current test is VERSION_MAJOR >= 1
&& VERSION_MINOR >= 4 and the APR versioning contract says that test is
always sufficient.
This dialog reads like folks may assume the httpd MMN feature tests
work for APR functions, but there isn't such a feature test in APR.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>> forwards.
>>
>> The APR versioning rules are hopelessly broken if a tarball snapshot
>> of the 1.4.x branch before a GA release casts the API in stone.
>>
>> Surely I misunderstood you.
>
> Is there a README indicating that the MAJOR/MINOR version tests for this
> particular tarball are not relevant/complete? No.
>
> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
> You surely don't misunderstand what I said.
Why is something with version x.y.z-dev a release and not a snapshot?
> As for broken versioning rules, please take that to APR.
>
> Perhaps in retrospect, APR would consider an even/odds approach as httpd
> has for adding (even eliminating) interfaces during a development cycle.
IMO the determination could be as simple as whether or not a release
in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 11:29 PM, William A. Rowe Jr.
<wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
>> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>>
>>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>>> forwards.
>>
>> The APR versioning rules are hopelessly broken if a tarball snapshot
>> of the 1.4.x branch before a GA release casts the API in stone.
>>
>> Surely I misunderstood you.
>
> Is there a README indicating that the MAJOR/MINOR version tests for this
> particular tarball are not relevant/complete? No.
>
> This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
> You surely don't misunderstand what I said.
Why is something with version x.y.z-dev a release and not a snapshot?
> As for broken versioning rules, please take that to APR.
>
> Perhaps in retrospect, APR would consider an even/odds approach as httpd
> has for adding (even eliminating) interfaces during a development cycle.
IMO the determination could be as simple as whether or not a release
in the maj.min series has yet been declared GA.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
>
>> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
>> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
>> forwards.
>
> The APR versioning rules are hopelessly broken if a tarball snapshot
> of the 1.4.x branch before a GA release casts the API in stone.
>
> Surely I misunderstood you.
Is there a README indicating that the MAJOR/MINOR version tests for this
particular tarball are not relevant/complete? No.
This is not a snapshot. It is labeled httpd-2.3.4-alpha.tar.xx release.
You surely don't misunderstand what I said.
As for broken versioning rules, please take that to APR.
Perhaps in retrospect, APR would consider an even/odds approach as httpd
has for adding (even eliminating) interfaces during a development cycle.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Dec 3, 2009 at 6:21 PM, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
> apr-util 1.4.0 dev, and the API versioning rules will bind from that release
> forwards.
The APR versioning rules are hopelessly broken if a tarball snapshot
of the 1.4.x branch before a GA release casts the API in stone.
Surely I misunderstood you.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> This is all fine and good but I don't see any implication above that the
> APR project must enforce its versioning rules on anything other than
> releases *it voted on* - i.e. releases of APR, rather than releases of
> httpd.
I'm more than a bit confused. Does it matter if /usr/lib64/libapr-1.so.0.0
was installed by a release from apr, or from the httpd or svn projects? You
are one of the strongest advocates for consistency in shipped, released,
installed binary artifacts and have offered me no end of grief for single-
platform minor behavioral changes. And certainly I respect you, for your
convictions on this subject.
So let's measurably quantify if this is a molehill;
The httpd project has a feature-detection mechanism of AP_MODULE_MAGIC_AT_LEAST
from ap_mmn.h which reflects the current API, defined by MODULE_MAGIC_NUMBER_MAJOR
and MODULE_MAGIC_NUMBER_MINOR. The apr project uses only APR_VERSION_AT_LEAST
provided by apr_version.h, which reflects APR_MAJOR_VERSION, APR_MINOR_VERSION
and APR_PATCH_VERSION. The version contract declares all features are introduced
at APR_PATCH_VERSION 0 of a given series. Further, httpd would provide for other
projects to ship httpd's code, AP_SERVER_BASEVENDOR, AP_SERVER_BASEPROJECT and
AP_SERVER_BASEPRODUCT define who has provisioned the code. APR has no similar
constructs, by design.
Do you disagree with the paragraph above?
Anything that ships from /dist/ must be expected to be installed on some
users' machines, and the code has been released by the respective projects.
Infrastructure has set down ASF-wide policy that /dist/ contains only, and
all release artifacts. By convention, the ASF does not un-release code.
What exists in http://www.apache.org/dist/ persists forever in the
http://archive.apache.org/dist/. On the other hand, infrastructure has
defined http://svn.apache.org/snapshots/ as exactly that, and another
foundation-wide convention defines /dev/ as the developers' working
space, never release space. There's a clear definition, technically and
legally, between published product and work product.
Do you disagree with the paragraph above?
Then now there should expected to be local installs of a non-APR release
of an APR package by end users, as a published ASF release, without the
user being aware that they have introduced an incompatibility in other
software projects with the bundled flavor of APR. They believed they
were guinea pigs for an alpha of httpd. They should not be expected to
anticipate that their installed package may break third party applications
that are testing for APR 1.4 as a prerequisite to a new feature.
Do you disagree with the paragraph above?
Jeff called for apr (or httpd) to offer snapshots as proof-of-readiness
for the next API iteration. These could have resided at /dev/, or direct
from the /snapshots/ URL. That sounded like a good idea, and would have
been a reasonable course of action to resolve the previous logjam.
Instead, httpd had chosen to %$@jam APR. No, I don't really see this as
a technical molehill, but others are free to disagree, since this para
is purely opinion :)
> What and how the APR project chooses to apply API stability rules is
> something decided by the APR project, not the board or infra. Do you
> disagree with that?
Right. The versioning.html is APR's document, and its a shame when other
projects don't respect the advantages of respecting those guidelines.
Makes Sun's dictatorial supervision of java. seem rather wise. I'd hope
we can coexist without being dictatorial about it.
Since httpd has introduced a potential for inconsistency, APR project can
work around this by bumping version minor on any further '1.4' changes.
If they are called 1.5, there is no ambiguity.
There's obviously some opportunity at apr 2.0 to refine the versioning
contract at APR. I'd hope we take advantage of the opportunity to look
at how it's worked for us, and how it's impeded us from moving forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
>
> This is all fine and good but I don't see any implication above that the
> APR project must enforce its versioning rules on anything other than
> releases *it voted on* - i.e. releases of APR, rather than releases of
> httpd.
I'm more than a bit confused. Does it matter if /usr/lib64/libapr-1.so.0.0
was installed by a release from apr, or from the httpd or svn projects? You
are one of the strongest advocates for consistency in shipped, released,
installed binary artifacts and have offered me no end of grief for single-
platform minor behavioral changes. And certainly I respect you, for your
convictions on this subject.
So let's measurably quantify if this is a molehill;
The httpd project has a feature-detection mechanism of AP_MODULE_MAGIC_AT_LEAST
from ap_mmn.h which reflects the current API, defined by MODULE_MAGIC_NUMBER_MAJOR
and MODULE_MAGIC_NUMBER_MINOR. The apr project uses only APR_VERSION_AT_LEAST
provided by apr_version.h, which reflects APR_MAJOR_VERSION, APR_MINOR_VERSION
and APR_PATCH_VERSION. The version contract declares all features are introduced
at APR_PATCH_VERSION 0 of a given series. Further, httpd would provide for other
projects to ship httpd's code, AP_SERVER_BASEVENDOR, AP_SERVER_BASEPROJECT and
AP_SERVER_BASEPRODUCT define who has provisioned the code. APR has no similar
constructs, by design.
Do you disagree with the paragraph above?
Anything that ships from /dist/ must be expected to be installed on some
users' machines, and the code has been released by the respective projects.
Infrastructure has set down ASF-wide policy that /dist/ contains only, and
all release artifacts. By convention, the ASF does not un-release code.
What exists in http://www.apache.org/dist/ persists forever in the
http://archive.apache.org/dist/. On the other hand, infrastructure has
defined http://svn.apache.org/snapshots/ as exactly that, and another
foundation-wide convention defines /dev/ as the developers' working
space, never release space. There's a clear definition, technically and
legally, between published product and work product.
Do you disagree with the paragraph above?
Then now there should expected to be local installs of a non-APR release
of an APR package by end users, as a published ASF release, without the
user being aware that they have introduced an incompatibility in other
software projects with the bundled flavor of APR. They believed they
were guinea pigs for an alpha of httpd. They should not be expected to
anticipate that their installed package may break third party applications
that are testing for APR 1.4 as a prerequisite to a new feature.
Do you disagree with the paragraph above?
Jeff called for apr (or httpd) to offer snapshots as proof-of-readiness
for the next API iteration. These could have resided at /dev/, or direct
from the /snapshots/ URL. That sounded like a good idea, and would have
been a reasonable course of action to resolve the previous logjam.
Instead, httpd had chosen to %$@jam APR. No, I don't really see this as
a technical molehill, but others are free to disagree, since this para
is purely opinion :)
> What and how the APR project chooses to apply API stability rules is
> something decided by the APR project, not the board or infra. Do you
> disagree with that?
Right. The versioning.html is APR's document, and its a shame when other
projects don't respect the advantages of respecting those guidelines.
Makes Sun's dictatorial supervision of java. seem rather wise. I'd hope
we can coexist without being dictatorial about it.
Since httpd has introduced a potential for inconsistency, APR project can
work around this by bumping version minor on any further '1.4' changes.
If they are called 1.5, there is no ambiguity.
There's obviously some opportunity at apr 2.0 to refine the versioning
contract at APR. I'd hope we take advantage of the opportunity to look
at how it's worked for us, and how it's impeded us from moving forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 04, 2009 at 07:48:02PM -0600, William Rowe wrote:
> Joe Orton wrote:
> > 1) the httpd project cannot force the APR project to commit to API
> > stability by distributing a snapshot of the APR 1.4 branch. Why on
> > earth would that be the case? The only time the APR project commits to
> > API stability is by making a new .0 release itself. What other projects
> > do is irrelevant to APR.
>
> Joe, as I pointed out in another thread, httpd *does* commit apr the moment
> the mislabeled artifact hits www.apache.org/dist/ - where does that package
> suggest it is nothing but a snapshot? The answer is, it doesn't.
>
> When we did this previously in httpd 2.0 (never 2.1 to the best of my
> recollection) we actually did commit to that particular apr API. The
> rules in 0.9 just weren't so draconian.
>
> If you don't like any of these rules;
>
> * what is on /dist/ is a release
> * what is released apr >= 1.0 follows absolute versioning rules
> * what is a snapshot doesn't appear on /dist/
>
> then take those issues to an infra/board level. We've had these discussions
> a thousand times on incubator lists, and this is a clear case of what is
> good for the goose...
This is all fine and good but I don't see any implication above that the
APR project must enforce its versioning rules on anything other than
releases *it voted on* - i.e. releases of APR, rather than releases of
httpd.
What and how the APR project chooses to apply API stability rules is
something decided by the APR project, not the board or infra. Do you
disagree with that?
If you think we need to amend apr/README to describe how the APR
versioning rules apply to the APR project, so be it, but I think you are
making an Everest-sized mountain out of a molehill here.
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Fri, Dec 04, 2009 at 07:48:02PM -0600, William Rowe wrote:
> Joe Orton wrote:
> > 1) the httpd project cannot force the APR project to commit to API
> > stability by distributing a snapshot of the APR 1.4 branch. Why on
> > earth would that be the case? The only time the APR project commits to
> > API stability is by making a new .0 release itself. What other projects
> > do is irrelevant to APR.
>
> Joe, as I pointed out in another thread, httpd *does* commit apr the moment
> the mislabeled artifact hits www.apache.org/dist/ - where does that package
> suggest it is nothing but a snapshot? The answer is, it doesn't.
>
> When we did this previously in httpd 2.0 (never 2.1 to the best of my
> recollection) we actually did commit to that particular apr API. The
> rules in 0.9 just weren't so draconian.
>
> If you don't like any of these rules;
>
> * what is on /dist/ is a release
> * what is released apr >= 1.0 follows absolute versioning rules
> * what is a snapshot doesn't appear on /dist/
>
> then take those issues to an infra/board level. We've had these discussions
> a thousand times on incubator lists, and this is a clear case of what is
> good for the goose...
This is all fine and good but I don't see any implication above that the
APR project must enforce its versioning rules on anything other than
releases *it voted on* - i.e. releases of APR, rather than releases of
httpd.
What and how the APR project chooses to apply API stability rules is
something decided by the APR project, not the board or infra. Do you
disagree with that?
If you think we need to amend apr/README to describe how the APR
versioning rules apply to the APR project, so be it, but I think you are
making an Everest-sized mountain out of a molehill here.
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
>> Paul Querna wrote:
>>> Vote Results:
>>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>>> +1: Gregg Smith
>>> +/-0: Rainer Jung
>>> -1: William A. Rowe, Jr.
>>>
>>> Vote passes.
>> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
>> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
>> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
>> httpd-2.3.4-alpha.tar.xx package alone.
>
> I've no issue at all with the -deps tarball containing a snapshot of
> APR:
>
> 1) the httpd project cannot force the APR project to commit to API
> stability by distributing a snapshot of the APR 1.4 branch. Why on
> earth would that be the case? The only time the APR project commits to
> API stability is by making a new .0 release itself. What other projects
> do is irrelevant to APR.
Joe, as I pointed out in another thread, httpd *does* commit apr the moment
the mislabeled artifact hits www.apache.org/dist/ - where does that package
suggest it is nothing but a snapshot? The answer is, it doesn't.
When we did this previously in httpd 2.0 (never 2.1 to the best of my
recollection) we actually did commit to that particular apr API. The
rules in 0.9 just weren't so draconian.
If you don't like any of these rules;
* what is on /dist/ is a release
* what is released apr >= 1.0 follows absolute versioning rules
* what is a snapshot doesn't appear on /dist/
then take those issues to an infra/board level. We've had these discussions
a thousand times on incubator lists, and this is a clear case of what is
good for the goose...
> 2) the httpd project isn't taking on any commitment to itself maintain
> API stability in the shipped APR snapshot because *this is an alpha*, so
> we're not guaranteeing API stability.
Nope, much like broken ldap and crypto interfaces, it simply inflicts them
upon apr and hopes for someone else to clean up the junk later, perhaps.
But the apr project would be remiss in not voiding 1.4.x and moving on to
1.5.x for API additions since users can now be reasonably expected to have
installed an apr 1.4.x major/minor with a specific feature set.
> Furthermore I don't think it's a good idea to set a precedent of
> requiring a separate vote on each file which makes up "the release". I
> certainly presumed that the vote Paul called was for all the files
> making up "the release".
Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do
I really think everyone voting on the source code snapshot of httpd is paying
any attention to that artifact (or this new -deps artifact, when all the deps
are already provisioned on most voter's machines)?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Joe Orton wrote:
> On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
>> Paul Querna wrote:
>>> Vote Results:
>>> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
>>> +1: Gregg Smith
>>> +/-0: Rainer Jung
>>> -1: William A. Rowe, Jr.
>>>
>>> Vote passes.
>> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
>> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
>> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
>> httpd-2.3.4-alpha.tar.xx package alone.
>
> I've no issue at all with the -deps tarball containing a snapshot of
> APR:
>
> 1) the httpd project cannot force the APR project to commit to API
> stability by distributing a snapshot of the APR 1.4 branch. Why on
> earth would that be the case? The only time the APR project commits to
> API stability is by making a new .0 release itself. What other projects
> do is irrelevant to APR.
Joe, as I pointed out in another thread, httpd *does* commit apr the moment
the mislabeled artifact hits www.apache.org/dist/ - where does that package
suggest it is nothing but a snapshot? The answer is, it doesn't.
When we did this previously in httpd 2.0 (never 2.1 to the best of my
recollection) we actually did commit to that particular apr API. The
rules in 0.9 just weren't so draconian.
If you don't like any of these rules;
* what is on /dist/ is a release
* what is released apr >= 1.0 follows absolute versioning rules
* what is a snapshot doesn't appear on /dist/
then take those issues to an infra/board level. We've had these discussions
a thousand times on incubator lists, and this is a clear case of what is
good for the goose...
> 2) the httpd project isn't taking on any commitment to itself maintain
> API stability in the shipped APR snapshot because *this is an alpha*, so
> we're not guaranteeing API stability.
Nope, much like broken ldap and crypto interfaces, it simply inflicts them
upon apr and hopes for someone else to clean up the junk later, perhaps.
But the apr project would be remiss in not voiding 1.4.x and moving on to
1.5.x for API additions since users can now be reasonably expected to have
installed an apr 1.4.x major/minor with a specific feature set.
> Furthermore I don't think it's a good idea to set a precedent of
> requiring a separate vote on each file which makes up "the release". I
> certainly presumed that the vote Paul called was for all the files
> making up "the release".
Nonsense. I post up httpd win32 binaries all the time to /dev/dist/. Do
I really think everyone voting on the source code snapshot of httpd is paying
any attention to that artifact (or this new -deps artifact, when all the deps
are already provisioned on most voter's machines)?
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Dec 03, 2009 at 05:21:09PM -0600, William Rowe wrote:
> Paul Querna wrote:
> > Vote Results:
> > +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> > +1: Gregg Smith
> > +/-0: Rainer Jung
> > -1: William A. Rowe, Jr.
> >
> > Vote passes.
>
> I'm sorry. I explicitly insisted on a vote on the -deps package seperately
> from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
> Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
> httpd-2.3.4-alpha.tar.xx package alone.
I've no issue at all with the -deps tarball containing a snapshot of
APR:
1) the httpd project cannot force the APR project to commit to API
stability by distributing a snapshot of the APR 1.4 branch. Why on
earth would that be the case? The only time the APR project commits to
API stability is by making a new .0 release itself. What other projects
do is irrelevant to APR.
2) the httpd project isn't taking on any commitment to itself maintain
API stability in the shipped APR snapshot because *this is an alpha*, so
we're not guaranteeing API stability.
Furthermore I don't think it's a good idea to set a precedent of
requiring a separate vote on each file which makes up "the release". I
certainly presumed that the vote Paul called was for all the files
making up "the release".
Regards, Joe
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
I'm sorry. I explicitly insisted on a vote on the -deps package seperately
from the 2.3.4 package, because it was entirely reasonable that Sander Temme,
Paul Querna, Joe Orton, Niklas Edmundsson, or Gregg Smith reviewed -only- the
httpd-2.3.4-alpha.tar.xx package alone.
Gentlemen, if you could verify that your vote was for *both* the core package
and the -deps.tar.xx package, that might keep Paul on his schedule (or fall
against the proposed -deps.tar.xx package).
Remember your -deps vote is to approve the release of apr 1.4.0-dev and the
apr-util 1.4.0 dev, and the API versioning rules will bind from that release
forwards.
Re: [RESULTS] [VOTE] Release httpd 2.3.4-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
Paul Querna wrote:
> Vote Results:
> +1 (binding): Sander Temme, Paul Querna, Joe Orton, Niklas Edmundsson,
> +1: Gregg Smith
> +/-0: Rainer Jung
> -1: William A. Rowe, Jr.
>
> Vote passes.
>
> I'll push out the tarballs to start getting mirrors, and hack on an
> announcement email for tomorrow.
Oh - looking forward to the announce; the damage occured the moment
you had pushed to /dist/httpd/, we don't un-release software, and any
old arguments are over about the wisdom of releasing the -deps package.
Except of course, we need to finish the discussion of *adding* PCRE, but
that should never stop an alpha release.
In the meantime I'm pushing forwards on apr-1.4.1 since testing for
subversion 0 won't indicate if the APR_STATUS_IS_ENOTDIR had been fixed
(for anyone looking for min revlevel checks), and once that is done,
perhaps someone else wants to advocate for releasing apr-util-1.4.0.
But AFAIK apr-util 1.4.0 is not a prerequisite for httpd 2.3 alphas
just yet, it is an optional requirement for the scache module.