Re: What's next for 2.2 and 2.3/trunk?
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?
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?
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 mi
Re: What's next for 2.2 and 2.3/trunk?
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?
On Fri, Jun 4, 2010 at 10:35 AM, Graham Leggett 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?
On 2010-06-03 at 22:28, "William A. Rowe Jr." 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?
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?
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?
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?
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?
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?
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?
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?
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?
On Thu, Jun 3, 2010 at 7: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). > > 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?
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?
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?
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?
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?
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?
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 scte...@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?
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?
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?
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 scte...@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?
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?
On 3 June 2010 10:40, 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? 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?
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 scte...@apache.org PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
Re: What's next for 2.2 and 2.3/trunk?
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 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?
On Jun 1, 2010, at 4:49 PM, Paul Querna wrote: > On Tue, 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...? > > 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?
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 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?
On Tue, 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...? 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.
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...?