You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jim Jagielski <ji...@apache.org> on 2010/06/01 18:08:12 UTC
What's next for 2.2 and 2.3/trunk?
Considering that 2.3/trunk is back to limbo-land, I'd like
to propose that we be more "aggressive" is backporting some
items. Even if under experimental, it would be nice if slotmem
and socache were backported. I also like the refactoring of
the providers for proxy in trunk as compared to 2.2, but
last time I suggested it, it looked like 2.3/2.4 was close(r)
to reality...
comments...?
Re: What's next for 2.2 and 2.3/trunk?
Posted by Dan Poirier <po...@pobox.com>.
On 2010-06-03 at 22:28, "William A. Rowe Jr." <wr...@rowe-clan.net> wrote:
> Not because of binary compatibility, but because users have certain
> expectations when they move from x.y.15 to x.y.16 that nothing much
> has changed, it's just lots of fixes. And if your backport ideas
> include a lot of config changes, well that further breaks the users
> expectations.
Absolutely. We can't be making changes in 2.2.x that break existing
configurations.
Dan
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/1/2010 11:08 AM, Jim Jagielski wrote:
> Considering that 2.3/trunk is back to limbo-land, I'd like
> to propose that we be more "aggressive" is backporting some
> items. Even if under experimental, it would be nice if slotmem
> and socache were backported. I also like the refactoring of
> the providers for proxy in trunk as compared to 2.2, but
> last time I suggested it, it looked like 2.3/2.4 was close(r)
> to reality...
>
> comments...?
I'd be strongly opposed to releasing all this refactoring of the
proxy suite, etc, into the 2.2 tree.
Not because of binary compatibility, but because users have certain
expectations when they move from x.y.15 to x.y.16 that nothing much
has changed, it's just lots of fixes. And if your backport ideas
include a lot of config changes, well that further breaks the users
expectations.
To accomplish what you like, if we collectively believe trunk has
stalled, would be to bump trunk to 2.5, and cross-pollinate a new
2.3 branch that can move forwards towards release.
I'd like to see what can be accomplished with trunk over the next
few weeks, and what agreements the project can come to, before we
take such a radical step as branching two development lines. If
bits of trunk that concern people can be sandboxed for the moment,
instead, that might be less pain.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
I got it... (no idea why my orig reply didn't make it thru)... I did
a chunk of the 2.2 releases so I have the procedure down.
On Jun 2, 2010, at 6:48 AM, Issac Goldstand wrote:
> Noone seems to have stepped up for this, so I'll voulenteer. Is there a RELEASE file somewhere with the exact protocol? (If not, I'll add that to trunk before bundling up the next RC)
>
> On 6/1/2010 11:49 PM, Paul Querna wrote:
>> On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski<ji...@apache.org> wrote:
>>
>>> Considering that 2.3/trunk is back to limbo-land, I'd like
>>> to propose that we be more "aggressive" is backporting some
>>> items. Even if under experimental, it would be nice if slotmem
>>> and socache were backported. I also like the refactoring of
>>> the providers for proxy in trunk as compared to 2.2, but
>>> last time I suggested it, it looked like 2.3/2.4 was close(r)
>>> to reality...
>>>
>>> comments...?
>>>
>> 2.2 came out 5.5 years ago. I strongly support shipping 2.4.
>>
>> i've not had time to try to ship more alpha/betas. Does anyone else
>> have time to head up RMing it?
>>
>> Its easy once you get it down, 2 commits, one run of of the release
>> shell script, and 3 emails.
>>
>
Re: What's next for 2.2 and 2.3/trunk?
Posted by Issac Goldstand <ma...@beamartyr.net>.
Noone seems to have stepped up for this, so I'll voulenteer. Is there a
RELEASE file somewhere with the exact protocol? (If not, I'll add that
to trunk before bundling up the next RC)
On 6/1/2010 11:49 PM, Paul Querna wrote:
> On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski<ji...@apache.org> wrote:
>
>> Considering that 2.3/trunk is back to limbo-land, I'd like
>> to propose that we be more "aggressive" is backporting some
>> items. Even if under experimental, it would be nice if slotmem
>> and socache were backported. I also like the refactoring of
>> the providers for proxy in trunk as compared to 2.2, but
>> last time I suggested it, it looked like 2.3/2.4 was close(r)
>> to reality...
>>
>> comments...?
>>
> 2.2 came out 5.5 years ago. I strongly support shipping 2.4.
>
> i've not had time to try to ship more alpha/betas. Does anyone else
> have time to head up RMing it?
>
> Its easy once you get it down, 2 commits, one run of of the release
> shell script, and 3 emails.
>
Re: Alpha of 2.3.6 next week
Posted by Eric Covener <co...@gmail.com>.
>> Sounds like the banner added here just needs to be dropped then, or am
>> I still lost?
>>
>> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?r1=909323&r2=909322&pathrev=909323
>
> drop that banner, rename the one at the top to 2.3.6 (I think that's
> what you mean)
Yep, misspoke. Fixed in r950761 with the 2.3.6 banner moved up to the
top (no security entries had to get moved)
--
Eric Covener
covener@gmail.com
Re: Alpha of 2.3.6 next week
Posted by Jeff Trawick <tr...@gmail.com>.
On Wed, Jun 2, 2010 at 4:51 PM, Eric Covener <co...@gmail.com> wrote:
> On Wed, Jun 2, 2010 at 2:42 PM, Sander Temme <sc...@apache.org> wrote:
>>
>> On Jun 2, 2010, at 11:11 AM, Eric Covener wrote:
>>
>>>> tags are cheap. If soon after 2.3.6 I need to do a 2.3.7
>>>> then I'm alright with that ;)
>>>
>>> slightly off-topic, how come our CHANGES has both a 2.3.6 and 2.3.7
>>> banner but there's no tag for the former?
>>
>> Per Jim, 2.3.6 will be tagged next week. 2.3.7 will follow afterwards.
>
> Sounds like the banner added here just needs to be dropped then, or am
> I still lost?
>
> http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?r1=909323&r2=909322&pathrev=909323
drop that banner, rename the one at the top to 2.3.6 (I think that's
what you mean)
Re: Alpha of 2.3.6 next week
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jun 2, 2010 at 2:42 PM, Sander Temme <sc...@apache.org> wrote:
>
> On Jun 2, 2010, at 11:11 AM, Eric Covener wrote:
>
>>> tags are cheap. If soon after 2.3.6 I need to do a 2.3.7
>>> then I'm alright with that ;)
>>
>> slightly off-topic, how come our CHANGES has both a 2.3.6 and 2.3.7
>> banner but there's no tag for the former?
>
> Per Jim, 2.3.6 will be tagged next week. 2.3.7 will follow afterwards.
Sounds like the banner added here just needs to be dropped then, or am
I still lost?
http://svn.apache.org/viewvc/httpd/httpd/trunk/CHANGES?r1=909323&r2=909322&pathrev=909323
>
> S.
>
> --
> Sander Temme
> sctemme@apache.org
> PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
>
>
>
>
--
Eric Covener
covener@gmail.com
Re: Alpha of 2.3.6 next week
Posted by Sander Temme <sc...@apache.org>.
On Jun 2, 2010, at 11:11 AM, Eric Covener wrote:
>> tags are cheap. If soon after 2.3.6 I need to do a 2.3.7
>> then I'm alright with that ;)
>
> slightly off-topic, how come our CHANGES has both a 2.3.6 and 2.3.7
> banner but there's no tag for the former?
Per Jim, 2.3.6 will be tagged next week. 2.3.7 will follow afterwards.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Alpha of 2.3.6 next week
Posted by Eric Covener <co...@gmail.com>.
> tags are cheap. If soon after 2.3.6 I need to do a 2.3.7
> then I'm alright with that ;)
slightly off-topic, how come our CHANGES has both a 2.3.6 and 2.3.7
banner but there's no tag for the former?
--
Eric Covener
covener@gmail.com
Re: Alpha of 2.3.6 next week
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2010, at 2:03 PM, Stefan Fritsch wrote:
> On Wednesday 02 June 2010, Sander Temme wrote:
>> On Jun 2, 2010, at 9:02 AM, Eric Covener wrote:
>>> On Wed, Jun 2, 2010 at 11:55 AM, Jim Jagielski <ji...@jagunet.com>
> wrote:
>>>> I'm planning on releasing an alpha of 2.3.6 next week in
>>>> hopes that we can push out a beta v. soon after.
>>>
>>> Were infra's concerns wrapped up from the last alpha?
>>
>> I'm sorry, I've had blackouts covering this list. What were their
>> concerns? Were they discussed on this list?
>
>
> There was at least some mod_deflate issue
>
> http://mail-archives.apache.org/mod_mbox/httpd-
> dev/201002.mbox/<42...@mail.gmail.com>
>
> which was fixed in r910069. There was also talk about a mem leak but
> IIRC it was unclear if it is in httpd itself or in mod_mbox. I don't
> know if there were more concerns.
tags are cheap. If soon after 2.3.6 I need to do a 2.3.7
then I'm alright with that ;)
Re: Alpha of 2.3.6 next week
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Wednesday 02 June 2010, Sander Temme wrote:
> On Jun 2, 2010, at 9:02 AM, Eric Covener wrote:
> > On Wed, Jun 2, 2010 at 11:55 AM, Jim Jagielski <ji...@jagunet.com>
wrote:
> >> I'm planning on releasing an alpha of 2.3.6 next week in
> >> hopes that we can push out a beta v. soon after.
> >
> > Were infra's concerns wrapped up from the last alpha?
>
> I'm sorry, I've had blackouts covering this list. What were their
> concerns? Were they discussed on this list?
There was at least some mod_deflate issue
http://mail-archives.apache.org/mod_mbox/httpd-
dev/201002.mbox/<42...@mail.gmail.com>
which was fixed in r910069. There was also talk about a mem leak but
IIRC it was unclear if it is in httpd itself or in mod_mbox. I don't
know if there were more concerns.
Cheers,
Stefan
Re: Alpha of 2.3.6 next week
Posted by Sander Temme <sc...@apache.org>.
On Jun 2, 2010, at 9:02 AM, Eric Covener wrote:
> On Wed, Jun 2, 2010 at 11:55 AM, Jim Jagielski <ji...@jagunet.com> wrote:
>> I'm planning on releasing an alpha of 2.3.6 next week in
>> hopes that we can push out a beta v. soon after.
>
> Were infra's concerns wrapped up from the last alpha?
I'm sorry, I've had blackouts covering this list. What were their concerns? Were they discussed on this list?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: Alpha of 2.3.6 next week
Posted by Eric Covener <co...@gmail.com>.
On Wed, Jun 2, 2010 at 11:55 AM, Jim Jagielski <ji...@jagunet.com> wrote:
> I'm planning on releasing an alpha of 2.3.6 next week in
> hopes that we can push out a beta v. soon after.
Were infra's concerns wrapped up from the last alpha?
--
Eric Covener
covener@gmail.com
Re: Alpha of 2.3.6 next week
Posted by Graham Leggett <mi...@sharp.fm>.
On 02 Jun 2010, at 5:55 PM, Jim Jagielski wrote:
> I'm planning on releasing an alpha of 2.3.6 next week in
> hopes that we can push out a beta v. soon after.
Release early, release often :)
Regards,
Graham
--
Re: Alpha of 2.3.6 next week
Posted by Jim Jagielski <ji...@jaguNET.com>.
FWIW, I'm holding off based on a proxy/closing connection issue...
On Jun 10, 2010, at 8:47 AM, Jim Jagielski wrote:
> Okey dokey... unless I hear otherwise w/i a few hours, I will
> tag and roll 2.3.6-alpha
>
> On Jun 8, 2010, at 4:25 PM, Mario Brandt wrote:
>
>> Thanks Stefan,
>> it builds fine.
>>
>>
>> Mario
>>
>> On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch <sf...@sfritsch.de> wrote:
>>> This should be fixed now and I hopefully have also addressed Bill's
>>> concern about r952724. I don't see any blocker for an alpha-release
>>> anymore.
>>>
>>
>
Re: Alpha of 2.3.6 next week
Posted by Jim Jagielski <ji...@jaguNET.com>.
Okey dokey... unless I hear otherwise w/i a few hours, I will
tag and roll 2.3.6-alpha
On Jun 8, 2010, at 4:25 PM, Mario Brandt wrote:
> Thanks Stefan,
> it builds fine.
>
>
> Mario
>
> On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch <sf...@sfritsch.de> wrote:
>> This should be fixed now and I hopefully have also addressed Bill's
>> concern about r952724. I don't see any blocker for an alpha-release
>> anymore.
>>
>
Re: Alpha of 2.3.6 next week
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
And with a few addt'l patches, it builds clean (excluding some recent
ldap oddities coming from MS's toolchain), thanks for taking a good
look into this Mario.
On 6/8/2010 3:25 PM, Mario Brandt wrote:
> Thanks Stefan,
> it builds fine.
>
> Mario
>
> On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch <sf...@sfritsch.de> wrote:
>> This should be fixed now and I hopefully have also addressed Bill's
>> concern about r952724. I don't see any blocker for an alpha-release
>> anymore.
>>
>
Re: Alpha of 2.3.6 next week
Posted by Mario Brandt <jb...@gmail.com>.
Thanks Stefan,
it builds fine.
Mario
On Tue, Jun 8, 2010 at 21:51, Stefan Fritsch <sf...@sfritsch.de> wrote:
> This should be fixed now and I hopefully have also addressed Bill's
> concern about r952724. I don't see any blocker for an alpha-release
> anymore.
>
Re: Alpha of 2.3.6 next week
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tuesday 08 June 2010, Stefan Fritsch wrote:
> On Tue, 8 Jun 2010, Jim Jagielski wrote:
> > OK sounds like we're good for a 2.3.6-alpha... I'll likely
> > do either later on today or else Thursday (traveling on Weds).
>
> There is still the Windows build failure reported by Gregg L.
> Smith. Does anybody with a Windows build environment have time to
> look at it?
This should be fixed now and I hopefully have also addressed Bill's
concern about r952724. I don't see any blocker for an alpha-release
anymore.
Re: Alpha of 2.3.6 next week
Posted by Mario Brandt <jb...@gmail.com>.
I still get that error on Windows compiling from trunk.
Mario
On Tue, Jun 8, 2010 at 16:05, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Tue, 8 Jun 2010, Jim Jagielski wrote:
>
>> OK sounds like we're good for a 2.3.6-alpha... I'll likely
>> do either later on today or else Thursday (traveling on Weds).
>
> There is still the Windows build failure reported by Gregg L. Smith. Does
> anybody with a Windows build environment have time to look at it?
>
Re: Alpha of 2.3.6 next week
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Tue, 8 Jun 2010, Jim Jagielski wrote:
> OK sounds like we're good for a 2.3.6-alpha... I'll likely
> do either later on today or else Thursday (traveling on Weds).
There is still the Windows build failure reported by Gregg L. Smith.
Does anybody with a Windows build environment have time to look at it?
Re: Alpha of 2.3.6 next week
Posted by Jim Jagielski <ji...@jaguNET.com>.
OK sounds like we're good for a 2.3.6-alpha... I'll likely
do either later on today or else Thursday (traveling on Weds).
On Jun 7, 2010, at 4:21 PM, Rainer Jung wrote:
> On 02.06.2010 17:55, Jim Jagielski wrote:
>> I'm planning on releasing an alpha of 2.3.6 next week in
>> hopes that we can push out a beta v. soon after.
>
> I think my changes concerning building shared modules by default and adding items to the error log format are complete. And I guess Stefans log configuration patches are also ready for 2.3.6.
>
> I've got two things on my Todo list, adding sub second timestamps to the access log (patch proposal forthcoming soon) and improving the graceful process shutdown. No need to wait for that with 2.3.6.
>
> Rainer
>
Re: Alpha of 2.3.6 next week
Posted by Rainer Jung <ra...@kippdata.de>.
On 02.06.2010 17:55, Jim Jagielski wrote:
> I'm planning on releasing an alpha of 2.3.6 next week in
> hopes that we can push out a beta v. soon after.
I think my changes concerning building shared modules by default and
adding items to the error log format are complete. And I guess Stefans
log configuration patches are also ready for 2.3.6.
I've got two things on my Todo list, adding sub second timestamps to the
access log (patch proposal forthcoming soon) and improving the graceful
process shutdown. No need to wait for that with 2.3.6.
Rainer
Re: 2.3.6-alpha
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/11/2010 7:29 AM, Jim Jagielski wrote:
> I have tagged and rolled 2.3.6 alpha tballs and committed them
> to the dist.apache.org/repos/dist/dev/httpd repo.
Thanks! I don't see a reason to hold off the vote, since all committers
can check out that repository directly (it svn up'ed fine here, as I was
preparing for some unrelated site updates).
> As soon as they show up, I will start the release vote.
You'll be waiting a very long time, since this is all dependent on the
svnpubsub service. That update is either instantaneous, or never. It is
suggested you avoid email and file a jira ticket, to avoid pissing off Joe.
2.3.6-alpha
Posted by Jim Jagielski <ji...@jaguNET.com>.
I have tagged and rolled 2.3.6 alpha tballs and committed them
to the dist.apache.org/repos/dist/dev/httpd repo.
As soon as they show up, I will start the release vote.
Alpha of 2.3.6 next week
Posted by Jim Jagielski <ji...@jaguNET.com>.
I'm planning on releasing an alpha of 2.3.6 next week in
hopes that we can push out a beta v. soon after.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 1, 2010, at 4:49 PM, Paul Querna wrote:
> On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
>> Considering that 2.3/trunk is back to limbo-land, I'd like
>> to propose that we be more "aggressive" is backporting some
>> items. Even if under experimental, it would be nice if slotmem
>> and socache were backported. I also like the refactoring of
>> the providers for proxy in trunk as compared to 2.2, but
>> last time I suggested it, it looked like 2.3/2.4 was close(r)
>> to reality...
>>
>> comments...?
>
> 2.2 came out 5.5 years ago. I strongly support shipping 2.4.
>
> i've not had time to try to ship more alpha/betas. Does anyone else
> have time to head up RMing it?
>
I'll start RMing 2.4 in hopes of getting this puppy out
the door...
Re: What's next for 2.2 and 2.3/trunk?
Posted by Paul Querna <pa...@querna.org>.
On Tue, Jun 1, 2010 at 9:08 AM, Jim Jagielski <ji...@apache.org> wrote:
> Considering that 2.3/trunk is back to limbo-land, I'd like
> to propose that we be more "aggressive" is backporting some
> items. Even if under experimental, it would be nice if slotmem
> and socache were backported. I also like the refactoring of
> the providers for proxy in trunk as compared to 2.2, but
> last time I suggested it, it looked like 2.3/2.4 was close(r)
> to reality...
>
> comments...?
2.2 came out 5.5 years ago. I strongly support shipping 2.4.
i've not had time to try to ship more alpha/betas. Does anyone else
have time to head up RMing it?
Its easy once you get it down, 2 commits, one run of of the release
shell script, and 3 emails.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Graham Dumpleton <gr...@gmail.com>.
On 3 June 2010 10:40, Sander Temme <sc...@apache.org> wrote:
>
> On Jun 1, 2010, at 9:08 AM, Jim Jagielski wrote:
>
>> Considering that 2.3/trunk is back to limbo-land, I'd like
>> to propose that we be more "aggressive" is backporting some
>> items. Even if under experimental, it would be nice if slotmem
>> and socache were backported. I also like the refactoring of
>> the providers for proxy in trunk as compared to 2.2, but
>> last time I suggested it, it looked like 2.3/2.4 was close(r)
>> to reality...
>>
>> comments...?
>
> Amusingly (at least to me), I happened upon an old post by Joel Spolsky from 2002:
>
> http://www.joelonsoftware.com/articles/PickingShipDate.html
>
> "For Systems With Millions of Customers and Millions of Integration Points, Prefer Rare Releases. You can do it like Apache: one release at the beginning of the Internet Bubble, and one release at the end. Perfect."
>
> I personally think we have enough to release for users to chew on:
>
> http://httpd.apache.org/docs/trunk/new_features_2_4.html
>
> PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
By you mentioning WSGI, are you asking whether mod_wsgi works against 2.3 trunk?
If you are, the answer is that mod_wsgi trunk should work. Ie.,
unreleased version.
Official tar ball releases of mod_wsgi will not work because of
changes a while back in 2.3 to eliminate ap_accept_lock_mech from
public API.
If 2.3 is going to start progressing again before mod_wsgi 4.0 is
released, I can always backport workaround for that to mod_wsgi 3.X
branch.
FWIW, although I haven't tried it, I suspect that even mod_python
trunk will not build against Apache 2.3 as it makes use of ap_requires
which vanished in 2.3.
Graham
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jeff Trawick <tr...@gmail.com>.
On Fri, Jun 4, 2010 at 10:35 AM, Graham Leggett <mi...@sharp.fm> wrote:
> On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
>
> +1 for the continued, and perhaps more widespread, voluntary soliciting of
>> approval in advance for changes which add new modules or other significant
>> new function, or make other widespread changes, or change prerequisites in a
>> meaningful way, or have been discussed in the past without resolution (or
>> with outright rejection), etc., etc. (We don't need an explicit laundry
>> list, or any additional policy, to codify the practical matter that multiple
>> developers need to be ready and willing to cope with such changes when they
>> reach the user base).
>>
>> This has been done countless times by numerous people in this successful
>> decade, in spite of, and even for the continued viability of, the C-T-R
>> policy.
>>
>
> This creates an artificial "two tier" hierarchy of committers, those who
> regularly "approve" changes, and those who don't.
>
Some people have more time and energy to read through more proposals and
give their 2 cents one way or another. The important point isn't "approve"
but "review and comment." Also, this is self-selecting so I don't see the
issue of merit.
A new person arriving here is certainly not going to feel confident enough
> to step in and "approve" a change. What they'll see is a small group of
> people "approving" changes made by a larger group of people, and they'll
> naturally fall into the second "tier".
>
> The ASF is a meritocracy, and someone attains committership by proving
> their merit to the point where they are invited to become committers:
>
> http://www.apache.org/foundation/how-it-works.html#meritocracy
>
> Where this has started to become a problem is when committers in the "first
> tier" feel their "seniority" is enough basis for an objection to a code
> contribution.
sounds like a PMC issue to me
> All committers are equal, and no matter how long a committer has been
> around, they have to provide a justification for their objection to a piece
> of code just as thoroughly thought out as the original committer is expected
> to be thorough with their original contribution.
>
Equality is not the issue. I think I can describe the same conflict you are
referring to in these very different terms:
* some members of the community ask for feedback from their peers before
making "big" changes; I think this implies that these members of the
community are not interested in making the change unless there is reasonable
agreement that it is a good thing to do, independent of any specific
technical detail
* some members of the community make "big" changes without looking first for
the group sense of whether the change is generally accepted to be a good
thing; I think this implies that these members of the community feel that
their change should be in the server unless there is a specific reason to
veto it
This is not a black and white issue;"big" is in the eyes of the beholder,
and there's no fixed membership in the two camps. These are just two
philosophically different approaches related to the conflict you are
discussing, and I think individual developers remain mostly in the same camp
over time.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 05 June 2010, Roy T. Fielding wrote:
> On Jun 4, 2010, at 1:23 PM, Graham Leggett wrote:
> > "CTR is fine for all normal fixes. RTC is always preferred for
> > major code refactorings."
> >
> > I ask you this: What constitutes "a modest new feature"? It's not
> > a fix. It's not a major code refactoring. But modest new
> > features have been strongly objected to by a small group of
> > people on this list who insisted it was a clear cut case of
> > "should have reviewed first", on a branch that is CTR.
> >
> > I have absolutely no objection whatsoever to the need for review
> > of a major code refactoring. I have absolutely no objection
> > whatsoever to those who express the opinion that a piece of
> > committed code is inappropriate or unnecessary. But we've
> > reached the point where people want anything that isn't any more
> > than a fix to be reviewed first *before* commit as a matter of
> > procedure, and this wooly grey area cannot continue.
>
> Please see
>
> http://httpd.apache.org/dev/guidelines.html
>
> under the heading "When to Commit a Change".
>
> Ideas must be review-then-commit; patches can be
> commit-then-review. With a commit-then-review process, we trust
> that the developer doing the commit has a high degree of
> confidence in the change. Doubtful changes, new features, and
> large-scale overhauls need to be discussed before being committed
> to a repository. Any change that affects the semantics of
> arguments to configurable directives, significantly adds to the
> runtime size of the program, or changes the semantics of an
> existing API function must receive consensus approval on the
> mailing list before being committed.
I very much agree with this policy. Usually it works quite well.
But having no one review the contributions from a new (or even a not
so new) contributor can be very demotivating. I think all commiters
should look for such situations and suggest/implement remedies (e.g.
additional branches, as Jim suggested, or by commenting on the ideas
even if one has too little time to review the patches). Also, the
problem is less likely to occur when there are more committers. So,
more committers should be added whenever possible, and with as little
delay as possible.
Cheers,
Stefan
PS: The above page could use a clarification what the "Apache group"
actually is. The commiters or only the PMC?
Re: What's next for 2.2 and 2.3/trunk?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Jun 4, 2010, at 1:23 PM, Graham Leggett wrote:
> "CTR is fine for all normal fixes. RTC is always preferred for major code
> refactorings."
>
> I ask you this: What constitutes "a modest new feature"? It's not a fix. It's not a major code refactoring. But modest new features have been strongly objected to by a small group of people on this list who insisted it was a clear cut case of "should have reviewed first", on a branch that is CTR.
>
> I have absolutely no objection whatsoever to the need for review of a major code refactoring. I have absolutely no objection whatsoever to those who express the opinion that a piece of committed code is inappropriate or unnecessary. But we've reached the point where people want anything that isn't any more than a fix to be reviewed first *before* commit as a matter of procedure, and this wooly grey area cannot continue.
Please see
http://httpd.apache.org/dev/guidelines.html
under the heading "When to Commit a Change".
Ideas must be review-then-commit; patches can be commit-then-review.
With a commit-then-review process, we trust that the developer doing
the commit has a high degree of confidence in the change.
Doubtful changes, new features, and large-scale overhauls need to be
discussed before being committed to a repository. Any change that affects
the semantics of arguments to configurable directives, significantly adds
to the runtime size of the program, or changes the semantics of an
existing API function must receive consensus approval on the mailing
list before being committed.
....Roy
Re: What's next for 2.2 and 2.3/trunk?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Jun 2010, at 6:06 PM, William A. Rowe Jr. wrote:
> All individuals are invited to chime in when a proposal is raised,
> and to
> invest the time in reviewing the proposal. That includes non
> committers.
>
> There are no "tiers", except for contributor, committer, and project
> committee
> member.
>
> There are committers who continue to amass esteem by regular and
> sustained
> review of the code contributions - those CTR, RTC, and even
> committing code
> for the non-committers provided on the dev@ or bugzilla channel.
And in so doing creating the "first tier" and "second tier" that I'm
talking about.
Committers are expected to make regular and sustained review of the
code contributions from day one, in fact the basis by which that
committer was invited to be a committer was *because* they made
regular and sustained code contributions.
There is no "continue to amass esteem".
The reason this is dangerous is because if this is allowed to happen,
we risk someone who has "amassed esteem" to start using "esteem" as
currency instead of a solid technical justification. Just because
someone has been around a long time does not relieve them of the
obligation to solidly justify their position on an issue or their
rejection or acceptance of a piece of code.
> There is no new layer of bureaucracy, nor is it even bureaucracy.
> It's the
> desire of the entire project to see big ideas, or big refactorings,
> come to
> the list first to be vetted. That has always been there.
No, to quote you:
"CTR is fine for all normal fixes. RTC is always preferred for major
code
refactorings."
I ask you this: What constitutes "a modest new feature"? It's not a
fix. It's not a major code refactoring. But modest new features have
been strongly objected to by a small group of people on this list who
insisted it was a clear cut case of "should have reviewed first", on a
branch that is CTR.
I have absolutely no objection whatsoever to the need for review of a
major code refactoring. I have absolutely no objection whatsoever to
those who express the opinion that a piece of committed code is
inappropriate or unnecessary. But we've reached the point where people
want anything that isn't any more than a fix to be reviewed first
*before* commit as a matter of procedure, and this wooly grey area
cannot continue.
> Graham, I'm a little bit concerned you aren't reading what a number
> of the
> experienced committers are saying to you. Please take the time to
> reread
> these posts, perhaps they will be clearer on a second or third
> reading.
And here again, you attempt to create the "two tier" hierarchy by
referring to "experienced committers", as if they are a group apart
from "committers".
Wearing my hat as a long standing member of the foundation - which
gives me no special status on this or any other ASF project, but does
reflect my continued concern about the foundation and how it is run -
I am really concerned that this very non-ASF set of practices are
being perpetuated within the project that is supposed to be the model
for how an ASF project is run. And given the recent threads on various
ASF lists on this topic, I am not alone in my concern.
Please take time to read this, in detail:
http://www.apache.org/foundation/how-it-works.html
Particularly, this:
"Within the ASF we worry about any community which centers around a
few individuals who are working virtually uncontested. We believe that
this is detrimental to quality, stability, and robustness of both code
and long term social structures."
I believe the "amassed esteem" or "experienced committer" you have
referred to above fits squarely on the definition of "centers around a
few individuals who are working virtually uncontested", and I am
concerned that people might believe their "experienced committer"
status somehow gives them more authority than another committer. It
does not.
>>> CTR is fine for all normal fixes.
>>
>> No, it has been the policy of the project for many years that CTR is
>> fine on trunk for *all* contributions.
>
> *All* contributions have never been welcome. Those that fit within
> what
> the PMC collectively believes httpd should contain are always welcome.
This isn't how the ASF works.
The PMC does not dictate to end users what they want or what code
should be accepted. Any objection by any PMC member needs to be backed
up with a solid technical justification, just like any committer is
required to.
Or to quote from http://www.apache.org/foundation/how-it-works.html:
"The role of the PMC from a Foundation perspective is oversight. The
main role of the PMC is not code and not coding - but to ensure that
all legal issues are addressed, that procedure is followed, and that
each and every release is the product of the community as a whole.
That is key to our litigation protection mechanisms."
The key words are "not code and not coding". The only reason a PMC
might reject code is if the code did not address the legal
requirements (licensing, etc), or did not follow procedure. If a PMC
member wanted to reject code for a reason other than these, they would
reject the code wearing their committer hat, and what that means is
that they would be bound by the same requirements for providing
justification that binds any committer.
To sum up, this is a group of peers, and the group only works when we
respect each other's contributions and views on an equal basis.
Regards,
Graham
--
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/4/2010 9:35 AM, Graham Leggett wrote:
> On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
>
>>
>> This has been done countless times by numerous people in this
>> successful decade, in spite of, and even for the continued viability
>> of, the C-T-R policy.
>
> This creates an artificial "two tier" hierarchy of committers, those who
> regularly "approve" changes, and those who don't.
All individuals are invited to chime in when a proposal is raised, and to
invest the time in reviewing the proposal. That includes non committers.
There are no "tiers", except for contributor, committer, and project committee
member.
There are committers who continue to amass esteem by regular and sustained
review of the code contributions - those CTR, RTC, and even committing code
for the non-committers provided on the dev@ or bugzilla channel.
There is no new layer of bureaucracy, nor is it even bureaucracy. It's the
desire of the entire project to see big ideas, or big refactorings, come to
the list first to be vetted. That has always been there.
Graham, I'm a little bit concerned you aren't reading what a number of the
experienced committers are saying to you. Please take the time to reread
these posts, perhaps they will be clearer on a second or third reading.
On 6/4/2010 9:19 AM, Graham Leggett wrote:
> On 04 Jun 2010, at 2:55 AM, William A. Rowe Jr. wrote:
>
>> CTR is fine for all normal fixes.
>
> No, it has been the policy of the project for many years that CTR is
> fine on trunk for *all* contributions.
*All* contributions have never been welcome. Those that fit within what
the PMC collectively believes httpd should contain are always welcome.
What the dev list is for is to help filter this collective consensus.
This is always preferable to what can degrade into a commit battle.
And many contributions were offered first to dev@ because of their scope.
Often accepted, sometimes rejected. Occasionally, ejected after acceptance.
At some points when I was actively teaching or doing repair projects or the
computer lab, I had the keys to my church. There was no church.org/dev/
site with access policies, no do's and dont's. People with keys were just
trusted to use them responsibly.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Jun 2010, at 2:51 AM, Jeff Trawick wrote:
> +1 for the continued, and perhaps more widespread, voluntary
> soliciting of approval in advance for changes which add new modules
> or other significant new function, or make other widespread changes,
> or change prerequisites in a meaningful way, or have been discussed
> in the past without resolution (or with outright rejection), etc.,
> etc. (We don't need an explicit laundry list, or any additional
> policy, to codify the practical matter that multiple developers need
> to be ready and willing to cope with such changes when they reach
> the user base).
>
> This has been done countless times by numerous people in this
> successful decade, in spite of, and even for the continued viability
> of, the C-T-R policy.
This creates an artificial "two tier" hierarchy of committers, those
who regularly "approve" changes, and those who don't.
A new person arriving here is certainly not going to feel confident
enough to step in and "approve" a change. What they'll see is a small
group of people "approving" changes made by a larger group of people,
and they'll naturally fall into the second "tier".
The ASF is a meritocracy, and someone attains committership by proving
their merit to the point where they are invited to become committers:
http://www.apache.org/foundation/how-it-works.html#meritocracy
Where this has started to become a problem is when committers in the
"first tier" feel their "seniority" is enough basis for an objection
to a code contribution. All committers are equal, and no matter how
long a committer has been around, they have to provide a justification
for their objection to a piece of code just as thoroughly thought out
as the original committer is expected to be thorough with their
original contribution.
Regards,
Graham
--
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jeff Trawick <tr...@gmail.com>.
On Thu, Jun 3, 2010 at 7:51 PM, Graham Leggett <mi...@sharp.fm> wrote:
> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
>
> It would be, but it's necessary. The ASF is a collaborative environment;
>> unreviewed code should not released, even when the authors are committers.
>> A major patch like this hitting svn, without previous review, makes our
>> fellow committers' eyes glaze over.
>>
>> If there is not positive feedback from two reviewers, this code does not
>> belong in trunk/. As a committer, you are *free* to create your own
>> sandboxes in svn to demonstrate code changes, if that helps attract the
>> necessary review.
>>
>
> What you're describing here is review-then-commit (RTC).
>
> If we want trunk to be review-then-commit then we must make a decision and
> make it review-then-commit. If trunk is to remain commit-then-review (CTR),
> then people must be free to commit, then have people review.
>
> We cannot continue with this weird "limbo" situation where trunk is
> officially CTR, but unofficially RTC, because you have to check first on the
> list before committing anything, and you're too scared to commit anything
> because you're scared you're going to offend somebody who believes they
> should have been consulted first before someone commits to a CTR branch.
>
> The reason CTR is ideal for trunk is because the consequences of the rest
> of the project being too busy to review the code, is that the code is
> accepted without dispute. This produces a clear incentive to make sure that
> the rest of the project reviews code. It's really easy for the rest of the
> project to go "I don't care about feature X, so I'll ignore reviewing that
> proposed code, I'm too busy". Under RTC, progress slows, people get fed up
> waiting for other people to review, progress stops, project dies.
>
> Having said that, RTC is entirely appropriate for the stable branch. Here
> the point is stability - we don't want progress, unless the progress is
> justified through the agreement of at least 3 other people. Progress slows,
> but progress doesn't stop, because the person writing the code can always
> wait until trunk becomes the next stable version.
>
> We've been doing this like this for over a decade, and it has worked really
> well. If you want the policy to be changed, argue that the policy should be
> changed. But do not try and apply a pseudo-policy on top of the already
> established ASF practice of CTR, it's not fair to our contributors.
>
+1 for the continued, and perhaps more widespread, voluntary soliciting of
approval in advance for changes which add new modules or other significant
new function, or make other widespread changes, or change prerequisites in a
meaningful way, or have been discussed in the past without resolution (or
with outright rejection), etc., etc. (We don't need an explicit laundry
list, or any additional policy, to codify the practical matter that multiple
developers need to be ready and willing to cope with such changes when they
reach the user base).
This has been done countless times by numerous people in this successful
decade, in spite of, and even for the continued viability of, the C-T-R
policy.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 4, 2010, at 1:58 AM, Ruediger Pluem wrote:
> On 04.06.2010 01:51, Graham Leggett wrote:
>> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
>>
>>> It would be, but it's necessary. The ASF is a collaborative environment;
>>> unreviewed code should not released, even when the authors are
>>> committers.
>>> A major patch like this hitting svn, without previous review, makes our
>>> fellow committers' eyes glaze over.
>>>
>>> If there is not positive feedback from two reviewers, this code does not
>>> belong in trunk/. As a committer, you are *free* to create your own
>>> sandboxes in svn to demonstrate code changes, if that helps attract the
>>> necessary review.
>>
>> What you're describing here is review-then-commit (RTC).
>
> No. It was always the case that larger and more intrusive changes should be
> discussed on dev@ before folding it into trunk either by posting them or by
> creating a developer branch.
> This makes perfect sense to me as we are doing a collaborative effort in
> creating the code and it shows that there is enough support for these
> kind of changes. It helps avoiding a large back and forth in the trunk
> and -1 votes on commits.
> I don't think that we need any kind of written policy for this as I trust
> the developers here to do it if it is needed.
In reality, this issue exists because we are using trunk currently
as the "code sandbox", which should be CTR as well as the
direct descendent for 2.4 and, as such, should be treated more
gingerly and thus RTC.
We could easily resolve this by creating another branch... either
copying trunk to httpd-2.3 and keeping trunk as CTR and having
2.3 as RTC (ala 2.2), with the expectation that 2.3 becomes 2.4,
or else some sort of sandbox branch off of trunk for more
"intrusive" changes...
Personally, I think branching a 2.3 would result in a faster
push towards 2.4.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Ruediger Pluem <rp...@apache.org>.
On 04.06.2010 01:51, Graham Leggett wrote:
> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
>
>> It would be, but it's necessary. The ASF is a collaborative environment;
>> unreviewed code should not released, even when the authors are
>> committers.
>> A major patch like this hitting svn, without previous review, makes our
>> fellow committers' eyes glaze over.
>>
>> If there is not positive feedback from two reviewers, this code does not
>> belong in trunk/. As a committer, you are *free* to create your own
>> sandboxes in svn to demonstrate code changes, if that helps attract the
>> necessary review.
>
> What you're describing here is review-then-commit (RTC).
No. It was always the case that larger and more intrusive changes should be
discussed on dev@ before folding it into trunk either by posting them or by
creating a developer branch.
This makes perfect sense to me as we are doing a collaborative effort in
creating the code and it shows that there is enough support for these
kind of changes. It helps avoiding a large back and forth in the trunk
and -1 votes on commits.
I don't think that we need any kind of written policy for this as I trust
the developers here to do it if it is needed.
Regards
Rüdiger
Re: What's next for 2.2 and 2.3/trunk?
Posted by Graham Leggett <mi...@sharp.fm>.
On 04 Jun 2010, at 2:55 AM, William A. Rowe Jr. wrote:
>>> If there is not positive feedback from two reviewers, this code
>>> does not
>>> belong in trunk/. As a committer, you are *free* to create your own
>>> sandboxes in svn to demonstrate code changes, if that helps
>>> attract the
>>> necessary review.
>>
>> What you're describing here is review-then-commit (RTC).
>
> No, I wasn't. What I was suggesting is that code that is missing
> the 'then
> Commit' bits of RTC doesn't belong. It is not reassuring when
> committers
> aren't reviewing the patches offered when they are presented.
> Committing
> them to trunk doesn't reassure me that they'll have sufficient
> review after
> the commit, either.
I get the strong sense that you want to "patch over" problems like
this by adding additional layers of bureaucracy, instead of fixing the
underlying problem - a shortage of active committers.
The ASF trusts committers. Committers are trusted not only to produce
good code, but also to look over the shoulders of other committers and
review code. This you-watch-my-back-and-I-watch-yours constitutes a
very strong level of redundancy in our development process - a problem
introduced is very unlikely to remain undetected, and this is evident
in the excellent stability of our codebase.
This however only works if the level of active committers is kept up.
Naturally over time the level of contribution of committers will
change as priorities change, personal interests change, etc, and this
causes a natural erosion of the active committer level. This needs to
be balanced with the introduction of new committers, before a new new
committer feels their contribution is being ignored and diverts their
energy elsewhere.
Adding the additional bureaucracy as you propose will only make the
problem worse. Instead of it taking a long time for code contributions
to be accepted like now, code will be actively rejected due simply to
disinterest by a too-small group of existing committers, and not
because of the quality of the code.
> CTR is fine for all normal fixes.
No, it has been the policy of the project for many years that CTR is
fine on trunk for *all* contributions.
We have historically added the "if it's big, check first" proviso as a
sanity check to make sure nobody goes off on a big tangent, but lately
this has turned into just "check first", and "check first" means
"review".
> RTC is always preferred for major code
> refactorings. But the reviews need to happen, and this particular
> code has
> been available for discussion at dev@ for months, with very little
> comment
> between very few committers, which isn't a healthy sign.
I 100% agree it is not a healthy sign, but we disagree on the the
sign. I see it as a sign we must step up and propose some new
committers, I don't see it as a sign of a lack of code quality.
Regards,
Graham
--
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/3/2010 6:51 PM, Graham Leggett wrote:
> On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
>
>> It would be, but it's necessary. The ASF is a collaborative environment;
>> unreviewed code should not released, even when the authors are
>> committers.
>> A major patch like this hitting svn, without previous review, makes our
>> fellow committers' eyes glaze over.
>>
>> If there is not positive feedback from two reviewers, this code does not
>> belong in trunk/. As a committer, you are *free* to create your own
>> sandboxes in svn to demonstrate code changes, if that helps attract the
>> necessary review.
>
> What you're describing here is review-then-commit (RTC).
No, I wasn't. What I was suggesting is that code that is missing the 'then
Commit' bits of RTC doesn't belong. It is not reassuring when committers
aren't reviewing the patches offered when they are presented. Committing
them to trunk doesn't reassure me that they'll have sufficient review after
the commit, either.
CTR is fine for all normal fixes. RTC is always preferred for major code
refactorings. But the reviews need to happen, and this particular code has
been available for discussion at dev@ for months, with very little comment
between very few committers, which isn't a healthy sign.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 Jun 2010, at 10:17 PM, William A. Rowe Jr. wrote:
> It would be, but it's necessary. The ASF is a collaborative
> environment;
> unreviewed code should not released, even when the authors are
> committers.
> A major patch like this hitting svn, without previous review, makes
> our
> fellow committers' eyes glaze over.
>
> If there is not positive feedback from two reviewers, this code does
> not
> belong in trunk/. As a committer, you are *free* to create your own
> sandboxes in svn to demonstrate code changes, if that helps attract
> the
> necessary review.
What you're describing here is review-then-commit (RTC).
If we want trunk to be review-then-commit then we must make a decision
and make it review-then-commit. If trunk is to remain commit-then-
review (CTR), then people must be free to commit, then have people
review.
We cannot continue with this weird "limbo" situation where trunk is
officially CTR, but unofficially RTC, because you have to check first
on the list before committing anything, and you're too scared to
commit anything because you're scared you're going to offend somebody
who believes they should have been consulted first before someone
commits to a CTR branch.
The reason CTR is ideal for trunk is because the consequences of the
rest of the project being too busy to review the code, is that the
code is accepted without dispute. This produces a clear incentive to
make sure that the rest of the project reviews code. It's really easy
for the rest of the project to go "I don't care about feature X, so
I'll ignore reviewing that proposed code, I'm too busy". Under RTC,
progress slows, people get fed up waiting for other people to review,
progress stops, project dies.
Having said that, RTC is entirely appropriate for the stable branch.
Here the point is stability - we don't want progress, unless the
progress is justified through the agreement of at least 3 other
people. Progress slows, but progress doesn't stop, because the person
writing the code can always wait until trunk becomes the next stable
version.
We've been doing this like this for over a decade, and it has worked
really well. If you want the policy to be changed, argue that the
policy should be changed. But do not try and apply a pseudo-policy on
top of the already established ASF practice of CTR, it's not fair to
our contributors.
Regards,
Graham
--
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/3/2010 12:59 PM, Stefan Fritsch wrote:
> On Thursday 03 June 2010, William A. Rowe Jr. wrote:
>> On 6/3/2010 11:58 AM, Stefan Fritsch wrote:
>>> I definitely want to have the per-module/per-dir loglevel config
>>> in 2.4. I think it's working well enough to be commited to
>>> trunk. We can work out the remaining issues there. Unless
>>> somebody disagrees, I am going to commit.
>>
>> I'm still uncomfortable with the new manditory per-every-source
>> file macros.
>
> Please look at my mail from 1 hour ago. With the latest change, the
> macros are no longer mandatory. Not using them will just lead to
> the default (i.e. not per-module) loglevel being used for that file.
Thanks! I'll review, this certainly sounds like it influences my own
opinion.
>> Not enough to vote against (more like -.05), if you
>> are willing to find two more to +1 the proposed patch as it
>> stands.
>>
>> Because it is VERY intrusive, commit-before review is
>> inappropriate.
>
> On the one hand, I understand that. On the other hand, there seem to
> be very few people who have enough time to review the patch. It would
> be a pity if it was not included in 2.4 just for this reason.
It would be, but it's necessary. The ASF is a collaborative environment;
unreviewed code should not released, even when the authors are committers.
A major patch like this hitting svn, without previous review, makes our
fellow committers' eyes glaze over.
If there is not positive feedback from two reviewers, this code does not
belong in trunk/. As a committer, you are *free* to create your own
sandboxes in svn to demonstrate code changes, if that helps attract the
necessary review.
> How were such large changes handled in the past, like the AAA
> refactoring from 2.2 to 2.3?
Not well [with respect to AAA, or LDAP specifically] - this is one of
the concerns about 2.3 and the need for an extended review period, in
spite of how many terrific changes sit on trunk.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 03 June 2010, William A. Rowe Jr. wrote:
> On 6/3/2010 11:58 AM, Stefan Fritsch wrote:
> > I definitely want to have the per-module/per-dir loglevel config
> > in 2.4. I think it's working well enough to be commited to
> > trunk. We can work out the remaining issues there. Unless
> > somebody disagrees, I am going to commit.
>
> I'm still uncomfortable with the new manditory per-every-source
> file macros.
Please look at my mail from 1 hour ago. With the latest change, the
macros are no longer mandatory. Not using them will just lead to
the default (i.e. not per-module) loglevel being used for that file.
> Not enough to vote against (more like -.05), if you
> are willing to find two more to +1 the proposed patch as it
> stands.
>
> Because it is VERY intrusive, commit-before review is
> inappropriate.
On the one hand, I understand that. On the other hand, there seem to
be very few people who have enough time to review the patch. It would
be a pity if it was not included in 2.4 just for this reason. And
quite a few people who I have spoken with at Wicklow have expressed
interest in the functionality.
How were such large changes handled in the past, like the AAA
refactoring from 2.2 to 2.3?
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/3/2010 11:58 AM, Stefan Fritsch wrote:
>
> I definitely want to have the per-module/per-dir loglevel config in
> 2.4. I think it's working well enough to be commited to trunk. We can
> work out the remaining issues there. Unless somebody disagrees, I am
> going to commit.
I'm still uncomfortable with the new manditory per-every-source file
macros. Not enough to vote against (more like -.05), if you are willing
to find two more to +1 the proposed patch as it stands.
Because it is VERY intrusive, commit-before review is inappropriate.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 3, 2010, at 12:58 PM, Stefan Fritsch wrote:
> On Thursday 03 June 2010, Sander Temme wrote:
>> On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
>>>> PHP should largely move to FastCGI, so module compatibility
>>>> should not be a problem. Any idea about other popular modules?
>>>> WSGI? mod_perl? Are they ready for HEAD?
>>>
>>> That's a good question, but until we get a version of httpd
>>> 2.3/2.4/trunk out in people's hands with some confidence that
>>> "what you are testing is pretty close to what it will be,
>>> API-wise", we'll never know. If I was just a module developer, I
>>> wouldn't be wasting my time following trunk either, due to our
>>> track record ;)
>>
>> Are we ready to freeze the API? I think that's our Alpha -> Beta
>> transition point.
>
> I definitely want to have the per-module/per-dir loglevel config in
> 2.4. I think it's working well enough to be commited to trunk. We can
> work out the remaining issues there. Unless somebody disagrees, I am
> going to commit.
>
+1!
Re: What's next for 2.2 and 2.3/trunk?
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Thursday 03 June 2010, Sander Temme wrote:
> On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
> >> PHP should largely move to FastCGI, so module compatibility
> >> should not be a problem. Any idea about other popular modules?
> >> WSGI? mod_perl? Are they ready for HEAD?
> >
> > That's a good question, but until we get a version of httpd
> > 2.3/2.4/trunk out in people's hands with some confidence that
> > "what you are testing is pretty close to what it will be,
> > API-wise", we'll never know. If I was just a module developer, I
> > wouldn't be wasting my time following trunk either, due to our
> > track record ;)
>
> Are we ready to freeze the API? I think that's our Alpha -> Beta
> transition point.
I definitely want to have the per-module/per-dir loglevel config in
2.4. I think it's working well enough to be commited to trunk. We can
work out the remaining issues there. Unless somebody disagrees, I am
going to commit.
Cheers,
Stefan
Re: What's next for 2.2 and 2.3/trunk?
Posted by Sander Temme <sc...@apache.org>.
On Jun 3, 2010, at 8:45 AM, William A. Rowe Jr. wrote:
> On 6/3/2010 9:59 AM, Sander Temme wrote:
>>
>> On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
>>
>>>> PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
>>>>
>>>
>>> That's a good question, but until we get a version of httpd 2.3/2.4/trunk
>>> out in people's hands with some confidence that "what you are testing
>>> is pretty close to what it will be, API-wise", we'll never know.
>>> If I was just a module developer, I wouldn't be wasting my time
>>> following trunk either, due to our track record ;)
>>
>> Are we ready to freeze the API? I think that's our Alpha -> Beta transition point.
>
> Freeze? Our versioning policy is and has been, n.odd == unstable, n.even == stable.
Yep, and now we're working on bringing 2.3/trunk towards 2.4/stable.
> Beta could have some extra encouragement to avoid changing the API. Perhaps
> chilled over ice?
Code Slush, that's where it's at.
> Extra assurances things are 'finished'?
>
> But users will probably react more strongly to '-beta' than they do to '-alpha',
> and will be more likely to participate if their favorite new feature didn't
> also become part of 2.2.
As Jim pointed out, third party module developers are unlikely to waste cycles until we indicate that we won't pull the rug out from under them API-wise.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/3/2010 9:59 AM, Sander Temme wrote:
>
> On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
>
>>> PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
>>>
>>
>> That's a good question, but until we get a version of httpd 2.3/2.4/trunk
>> out in people's hands with some confidence that "what you are testing
>> is pretty close to what it will be, API-wise", we'll never know.
>> If I was just a module developer, I wouldn't be wasting my time
>> following trunk either, due to our track record ;)
>
> Are we ready to freeze the API? I think that's our Alpha -> Beta transition point.
Freeze? Our versioning policy is and has been, n.odd == unstable, n.even == stable.
Beta could have some extra encouragement to avoid changing the API. Perhaps
chilled over ice?
Extra assurances things are 'finished'?
But users will probably react more strongly to '-beta' than they do to '-alpha',
and will be more likely to participate if their favorite new feature didn't
also become part of 2.2.
Re: What's next for 2.2 and 2.3/trunk?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 6/3/2010 10:13 AM, Nick Kew wrote:
>
> On 3 Jun 2010, at 15:59, Sander Temme wrote:
>
>> Are we ready to freeze the API? I think that's our Alpha -> Beta transition point.
>
> How about a chart or something documenting API differences since 2.2?
> That would seem a useful input to answering your question.
+1 - and we need to worry about the user perspective, too, if we want folks
to be looking at alphas and betas.
> If noone has such a beast sitting around, I can have a stab at something.
There is this so far, which needs much love;
http://httpd.apache.org/docs/trunk/upgrading.html
http://httpd.apache.org/docs/trunk/new_features_2_4.html
If nobody has interest in documenting the structural changes to the auth
suite, with respect to nesting and block evaluation, I suggest we start
to back out that code. It has complicated this release for years.
Re: What's next for 2.2 and 2.3/trunk?
Posted by Nick Kew <ni...@webthing.com>.
On 3 Jun 2010, at 15:59, Sander Temme wrote:
> Are we ready to freeze the API? I think that's our Alpha -> Beta transition point.
How about a chart or something documenting API differences since 2.2?
That would seem a useful input to answering your question.
If noone has such a beast sitting around, I can have a stab at something.
--
Nick Kew
Re: What's next for 2.2 and 2.3/trunk?
Posted by Sander Temme <sc...@apache.org>.
On Jun 3, 2010, at 7:15 AM, Jim Jagielski wrote:
>> PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
>>
>
> That's a good question, but until we get a version of httpd 2.3/2.4/trunk
> out in people's hands with some confidence that "what you are testing
> is pretty close to what it will be, API-wise", we'll never know.
> If I was just a module developer, I wouldn't be wasting my time
> following trunk either, due to our track record ;)
Are we ready to freeze the API? I think that's our Alpha -> Beta transition point.
S.
--
Sander Temme
sctemme@apache.org
PGP FP: FC5A 6FC6 2E25 2DFD 8007 EE23 9BB8 63B0 F51B B88A
Re: What's next for 2.2 and 2.3/trunk?
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Jun 2, 2010, at 8:40 PM, Sander Temme wrote:
>
> On Jun 1, 2010, at 9:08 AM, Jim Jagielski wrote:
>
>> Considering that 2.3/trunk is back to limbo-land, I'd like
>> to propose that we be more "aggressive" is backporting some
>> items. Even if under experimental, it would be nice if slotmem
>> and socache were backported. I also like the refactoring of
>> the providers for proxy in trunk as compared to 2.2, but
>> last time I suggested it, it looked like 2.3/2.4 was close(r)
>> to reality...
>>
>> comments...?
>
> Amusingly (at least to me), I happened upon an old post by Joel Spolsky from 2002:
>
> http://www.joelonsoftware.com/articles/PickingShipDate.html
>
> "For Systems With Millions of Customers and Millions of Integration Points, Prefer Rare Releases. You can do it like Apache: one release at the beginning of the Internet Bubble, and one release at the end. Perfect."
>
> I personally think we have enough to release for users to chew on:
>
> http://httpd.apache.org/docs/trunk/new_features_2_4.html
>
> PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
>
That's a good question, but until we get a version of httpd 2.3/2.4/trunk
out in people's hands with some confidence that "what you are testing
is pretty close to what it will be, API-wise", we'll never know.
If I was just a module developer, I wouldn't be wasting my time
following trunk either, due to our track record ;)
Re: What's next for 2.2 and 2.3/trunk?
Posted by Sander Temme <sc...@apache.org>.
On Jun 1, 2010, at 9:08 AM, Jim Jagielski wrote:
> Considering that 2.3/trunk is back to limbo-land, I'd like
> to propose that we be more "aggressive" is backporting some
> items. Even if under experimental, it would be nice if slotmem
> and socache were backported. I also like the refactoring of
> the providers for proxy in trunk as compared to 2.2, but
> last time I suggested it, it looked like 2.3/2.4 was close(r)
> to reality...
>
> comments...?
Amusingly (at least to me), I happened upon an old post by Joel Spolsky from 2002:
http://www.joelonsoftware.com/articles/PickingShipDate.html
"For Systems With Millions of Customers and Millions of Integration Points, Prefer Rare Releases. You can do it like Apache: one release at the beginning of the Internet Bubble, and one release at the end. Perfect."
I personally think we have enough to release for users to chew on:
http://httpd.apache.org/docs/trunk/new_features_2_4.html
PHP should largely move to FastCGI, so module compatibility should not be a problem. Any idea about other popular modules? WSGI? mod_perl? Are they ready for HEAD?
S.
--
Sander Temme
sctemme@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF