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 <ch...@force-elite.com> on 2008/04/12 19:20:56 UTC
[PROPOSAL] Time Based Releases
This is something I have been thinking about for awhile, and discussed
with a few other http server people before.
I think that for the 'stable' branch, we should move to time based releases.
My proposal is for every 2 months, we do a release of the main stable
branch, which at this time is 2.2.x.
Security Issues of great importance of course would trigger an immediate
release. Depending on the nearness to a scheduled release, we may or
may not scrap the next time based release.
A history of the 2.2.x releases:
2.2.0 : Released on December 1, 2005 as GA.
2.2.1 : Tagged on April 1, 2006, not released.
2.2.2 : Released on May 1, 2006 as GA.
2.2.3 : Released on July 28, 2006 as GA.
2.2.4 : Released on January 9, 2007 as GA.
2.2.5 : Tagged August 10, 2007, not released.
2.2.6 : Released September 7, 2007.
2.2.7 : Tagged January 4, 2008. Not released.
2.2.8 : Tagged January 10, 2008.
2.2.9 : In development
With a 2 month cycle, starting with 2.2.9 in mid-April, we would do the
following releases in 2008 to early 2009:
2.2.9: April
2.2.10: June
2.2.11: August
2.2.12: October
2.2.13: December
2.2.14: February 2009
I also volunteer to be the Release Manager for the first couple
releases, assuming no one else really wants to do them :-)
Thoughts?
Thanks,
-Paul
Re: [PROPOSAL] Time Based Releases
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 12, 2008, at 1:20 PM, Paul Querna wrote:
> This is something I have been thinking about for awhile, and
> discussed with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.
>
> My proposal is for every 2 months, we do a release of the main
> stable branch, which at this time is 2.2.x.
>
> I also volunteer to be the Release Manager for the first couple
> releases, assuming no one else really wants to do them :-)
>
> Thoughts?
>
As the person who's been pushing the last several releases out, I'm
+1 on having a set schedule, assuming, of course, that we aren't holding
ourselves to it ("it's done when it's done" after all), and I'm still
planning on calling for a 2.2.9 release soon and will continue to
offer to RM.
Re: [PROPOSAL] Time Based Releases
Posted by Mads Toftum <ma...@toftum.dk>.
On Mon, Apr 14, 2008 at 12:46:43PM -0400, Jim Jagielski wrote:
> I think what Paul is suggesting (he will for sure correct me
> if I'm wrong) is that it's better to at least have some semblance
> of a schedule than not, and by baselining every X months for a release,
> it provides us, as volunteers, to better allocate time. It does
> not mean, imo, that we rush out packages that aren't ready or
> release something just because "we have a schedule to keep"...
> we all have day jobs that force that on us, and we don't want
> that kind of pressure here as well.
>
TBH, I'm not too keen on the idea of releasing just because we're
suddenly hitting a specific date - if there's no changes worth
releasing... Yeah, I'd like to see it happen more often than every 6-8
months, but every 2-3 months is just going to create unnecessary work
fort the admins out there. Going down this route, I think the bare
minimum way of playing nice would be to very clearly mark releases as
either security, feature or just that time of the month releases.
> However, looking over things, I think that we have enough active
> activity such that a ~3month "cycle" might be workable...
How many branches are we talking about? the whole 2.x bunch or?
just my $.02
Mads Toftum
--
http://soulfood.dk
Re: [PROPOSAL] Time Based Releases
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Brad Nicholes wrote:
>
> IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x
> or 2.2.x,
s/be required/desire/ - it's a group consensus. It wasn't this way prior to
the 2.0.43 and doesn't have to be that way in the future, but I think it has
served our users well, and hasn't gotten in our way until...
> but the same level of conservatism shouldn't apply to 2.4 or 3.0.
++1
Bill
Configuration was Re: [PROPOSAL] Time Based Releases
Posted by "Akins, Brian" <Br...@turner.com>.
On 4/15/08 12:27 PM, "Brad Nicholes" <BN...@novell.com> wrote:
>IOW, we may be required to be conservative
> when it comes to 1.3.x, 2.0.x or 2.2.x, but the same level of conservatism
> shouldn't apply to 2.4 or 3.0.
Which is one of the reasons I think now is the time to completely redo the
configuration scheme. I think Paul would agree with me that we should just
embed Lua (not as mod_wombat) and be done with it.
--
Brian Akins
Chief Operations Engineer
Turner Digital Media Technologies
Re: [PROPOSAL] Time Based Releases
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/15/2008 at 5:49 AM, in message <48...@rowe-clan.net>, "William
A. Rowe, Jr." <wr...@rowe-clan.net> wrote:
> Jim Jagielski wrote:
>> I think what Paul is suggesting (he will for sure correct me
>> if I'm wrong) is that it's better to at least have some semblance
>> of a schedule than not, and by baselining every X months for a release,
>> it provides us, as volunteers, to better allocate time. It does
>> not mean, imo, that we rush out packages that aren't ready or
>> release something just because "we have a schedule to keep"...
>> we all have day jobs that force that on us, and we don't want
>> that kind of pressure here as well.
>>
>> However, looking over things, I think that we have enough active
>> activity such that a ~3month "cycle" might be workable...
>
> IOW, if we declare a 2 month cycle, we end up with releases every
> three months ;-)
I believe that it would benefit the project to do releases a little more frequently than we have in the past, I would just rather see the project release because a release is warranted. Not because a schedule dictates that we do it. I guess I have always liked the fact that Apache does things because it is the right thing to do, not because there is some artificial requirement. If Paul wants to release every two months, more power to him and to the project. Just do it, we shouldn't have to take a vote or change any of our existing written or unwritten policies.
Maybe the real problem is that the Apache httpd project has lost some of the passion that it used to have. I think that is what Roy was saying in the Keynote slides that Paul forwarded to the list. Maybe the problem is that we have all become a little too conservative when it comes to releases because we have all realized just how much people depend on this little piece of software. However that conservative attitude only applies to the past, it shouldn't apply to the future. IOW, we may be required to be conservative when it comes to 1.3.x, 2.0.x or 2.2.x, but the same level of conservatism shouldn't apply to 2.4 or 3.0. It's been 3 1/2 years since we started the last major release cycle of the httpd server and 2 1/2 years since the last major release of the web server. That's longer than many if not most commercial products. So what, if some of the 2.3 features are not fully baked or if some things may not work quite right. Why should that stop the project from releasing something anyway, whatever that something might be. If it is adopted and accepted, then great. If it falls on its face then we know what not to do the next time.
I know, I am probably preaching to the choir and it may even sound like I am arguing both sides of the subject line above. But if we want to get the passion back in the project, then it might be time for the project to take some more risks. Release because it is the right thing to do.
Brad
Re: [PROPOSAL] Time Based Releases
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jim Jagielski wrote:
> I think what Paul is suggesting (he will for sure correct me
> if I'm wrong) is that it's better to at least have some semblance
> of a schedule than not, and by baselining every X months for a release,
> it provides us, as volunteers, to better allocate time. It does
> not mean, imo, that we rush out packages that aren't ready or
> release something just because "we have a schedule to keep"...
> we all have day jobs that force that on us, and we don't want
> that kind of pressure here as well.
>
> However, looking over things, I think that we have enough active
> activity such that a ~3month "cycle" might be workable...
IOW, if we declare a 2 month cycle, we end up with releases every
three months ;-)
Re: [PROPOSAL] Time Based Releases
Posted by Jim Jagielski <ji...@jaguNET.com>.
I think what Paul is suggesting (he will for sure correct me
if I'm wrong) is that it's better to at least have some semblance
of a schedule than not, and by baselining every X months for a release,
it provides us, as volunteers, to better allocate time. It does
not mean, imo, that we rush out packages that aren't ready or
release something just because "we have a schedule to keep"...
we all have day jobs that force that on us, and we don't want
that kind of pressure here as well.
However, looking over things, I think that we have enough active
activity such that a ~3month "cycle" might be workable...
Re: [PROPOSAL] Time Based Releases
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Brad Nicholes [mailto:BNICHOLES@novell.com]
> Gesendet: Montag, 14. April 2008 17:44
> An: dev@httpd.apache.org
> Betreff: Re: [PROPOSAL] Time Based Releases
>
> >>> On 4/12/2008 at 11:20 AM, in message
> <48...@force-elite.com>, Paul
> Querna <ch...@force-elite.com> wrote:
> > This is something I have been thinking about for awhile,
> and discussed
> > with a few other http server people before.
> >
> > I think that for the 'stable' branch, we should move to
> time based releases.
> >
> > My proposal is for every 2 months, we do a release of the
> main stable
> > branch, which at this time is 2.2.x.
> >
> > Security Issues of great importance of course would trigger
> an immediate
> > release. Depending on the nearness to a scheduled release,
> we may or
> > may not scrap the next time based release.
> >
>
> I guess I am not sure what setting a schedule is trying to
> accomplish. Can't you do this already? If somebody wants to
> release every 2 months, that person can call for the release
> and be the RM every two months. In other words, as long as
> there is somebody willing to do the work, then the work will
> happen. If a release isn't required, ie. no real appreciable
> improvement since the previous release, then why require
> everyone to mobilize for very little gain. I guess I am
> looking for the problem that a hard schedule resolves when we
> can already release as early or as often as desired.
Well put. Reminds me of André's question "What problem are we trying to solve?"
The only benefit I can see in the schedule is that it gives all of us a gentle
reminder every x month that we should think about a new release. If there are
not enough people then that think that a release makes sense then there will
be no release.
So my point in proposing a longer period than the two month is that I want
to increase the likelyhood that enough people think that a release makes sense.
IMHO it would be a pity if the RM puts its valueable time in creating a
release tarball that fails to get the needed votes.
Even if gets enough votes I think it would be bad if the testing is limited
due to a tough schedule which could lower the quality of the release.
Regards
Rüdiger
Re: [PROPOSAL] Time Based Releases
Posted by Brad Nicholes <BN...@novell.com>.
>>> On 4/12/2008 at 11:20 AM, in message <48...@force-elite.com>, Paul
Querna <ch...@force-elite.com> wrote:
> This is something I have been thinking about for awhile, and discussed
> with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based releases.
>
> My proposal is for every 2 months, we do a release of the main stable
> branch, which at this time is 2.2.x.
>
> Security Issues of great importance of course would trigger an immediate
> release. Depending on the nearness to a scheduled release, we may or
> may not scrap the next time based release.
>
I guess I am not sure what setting a schedule is trying to accomplish. Can't you do this already? If somebody wants to release every 2 months, that person can call for the release and be the RM every two months. In other words, as long as there is somebody willing to do the work, then the work will happen. If a release isn't required, ie. no real appreciable improvement since the previous release, then why require everyone to mobilize for very little gain. I guess I am looking for the problem that a hard schedule resolves when we can already release as early or as often as desired.
Brad
Re: [PROPOSAL] Time Based Releases
Posted by André Malo <nd...@perlig.de>.
* Paul Querna wrote:
> This is something I have been thinking about for awhile, and discussed
> with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.
This would be the place for ", because [...]" ;-)
So, what problem are you trying to solve?
nd
--
$_=q?tvc!uif)%*|#Bopuifs!A`#~tvc!Xibu)%*|qsjou#Kvtu!A`#~tvc!KBQI!)*|~
tvc!ifmm)%*|#Qfsm!A`#~tvc!jt)%*|(Ibdlfs(~ # What the hell is JAPH? ;
@_=split/\s\s+#/;$_=(join''=>map{chr(ord( # André Malo ;
$_)-1)}split//=>$_[0]).$_[1];s s.*s$_see; # http://www.perlig.de/ ;
Re: [PROPOSAL] Time Based Releases
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 13, 2008, at 11:05 AM, Lars Eilebrecht wrote:
> According to Paul:
>
>> My proposal is for every 2 months, we do a release of the main stable
>> branch, which at this time is 2.2.x.
>
> +1 on the concept, but in my opinion 2 month is too short.
> 3-4 month would be better.
If two months is too short for some folks, I recommend you test every
other release instead of every one -- there's no sense slowing us down
if we have plenty of folks capable of testing any given release.
If it really turns out to be too short, we just won't have enough +1s.
....Roy
Re: [PROPOSAL] Time Based Releases
Posted by Lars Eilebrecht <la...@eilebrecht.net>.
According to Paul:
> My proposal is for every 2 months, we do a release of the main stable
> branch, which at this time is 2.2.x.
+1 on the concept, but in my opinion 2 month is too short.
3-4 month would be better.
ciao...
--
Lars Eilebrecht
lars@eilebrecht.net
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
jean-frederic clere wrote:
> I have looked to #44803 in fact we need something like JkOptions
> +ForwardURIEscaped which means something that requires changes in both
> mod_rewrite and mod_proxy.
> I will propose a patch soon.
Thank you!
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jess Holle
> Gesendet: Donnerstag, 17. April 2008 16:50
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> Jess Holle wrote:
> > Jim Jagielski wrote:
> >> Can you try:
> >>
> >> Index: modules/proxy/mod_proxy_ajp.c
> >> ===================================================================
> >> --- modules/proxy/mod_proxy_ajp.c (revision 648735)
> >> +++ modules/proxy/mod_proxy_ajp.c (working copy)
> >> @@ -72,8 +72,13 @@
> >> search = r->args;
> >>
> >> /* process path */
> >> - path = ap_proxy_canonenc(r->pool, url, strlen(url),
> enc_path, 0,
> >> - r->proxyreq);
> >> + if (apr_table_get(r->notes, "proxy-nocanon")) {
> >> + path = url; /* this is the raw path */
> >> + }
> >> + else {
> >> + path = ap_proxy_canonenc(r->pool, url, strlen(url),
> >> + enc_path, 0, r->proxyreq);
> >> + }
> >> if (path == NULL)
> >> return HTTP_BAD_REQUEST;
> > I don't do our Apache builds any more (and don't have
> things set up to
> > do so), but our engineer who does is slated to test the
> patch attached
> > to the bug soon.
> >
> > Is this the same as the patch attached to the bug report -- or a
> > different one?
> To be more clear exactly which patch should we be testing?
You better go with the one from the bug report. Otherwise you end up with
doubled query strings.
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Jim Jagielski wrote:
>> Can you try:
>>
>> Index: modules/proxy/mod_proxy_ajp.c
>> ===================================================================
>> --- modules/proxy/mod_proxy_ajp.c (revision 648735)
>> +++ modules/proxy/mod_proxy_ajp.c (working copy)
>> @@ -72,8 +72,13 @@
>> search = r->args;
>>
>> /* process path */
>> - path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
>> - r->proxyreq);
>> + if (apr_table_get(r->notes, "proxy-nocanon")) {
>> + path = url; /* this is the raw path */
>> + }
>> + else {
>> + path = ap_proxy_canonenc(r->pool, url, strlen(url),
>> + enc_path, 0, r->proxyreq);
>> + }
>> if (path == NULL)
>> return HTTP_BAD_REQUEST;
> I don't do our Apache builds any more (and don't have things set up to
> do so), but our engineer who does is slated to test the patch attached
> to the bug soon.
>
> Is this the same as the patch attached to the bug report -- or a
> different one?
To be more clear exactly which patch should we be testing?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
Jim Jagielski wrote:
> This section is the same as that in the bug report (make mod_proxy_ajp
> aware of the nocanon EnvVar), but the attached patch also includes
> a workaround for the doubling of any query strings. This 2nd part
> needs to be addressed but the real fix may not be done by
> this patch. If you have no query args, then either is fine.
We generally have query strings (and have to support the most general
case due to the number of quite disparate pages being served), so we'll
need the full patch. Thanks.
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 10:48 AM, Jess Holle wrote:
> Jim Jagielski wrote:
>> Can you try:
>>
>> Index: modules/proxy/mod_proxy_ajp.c
>> ===================================================================
>> --- modules/proxy/mod_proxy_ajp.c (revision 648735)
>> +++ modules/proxy/mod_proxy_ajp.c (working copy)
>> @@ -72,8 +72,13 @@
>> search = r->args;
>>
>> /* process path */
>> - path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
>> - r->proxyreq);
>> + if (apr_table_get(r->notes, "proxy-nocanon")) {
>> + path = url; /* this is the raw path */
>> + }
>> + else {
>> + path = ap_proxy_canonenc(r->pool, url, strlen(url),
>> + enc_path, 0, r->proxyreq);
>> + }
>> if (path == NULL)
>> return HTTP_BAD_REQUEST;
> I don't do our Apache builds any more (and don't have things set up
> to do so), but our engineer who does is slated to test the patch
> attached to the bug soon.
>
> Is this the same as the patch attached to the bug report -- or a
> different one?
>
This section is the same as that in the bug report (make mod_proxy_ajp
aware of the nocanon EnvVar), but the attached patch also includes
a workaround for the doubling of any query strings. This 2nd part
needs to be addressed but the real fix may not be done by
this patch. If you have no query args, then either is fine.
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
Jim Jagielski wrote:
> Can you try:
>
> Index: modules/proxy/mod_proxy_ajp.c
> ===================================================================
> --- modules/proxy/mod_proxy_ajp.c (revision 648735)
> +++ modules/proxy/mod_proxy_ajp.c (working copy)
> @@ -72,8 +72,13 @@
> search = r->args;
>
> /* process path */
> - path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
> - r->proxyreq);
> + if (apr_table_get(r->notes, "proxy-nocanon")) {
> + path = url; /* this is the raw path */
> + }
> + else {
> + path = ap_proxy_canonenc(r->pool, url, strlen(url),
> + enc_path, 0, r->proxyreq);
> + }
> if (path == NULL)
> return HTTP_BAD_REQUEST;
I don't do our Apache builds any more (and don't have things set up to
do so), but our engineer who does is slated to test the patch attached
to the bug soon.
Is this the same as the patch attached to the bug report -- or a
different one?
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote:
> jean-frederic clere wrote:
>>> IMHO we already forward them escaped. The problem is that things get
>>> unescaped first and for reserved characters like ';' this process
>>> cannot be reverted. So if the original URL contained an escaped ';'
>>> the forwarded one will contain a literal ';'.
>>> With mod_proxy or better ProxyPass you already can get around this
>>> by specifying the nocanon option which causes the the original
>>> URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
>> No nocanon doesn't do that. it use url (in which the %3B is already
>> converted in ;) instead the r->unparsed_uri.
>> And that would be JK_OPT_FWDURICOMPATUNPARSED and not
>> ForwardURIEscaped.
>> To get ForwardURIEscaped we could call ap_escape_uri() on url.
> I can confirm that using ProxyPass and nocanon does not solve the
> problem -- I just tested this.
Can you try:
Index: modules/proxy/mod_proxy_ajp.c
===================================================================
--- modules/proxy/mod_proxy_ajp.c (revision 648735)
+++ modules/proxy/mod_proxy_ajp.c (working copy)
@@ -72,8 +72,13 @@
search = r->args;
/* process path */
- path = ap_proxy_canonenc(r->pool, url, strlen(url), enc_path, 0,
- r->proxyreq);
+ if (apr_table_get(r->notes, "proxy-nocanon")) {
+ path = url; /* this is the raw path */
+ }
+ else {
+ path = ap_proxy_canonenc(r->pool, url, strlen(url),
+ enc_path, 0, r->proxyreq);
+ }
if (path == NULL)
return HTTP_BAD_REQUEST;
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 7:59 AM, Jess Holle wrote:
> jean-frederic clere wrote:
>>> IMHO we already forward them escaped. The problem is that things get
>>> unescaped first and for reserved characters like ';' this process
>>> cannot be reverted. So if the original URL contained an escaped ';'
>>> the forwarded one will contain a literal ';'.
>>> With mod_proxy or better ProxyPass you already can get around this
>>> by specifying the nocanon option which causes the the original
>>> URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
>> No nocanon doesn't do that. it use url (in which the %3B is already
>> converted in ;) instead the r->unparsed_uri.
>> And that would be JK_OPT_FWDURICOMPATUNPARSED and not
>> ForwardURIEscaped.
>> To get ForwardURIEscaped we could call ap_escape_uri() on url.
> I can confirm that using ProxyPass and nocanon does not solve the
> problem -- I just tested this.
>
Hmmm.... mod_proxy_http is aware, but methinks mod_proxy_ajp may not be
at this point :/
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 10:25 AM, Jim Jagielski wrote:
>
> On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote:
>>
>> But sure this could be also fixed in the appropriate canon_handler
>> hooks of mod_proxy_http and mod_proxy_ajp.
>>
>
> That's what I'm wondering... Treating this "special" inside
> of mod_proxy itself, when it's really a protocol issue (and
> what is "right" for that protocol) just seems a safer way.
> Or, at least, helps to maintain that illusion of abstraction :)
>
Something like:
Index: mod_proxy_http.c
===================================================================
--- mod_proxy_http.c (revision 649076)
+++ mod_proxy_http.c (working copy)
@@ -72,7 +72,9 @@
* has already been decoded. True proxy requests have r->uri
* == r->unparsed_uri, and no others have that property.
*/
- if (r->uri == r->unparsed_uri) {
+ if ((r->uri == r->unparsed_uri) ||
+ ((r->proxyreq == PROXYREQ_REVERSE) &&
+ apr_table_get(r->notes, "proxy-nocanon"))) {
search = strchr(url, '?');
if (search != NULL)
*(search++) = '\0';
ajp and fcgi similarly... :)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 10:04 AM, Plüm, Rüdiger, VF-Group wrote:
>
> But sure this could be also fixed in the appropriate canon_handler
> hooks of mod_proxy_http and mod_proxy_ajp.
>
That's what I'm wondering... Treating this "special" inside
of mod_proxy itself, when it's really a protocol issue (and
what is "right" for that protocol) just seems a safer way.
Or, at least, helps to maintain that illusion of abstraction :)
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jim Jagielski
> Gesendet: Donnerstag, 17. April 2008 15:16
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
>
> On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote:
> > But the patch I just attached to PR44803 should fix this:
> >
> > https://issues.apache.org/bugzilla/attachment.cgi?id=21826
> >
>
> :)
>
> Obviously, +1 on the mod_proxy_ajp patch (within minutes
> we had the same idea). Mulling over the impacts of the
Yep :-)
> up_uri_wout_query part though...
The query string was present twice (one from unparsed_uri which
still contains the query string and one that was added via r->query
later when running the canon_handler hook).
But sure this could be also fixed in the appropriate canon_handler
hooks of mod_proxy_http and mod_proxy_ajp.
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 17, 2008, at 8:46 AM, Plüm, Rüdiger, VF-Group wrote:
> But the patch I just attached to PR44803 should fix this:
>
> https://issues.apache.org/bugzilla/attachment.cgi?id=21826
>
:)
Obviously, +1 on the mod_proxy_ajp patch (within minutes
we had the same idea). Mulling over the impacts of the
up_uri_wout_query part though...
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jess Holle
> Gesendet: Donnerstag, 17. April 2008 13:59
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> jean-frederic clere wrote:
> >> IMHO we already forward them escaped. The problem is that
> things get
> >> unescaped first and for reserved characters like ';' this process
> >> cannot be reverted. So if the original URL contained an escaped ';'
> >> the forwarded one will contain a literal ';'.
> >> With mod_proxy or better ProxyPass you already can get around this
> >> by specifying the nocanon option which causes the the original
> >> URL to be forwarded (much like JkOptions
> +ForwardURICompatUnparsed).
> > No nocanon doesn't do that. it use url (in which the %3B is already
> > converted in ;) instead the r->unparsed_uri.
> > And that would be JK_OPT_FWDURICOMPATUNPARSED and not
> ForwardURIEscaped.
> > To get ForwardURIEscaped we could call ap_escape_uri() on url.
> I can confirm that using ProxyPass and nocanon does not solve the
> problem -- I just tested this.
I jsut retested with trunk again (/test/foo%3Bbar?spaz=bot).
In the nocanon case we sent
/test/foo%253Bbar%3Fspaz=bot
via AJP (network sniff) and in the case without noncanon we sent
/test/foo;bar
So in the first case we escape too often and in the second we do not
escape enough.
But the patch I just attached to PR44803 should fix this:
https://issues.apache.org/bugzilla/attachment.cgi?id=21826
So ProxyPassMatch does now work as desired (with option nocanon of
course).
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
jean-frederic clere wrote:
>> IMHO we already forward them escaped. The problem is that things get
>> unescaped first and for reserved characters like ';' this process
>> cannot be reverted. So if the original URL contained an escaped ';'
>> the forwarded one will contain a literal ';'.
>> With mod_proxy or better ProxyPass you already can get around this
>> by specifying the nocanon option which causes the the original
>> URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
> No nocanon doesn't do that. it use url (in which the %3B is already
> converted in ;) instead the r->unparsed_uri.
> And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped.
> To get ForwardURIEscaped we could call ap_escape_uri() on url.
I can confirm that using ProxyPass and nocanon does not solve the
problem -- I just tested this.
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: jean-frederic clere
> Gesendet: Donnerstag, 17. April 2008 13:39
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> Plüm wrote:
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: jean-frederic clere
> >> Gesendet: Donnerstag, 17. April 2008 11:02
> >> An: dev@httpd.apache.org
> >> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
> >>
> >> Jim Jagielski wrote:
> >>> On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:
> >>>> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
> >>>>> Jim Jagielski wrote:
> >>>>>> Plus, every 3 months would coincide with the
> >> report-to-board cycle,
> >>>>>> making it easier for everyone to follow :) Next is due
> in May, so
> >>>>>> if we release this month, then we can follow a "Release before
> >>>>>> the board report" or else "Release at board report" cycle (with
> >>>>>> the caveat I noted before ;) )
> >>>>>>
> >>>>>> As noted (and as I pinged a few people about in Amsterdam), I'm
> >>>>>> looking to push for a 2.2.9 soon. We have enough for sure
> >>>>>> warrant it... There is the "ship 1.3.0 with 2.2.9"
> >> thread going on,
> >>>>>> but I do not want 2.2.9 to hold off too long for that...
> >>>>>>
> >>>>>> So I'd like to propose 2.2.9 for the end of this month.
> >>>>> Sorry to butt in, but is there any hope of getting issue #44803
> >>>>> addressed in that timeframe?
> >>>>>
> >>>> Possibly, yes.
> >>>>
> >>> Quick look: We need to re-adjust this post fixups, since this
> >>> should be a setting ala flushpackets, etc...
> >>>
> >>>
> >> I have looked to #44803 in fact we need something like JkOptions
> >> +ForwardURIEscaped which means something that requires
> >
> > IMHO we already forward them escaped. The problem is that things get
> > unescaped first and for reserved characters like ';' this process
> > cannot be reverted. So if the original URL contained an escaped ';'
> > the forwarded one will contain a literal ';'.
> > With mod_proxy or better ProxyPass you already can get around this
> > by specifying the nocanon option which causes the the original
> > URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
>
> No nocanon doesn't do that. it use url (in which the %3B is already
> converted in ;) instead the r->unparsed_uri.
No. It does use r->unparsed_uri if r->uri and r->unparsed_uri both match
the ProxyPass(Match) condition.
> And that would be JK_OPT_FWDURICOMPATUNPARSED and not
> ForwardURIEscaped.
> To get ForwardURIEscaped we could call ap_escape_uri() on url.
We don't need to as we already call ap_proxy_canonenc on the URL which
does this.
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by jean-frederic clere <jf...@gmail.com>.
Plüm wrote:
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: jean-frederic clere [mailto:jfclere@gmail.com]
>> Gesendet: Donnerstag, 17. April 2008 11:02
>> An: dev@httpd.apache.org
>> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>>
>> Jim Jagielski wrote:
>>> On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:
>>>> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
>>>>> Jim Jagielski wrote:
>>>>>> Plus, every 3 months would coincide with the
>> report-to-board cycle,
>>>>>> making it easier for everyone to follow :) Next is due in May, so
>>>>>> if we release this month, then we can follow a "Release before
>>>>>> the board report" or else "Release at board report" cycle (with
>>>>>> the caveat I noted before ;) )
>>>>>>
>>>>>> As noted (and as I pinged a few people about in Amsterdam), I'm
>>>>>> looking to push for a 2.2.9 soon. We have enough for sure
>>>>>> warrant it... There is the "ship 1.3.0 with 2.2.9"
>> thread going on,
>>>>>> but I do not want 2.2.9 to hold off too long for that...
>>>>>>
>>>>>> So I'd like to propose 2.2.9 for the end of this month.
>>>>> Sorry to butt in, but is there any hope of getting issue #44803
>>>>> addressed in that timeframe?
>>>>>
>>>> Possibly, yes.
>>>>
>>> Quick look: We need to re-adjust this post fixups, since this
>>> should be a setting ala flushpackets, etc...
>>>
>>>
>> I have looked to #44803 in fact we need something like JkOptions
>> +ForwardURIEscaped which means something that requires
>
> IMHO we already forward them escaped. The problem is that things get
> unescaped first and for reserved characters like ';' this process
> cannot be reverted. So if the original URL contained an escaped ';'
> the forwarded one will contain a literal ';'.
> With mod_proxy or better ProxyPass you already can get around this
> by specifying the nocanon option which causes the the original
> URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
No nocanon doesn't do that. it use url (in which the %3B is already
converted in ;) instead the r->unparsed_uri.
And that would be JK_OPT_FWDURICOMPATUNPARSED and not ForwardURIEscaped.
To get ForwardURIEscaped we could call ap_escape_uri() on url.
Cheers
Jean-Frederic
>
> Regards
>
> Rüdiger
>
>
>
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: Jess Holle [mailto:jessh@ptc.com]
> Gesendet: Donnerstag, 17. April 2008 12:36
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> Plüm wrote:
> > IMHO we already forward them escaped. The problem is that things get
> > unescaped first and for reserved characters like ';' this process
> > cannot be reverted. So if the original URL contained an escaped ';'
> > the forwarded one will contain a literal ';'.
> > With mod_proxy or better ProxyPass you already can get around this
> > by specifying the nocanon option which causes the the original
> > URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
> >
> That makes sense -- as we're only having issues with ";" to
> the best of
> my knowledge.
>
> That said, we need to use the rewrite stuff shown in the bug (unless
> there's another way we're missing) to forward just the appropriate
> requests to Tomcat. Is there a way we're missing (that would
> ideally be
> clearly documented...) to avoid running into issues with ";"
> when using
> mod_proxy and mod_rewrite as we are? If not, then one is
> really needed
> for ";".
Have your tried something like
ProxyPassMatch (^/somewhere/.*jsp$) http://backend$1 nocanon
?
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
Plüm wrote:
> IMHO we already forward them escaped. The problem is that things get
> unescaped first and for reserved characters like ';' this process
> cannot be reverted. So if the original URL contained an escaped ';'
> the forwarded one will contain a literal ';'.
> With mod_proxy or better ProxyPass you already can get around this
> by specifying the nocanon option which causes the the original
> URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
>
That makes sense -- as we're only having issues with ";" to the best of
my knowledge.
That said, we need to use the rewrite stuff shown in the bug (unless
there's another way we're missing) to forward just the appropriate
requests to Tomcat. Is there a way we're missing (that would ideally be
clearly documented...) to avoid running into issues with ";" when using
mod_proxy and mod_rewrite as we are? If not, then one is really needed
for ";".
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Plüm,
Rüdiger,
VF-Group <ru...@vodafone.com>.
> -----Ursprüngliche Nachricht-----
> Von: jean-frederic clere [mailto:jfclere@gmail.com]
> Gesendet: Donnerstag, 17. April 2008 11:02
> An: dev@httpd.apache.org
> Betreff: Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
>
> Jim Jagielski wrote:
> >
> > On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:
> >>
> >> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
> >>> Jim Jagielski wrote:
> >>>> Plus, every 3 months would coincide with the
> report-to-board cycle,
> >>>> making it easier for everyone to follow :) Next is due in May, so
> >>>> if we release this month, then we can follow a "Release before
> >>>> the board report" or else "Release at board report" cycle (with
> >>>> the caveat I noted before ;) )
> >>>>
> >>>> As noted (and as I pinged a few people about in Amsterdam), I'm
> >>>> looking to push for a 2.2.9 soon. We have enough for sure
> >>>> warrant it... There is the "ship 1.3.0 with 2.2.9"
> thread going on,
> >>>> but I do not want 2.2.9 to hold off too long for that...
> >>>>
> >>>> So I'd like to propose 2.2.9 for the end of this month.
> >>> Sorry to butt in, but is there any hope of getting issue #44803
> >>> addressed in that timeframe?
> >>>
> >>
> >> Possibly, yes.
> >>
> >
> > Quick look: We need to re-adjust this post fixups, since this
> > should be a setting ala flushpackets, etc...
> >
> >
>
> I have looked to #44803 in fact we need something like JkOptions
> +ForwardURIEscaped which means something that requires
IMHO we already forward them escaped. The problem is that things get
unescaped first and for reserved characters like ';' this process
cannot be reverted. So if the original URL contained an escaped ';'
the forwarded one will contain a literal ';'.
With mod_proxy or better ProxyPass you already can get around this
by specifying the nocanon option which causes the the original
URL to be forwarded (much like JkOptions +ForwardURICompatUnparsed).
Regards
Rüdiger
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by jean-frederic clere <jf...@gmail.com>.
Jim Jagielski wrote:
>
> On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:
>>
>> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
>>> Jim Jagielski wrote:
>>>> Plus, every 3 months would coincide with the report-to-board cycle,
>>>> making it easier for everyone to follow :) Next is due in May, so
>>>> if we release this month, then we can follow a "Release before
>>>> the board report" or else "Release at board report" cycle (with
>>>> the caveat I noted before ;) )
>>>>
>>>> As noted (and as I pinged a few people about in Amsterdam), I'm
>>>> looking to push for a 2.2.9 soon. We have enough for sure
>>>> warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on,
>>>> but I do not want 2.2.9 to hold off too long for that...
>>>>
>>>> So I'd like to propose 2.2.9 for the end of this month.
>>> Sorry to butt in, but is there any hope of getting issue #44803
>>> addressed in that timeframe?
>>>
>>
>> Possibly, yes.
>>
>
> Quick look: We need to re-adjust this post fixups, since this
> should be a setting ala flushpackets, etc...
>
>
I have looked to #44803 in fact we need something like JkOptions
+ForwardURIEscaped which means something that requires changes in both
mod_rewrite and mod_proxy.
I will propose a patch soon.
Cheers
Jean-Frederic
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 14, 2008, at 10:15 AM, Jim Jagielski wrote:
>
> On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
>> Jim Jagielski wrote:
>>> Plus, every 3 months would coincide with the report-to-board cycle,
>>> making it easier for everyone to follow :) Next is due in May, so
>>> if we release this month, then we can follow a "Release before
>>> the board report" or else "Release at board report" cycle (with
>>> the caveat I noted before ;) )
>>>
>>> As noted (and as I pinged a few people about in Amsterdam), I'm
>>> looking to push for a 2.2.9 soon. We have enough for sure
>>> warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on,
>>> but I do not want 2.2.9 to hold off too long for that...
>>>
>>> So I'd like to propose 2.2.9 for the end of this month.
>> Sorry to butt in, but is there any hope of getting issue #44803
>> addressed in that timeframe?
>>
>
> Possibly, yes.
>
Quick look: We need to re-adjust this post fixups, since this
should be a setting ala flushpackets, etc...
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 14, 2008, at 10:00 AM, Jess Holle wrote:
> Jim Jagielski wrote:
>> Plus, every 3 months would coincide with the report-to-board cycle,
>> making it easier for everyone to follow :) Next is due in May, so
>> if we release this month, then we can follow a "Release before
>> the board report" or else "Release at board report" cycle (with
>> the caveat I noted before ;) )
>>
>> As noted (and as I pinged a few people about in Amsterdam), I'm
>> looking to push for a 2.2.9 soon. We have enough for sure
>> warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on,
>> but I do not want 2.2.9 to hold off too long for that...
>>
>> So I'd like to propose 2.2.9 for the end of this month.
> Sorry to butt in, but is there any hope of getting issue #44803
> addressed in that timeframe?
>
Possibly, yes.
The feedback on the "real" gap between mod_jk and mod_proxy_ajp is
stuff we really appreciate! Thanks!
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jess Holle <je...@ptc.com>.
Jim Jagielski wrote:
> Plus, every 3 months would coincide with the report-to-board cycle,
> making it easier for everyone to follow :) Next is due in May, so
> if we release this month, then we can follow a "Release before
> the board report" or else "Release at board report" cycle (with
> the caveat I noted before ;) )
>
> As noted (and as I pinged a few people about in Amsterdam), I'm
> looking to push for a 2.2.9 soon. We have enough for sure
> warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on,
> but I do not want 2.2.9 to hold off too long for that...
>
> So I'd like to propose 2.2.9 for the end of this month.
Sorry to butt in, but is there any hope of getting issue #44803
addressed in that timeframe?
[The gap between mod_jk and mod_proxy_ajp in this and other areas (I
don't believe it can set a longer packet size than 8K yet) is a bit
troubling...]
--
Jess Holle
Re: 2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
I've just updated STATUS to reflect that I'm hoping for us
to drive towards a 2.2.9 release by the end of this month...
2.2.9 (Was: Re: [PROPOSAL] Time Based Releases)
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Apr 13, 2008, at 3:32 AM, Justin Erenkrantz wrote:
> On Sat, Apr 12, 2008 at 9:52 PM, Ruediger Pluem <rp...@apache.org>
> wrote:
>>> My proposal is for every 2 months, we do a release of the main
>>> stable
>> branch, which at this time is 2.2.x.
>>>
>>
>> I would like to go for 3 month, so four times per year or once each
>> quarter.
>
> I think it's a good idea - except I think 2 months is a little too
> frequent as well. That means 1 week out of every 8 that we're
> spending checking and testing the release. 1 out of 12 weeks eases it
> a bit...so +1 for every three months. -- justin
>
Plus, every 3 months would coincide with the report-to-board cycle,
making it easier for everyone to follow :) Next is due in May, so
if we release this month, then we can follow a "Release before
the board report" or else "Release at board report" cycle (with
the caveat I noted before ;) )
As noted (and as I pinged a few people about in Amsterdam), I'm
looking to push for a 2.2.9 soon. We have enough for sure
warrant it... There is the "ship 1.3.0 with 2.2.9" thread going on,
but I do not want 2.2.9 to hold off too long for that...
So I'd like to propose 2.2.9 for the end of this month.
Re: [PROPOSAL] Time Based Releases
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Sat, Apr 12, 2008 at 9:52 PM, Ruediger Pluem <rp...@apache.org> wrote:
> > My proposal is for every 2 months, we do a release of the main stable
> branch, which at this time is 2.2.x.
> >
>
> I would like to go for 3 month, so four times per year or once each
> quarter.
I think it's a good idea - except I think 2 months is a little too
frequent as well. That means 1 week out of every 8 that we're
spending checking and testing the release. 1 out of 12 weeks eases it
a bit...so +1 for every three months. -- justin
Re: [PROPOSAL] Time Based Releases
Posted by Ruediger Pluem <rp...@apache.org>.
On 04/12/2008 07:20 PM, Paul Querna wrote:
> This is something I have been thinking about for awhile, and discussed
> with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.
I like this if it is seen as some kind of reminder that we really should
do a new release. But I would not like to see the timeframe written into
stone. It should be possible to
- postpone the release if we can't finish up an important patch at this
time which should be included in the next release (e.g. a regression)
or if we need to wait for an apr / apr-util release which might need
/ should also follow this schedule then. So quality before rush.
- skip a release if there are only very few and not important patches
(whatever this means could be subject to an interesting discussion :-),
but at least for the number of changes I tend to say <= 3).
It lowers the pain for (most) of our users and us, because a release
always creates work.
>
> My proposal is for every 2 months, we do a release of the main stable
> branch, which at this time is 2.2.x.
I would like to go for 3 month, so four times per year or once each quarter.
>
> Security Issues of great importance of course would trigger an immediate
> release. Depending on the nearness to a scheduled release, we may or
> may not scrap the next time based release.
Sure.
Regards
Rüdiger
Re: [PROPOSAL] Time Based Releases
Posted by Niklas Edmundsson <ni...@acc.umu.se>.
On Sat, 12 Apr 2008, Paul Querna wrote:
> This is something I have been thinking about for awhile, and discussed with a
> few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based releases.
Sounds sane. Even though there might only be small bugfixes it's a
good thing to release rather often to reduce the risk of having so
many new fixes and features that we trigger some weird bug in each
release that makes it unusable.
I suspect that this should really affect APR too since we have
examples of bugs that's fixed in APR trunk (or newer releases), an
example would be that for httpd 2.2.8 the included APR is broken wrt
bucket brigades and LFS on 32bit platforms...
> My proposal is for every 2 months, we do a release of the main stable branch,
> which at this time is 2.2.x.
+1, including the concerns that 3 months might be a more suitable goal
for releases (meaning that tagging 2 months after the last release
seems reasonable :) and that we should not write this in stone but
be flexible when needed.
/Nikke
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se
---------------------------------------------------------------------------
I'd love to, but I'm too young for that stuff.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Re: [PROPOSAL] Time Based Releases
Posted by Paul Querna <ch...@force-elite.com>.
Roy T. Fielding wrote:
> On Apr 12, 2008, at 7:20 PM, Paul Querna wrote:
>> This is something I have been thinking about for awhile, and discussed
>> with a few other http server people before.
>>
>> I think that for the 'stable' branch, we should move to time based
>> releases.
>>
>> My proposal is for every 2 months, we do a release of the main stable
>> branch, which at this time is 2.2.x.
>
> Assuming you mean time-based build-a-package and vote-on-it-to-release,
> then +1.
Yes.
And TBH, I think this will end up with me putting it in my iCal to
remind myself to start a release cycle attempt, and if anyone else helps
out, that would be a nice bonus.
-Paul
Re: [PROPOSAL] Time Based Releases
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Apr 12, 2008, at 7:20 PM, Paul Querna wrote:
> This is something I have been thinking about for awhile, and
> discussed with a few other http server people before.
>
> I think that for the 'stable' branch, we should move to time based
> releases.
>
> My proposal is for every 2 months, we do a release of the main
> stable branch, which at this time is 2.2.x.
Assuming you mean time-based build-a-package and vote-on-it-to-
release, then +1.
....Roy