Re: [NOTICE] Subversion conversion
Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I'm shooting for being done with it all by tomorrow night. Sander Did this happen? Bill
Re: [NOTICE] Subversion conversion
On Tue, 2004-11-16 at 07:03, Bill Stoddard wrote: Sander Striker wrote: Hi, I'm finally taking care of the conversion of httpd-* to SVN. I'll follow up with instructions on how to pull new workingcopies, etc etc. I'm looking for volunteers to actually write a page for developers on where to get SVN and how to check out the sources from the SVN repository. I'm shooting for being done with it all by tomorrow night. Sander Did this happen? Some irresponsible partying is delaying the process a bit... Sander
Re: [NOTICE] Subversion conversion
On Tue, 2004-11-16 at 09:34, Sander Striker wrote: On Tue, 2004-11-16 at 07:03, Bill Stoddard wrote: Sander Striker wrote: Did this happen? Some irresponsible partying is delaying the process a bit... To clarify: I was planning on moving forward yesterday after The Incredibles. I got about 80% through. I'll continue after breakfast. Apologies for the holdup. I promise it'll be worth it though. Sander
Branching and release scheduling
We had a good discussion over lunch today on our release processes and how to have stable releases while making new feature development as fun and easy for the geeks as possible. The main branch is always the development branch, with new features added whenever people see fit. There is never a feature freeze or even development slowdown on this branch. There should be regular releases based on this, roughly every couple of weeks, but basically whenever anyone is in the mood to roll a tarball. But there really needs to be a good script for rolling a tarball easily and quickly. These tarballs get full fledged announcements on the website. They get odd-minor-version releases, e.g. 2.1.x while the latest stable branch is at 2.0.x. They are only alphas, with no commitment to ABIs, APIs, or suitability for anything. Whenver there is consensus that it's time to get a release out soon, we make a branch. The branch is in feature freeze for its entire lifetime, The branch is named for the stable release it will eventually be. So for example, we could branch during the 2.1.x, decide that the feature set merits a 2.2 version number, and name the branch 2.2. As long as the releases on that branch are considered unstable, releases are still labelled 2.1.x. Once the release is deemed good enough for general use and the ABI is stable, it gets labelled 2.2.0. Further releases on that branch are naturally labelled 2.2.1, 2.2.2, etc. I think I included all the appropriate details, but the picture is probably clearer. Rich Bowen took it, and I moved it to save his bandwidth: http://www.apache.org/~manoj/dscn2804.jpg
Re: Branching and release scheduling
On Nov 16, 2004, at 3:16 PM, Manoj Kasichainula wrote: We had a good discussion over lunch today on our release processes and how to have stable releases while making new feature development as fun and easy for the geeks as possible. The is a purely personal POV, and I'm wishing I was at the lunch because this addresses something that I've been think and maybe others as well, considering a similar Email thread I see from Brad N, so take the below as my own opinions. I find it somewhat hard to get excited by 2.x development because 2.1 almost seems like a black hole at times... You put the energy into the development but have to wait for it to be folded into an actual version that gets released and used. Now waiting is good, but sometimes it seems that the backports are slow in getting approved. I think most developers like, well, if not *immediate* satisfaction, something more quick than the current develop-2.1-and-wait- for-a-long-time-before-folded-into-2.0. Stability is great, but we should be careful that we don't unduly sacrifice developer energy. This may not be so clear, so feel free to grab me :)
Re: Branching and release scheduling
On Tue, Nov 16, 2004 at 06:16:18PM -0500, Me at IO wrote: I think I included all the appropriate details, but the picture is probably clearer. Rich Bowen took it, and I moved it to save his bandwidth: http://www.apache.org/~manoj/dscn2804.jpg I missed discussing how APR fits in this scheme. The main dev branch would build against reasonably updated HEAD versions of APR. Given group consensus, we could stick to tags or branches of APR if needed. On the stable branch, the tree should be moved from this state to supporting a released version of APR. Roy raised some concerns about not being able to track versions of APR with the fixes we need. The APR guys say that everyone with httpd commit can get APR commit if needed, so that solves part of the problem, but I wonder if those httpd committers can drive APR releases.
Fwd: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to the [EMAIL PROTECTED] [EMAIL PROTECTED] Tuesday, November 16, 2004 4:08:20 PM During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
[EMAIL PROTECTED] Tuesday, November 16, 2004 4:28:38 PM On Tue, Nov 16, 2004 at 04:08:20PM -0700, Brad Nicholes wrote: slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote, not veto). I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 4:46:45 PM On 17.11.2004, at 00:30, Cliff Woolley wrote: On Tue, 16 Nov 2004, Justin Erenkrantz wrote: I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. I agree with Justin, but I recognize what a pain in the ass it is for people working off in the corners of the codebase. So -0 from me. Exactly the same feelings here, so -0 from my side too. Cheers, Erik
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 5:21:28 PM +1 Lazy consensus applied in this way will help the less popular parts of our codebase to continue to evolve and stabilize. Up to this point, only the most popular patches have been getting enough attention to receive the required three +1s. Going in this direction is definitely the right way to go. p.s. why is this on the pmc list? we have committers who aren't PMCers, right? -aaron On Nov 16, 2004, at 3:08 PM, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to the dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 5:48:15 PM If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin This is the definition of the downward spiral that we are in. If the code doesn't get out there then the interest in the code drops off. The more the interest in the code drops off, the less code there is to put out there. The whole idea behind Open Source is to get the code in front of the user, allow them to test, supply feedback so that bugs can be fixed. If the code gets hung up in the STATUS file, we don't get any feedback therefore the code never gets fixes. I would personally rather see the code in front of the user so that it is reviewed by more than just those with voting rights. How else are we going to generate a community. Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 4:28:38 PM On Tue, Nov 16, 2004 at 04:08:20PM -0700, Brad Nicholes wrote: slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote, not veto). I think this is a bad idea and would make stable turn into CTR. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. If there are a lack of votes for backport, then I believe that is a sign that there is not a healthy enough community of people who are able to review the code. I'd like to ensure that we don't create 'islands' of code that do not have sufficient people who understand it. -- justin
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 6:00:16 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 it might open up a couple of bugs/regressions, but it will certainly mean more fixes going in On 17/11/2004, at 10:08 AM, Brad Nicholes wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. Brad - -- Ian Holsman Director Network Management Systems CNET Networks PH: 415-344-2608 (USA) /(++61) 3-9818-0132 (Australia) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iD8DBQFBmqKgq3pgvCz4ZCcRAk6aAJ4pjGy170JuvPoq8fWgWtsf3Qw+kQCfXSe+ RmXGGKTaFWWTH6UeO/IQVZU= =k5e/ -END PGP SIGNATURE-
Fwd: Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
moving to dev@ list [EMAIL PROTECTED] Tuesday, November 16, 2004 6:04:08 PM This proposal is in addition to the proposal on the dev list. Once the code converts from CTR to RTC in a stable branch, then we need a way to make sure that overhead doesn't stifle ennovation. The fact is that users and casual developers pay more attention to the stable branch rather than HEAD. Why?? Because that is what matters to them. If there is an itch that needs to be scratched, it's in the code that they are depending on to run their site. That is usually not the bleeding edge. Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 4:29:31 PM * Brad Nicholes [EMAIL PROTECTED] wrote: During ApacheCon several httpd PMC members got together to discuss current issues with the httpd project and to try to find better ways to manage the project. One of the issues that was discussed heavily was the current policy of RTC vs CTR. The feeling of some of the PMC members is that the RTC policy as it is currently implemented on the 2.0 branch, is causing unnecessary overhead which has resulted in the slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. I think, the RTC policy for 2.0 is a good thing. It *forces* reviews, which actually often helped to prevent introducing new bugs (not always though, but that's probably another issue). IMHO a better way bring the development further is the suggestion on the dev list. *absolute* feature freeze on stable branches (except 1.3?), bug fixes only. Though it would need some time to establish the trust of the community in so much more versions, I like that idea somehow. nd -- Das einzige, das einen Gebäudekollaps (oder auch einen thermonuklearen Krieg) unbeschadet übersteht, sind Kakerlaken und AOL-CDs. -- Bastian Lipp in dcsm
Re: Branching and release scheduling
I have to agree with Jim. Well put! Brad [EMAIL PROTECTED] Tuesday, November 16, 2004 5:55:04 PM On Nov 16, 2004, at 3:16 PM, Manoj Kasichainula wrote: We had a good discussion over lunch today on our release processes and how to have stable releases while making new feature development as fun and easy for the geeks as possible. The is a purely personal POV, and I'm wishing I was at the lunch because this addresses something that I've been think and maybe others as well, considering a similar Email thread I see from Brad N, so take the below as my own opinions. I find it somewhat hard to get excited by 2.x development because 2.1 almost seems like a black hole at times... You put the energy into the development but have to wait for it to be folded into an actual version that gets released and used. Now waiting is good, but sometimes it seems that the backports are slow in getting approved. I think most developers like, well, if not *immediate* satisfaction, something more quick than the current develop-2.1-and-wait- for-a-long-time-before-folded-into-2.0. Stability is great, but we should be careful that we don't unduly sacrifice developer energy. This may not be so clear, so feel free to grab me :)
Re: Branching and release scheduling
On: Tue, 16 Nov 2004 07:55:13 PM EST, Jim Jagielski wrote On Nov 16, 2004, at 3:16 PM, Manoj Kasichainula wrote: We had a good discussion over lunch today on our release processes and how to have stable releases while making new feature development as fun and easy for the geeks as possible. I find it somewhat hard to get excited by 2.x development because 2.1 almost seems like a black hole at times... You put the energy into the development but have to wait for it to be folded into an actual version that gets released and used. [snip] Stability is great, but we should be careful that we don't unduly sacrifice developer energy. This may not be so clear, so feel free to grab me :) Hello, Yes, I've lurked on this list barely a week, and the only source contributions are very minor bugs (see my PATCH nags and s/CVS/SVN/g). However I was recently surfing around (for no apparent reason) and stumbled upon the GCC Development Plan ( http://gcc.gnu.org/develop.html ), which seems relevant to the current discussion. Of particular note is the schedule section, which sets a definite time frame of two months per release. IMO this shows committment to the project, and keeps everything moving forward, and would avoid the tendency to procrastinate. It's a powerful thing to put something in writing. I'm not a GCC developer, so I'm not biased,and have no experience with the plan in practice. I am however a user of GCC, and I do notice new features every few months. The idea of constant development seems unbalanced. If it's devloped but never tested or merged or released or stabalized or documented, it is all time wasted as far as the user is concerned, because they will never know about any of it unless there's a link to download a release on main site's downloads page. Who is going to know the code better than the person who writes it? If everyone is constantly playing with new features, who does the work of writing good docs, testing, merging, and fixing bugs? Development isn't even 1/2 of the job, and as such it needs to be balanced with all of the rest. Otherwise you have software which tries to do too much and doesn't quite deliver everything it promises. On the other hand, I know how it is, when I go to bed sleepy, thinking of some code feature or problem, wake up a few times at night and think of it, and have some ideas in the morning, which maybe disappear forever unless I make use of them. Sometimes just making a few notes isn't enough. This is the argument for constant development? To have the most flexibility and convenience to continually to capture as many new ideas as possible? The balance often seems to be three stages: Develop merge (alpha, odd minors), freeze test (beta, odd minors), bugfix only (gamma, even minors). So then the question again: how to keep releasing on a regular schedule? For each piece of new code that is developed or merged, it will need to be maintained later on (for documentation, testing, and bug fixes), so plan ahead. Is the original coder going to commit to that work, or would they prefer adding new features? If they want to develop, then they must find a maintainer to work with the developers with write-access. Are there enough qualified and trusted people with write-access to the source repository to review code submissions? Let's not overload them with a bunch of abandonned projects or too much new code from one person. Are there any prequalifiations like has-docs, has-maintainer(s), needs-testing, has-orphans or needs-updates (with respective threshhold values to allow new code but prevent a single developer from adding too much new code until they finish their old code), which could let the maintainer focus on code which is ready to be added or merged? Or is submission-throttling a bad idea, and why? Seems like there's a lot of code with a lot of easy to fix bugs and not enough people for the grunt work of reviewing, responding and ultimately closing all of them, but plenty of people to keep pushing new code development. Result: old bugs don't get fixed, new code doesn't get merged, no joy all around. I look forward to constructive responses if any. I'm just throwing this out there for the heck of it. Thanks as always for all the hard work: thinking of good ideas, implementing new policies and code to strengthen the development infrastructure, and the resultant excellent software, and documentation which makes the software come alive for the rest of us. Leif
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
At 05:28 PM 11/16/2004, Justin Erenkrantz wrote: On Tue, Nov 16, 2004 at 04:08:20PM -0700, Brad Nicholes wrote: slowdown of activity in the httpd project. One proposal that was made would be to adopt a lazy consensus rule. Basically what this means is that when a backport is proposed in the STATUS file, after a period of time and if the proposal has not recieved any 0 or -1 votes, it would automatically be approved for backport by lazy consensus. The purpose for this proposal is to avoid stagnation of backport proposals in the STATUS file simply due to the lack of votes. -1 (vote, not veto). I think this is a bad idea and would make stable turn into CTR. Let me make certain this is clear - it is REVIEW then commit, however, if nobody else cares to voice an objection after notice of intent to commit code, then the contributor wouldn't have obstacles. And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. I entirely agree - stability of the already-done version 2.0 is paramount to me. However we need to make some edge case expections for that code which only one or two voulenteers are familiar with. e.g. Win32 service code is only known by 4 members, Novell by only one, and ldap only three of us ever pay attention. 'Platform maintainers' should have some way to get measurable and tested code improvements back into 2.0. Bill
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
William A. Rowe, Jr. [EMAIL PROTECTED] writes: And, that, I believe jeopardizes the overall quality of the code. And, I'm not willing to take that risk. I entirely agree - stability of the already-done version 2.0 is paramount to me. However we need to make some edge case expections for that code which only one or two voulenteers are familiar with. e.g. Win32 service code is only known by 4 members, Novell by only one, and ldap only three of us ever pay attention. 'Platform maintainers' should have some way to get measurable and tested code improvements back into 2.0. I have ambivalent feeling toward this. If the same rules were applied to docs project, Japanese translation would be dead long time ago, at least on 2.0 branch. Thanks to the exception made for docs, 2.0 Japanese translations are almost as good as 2.1 ones. So I do understand the pain of working on something not majority of people have interest. It takes some time to get even one +1 (except the one from the original translator) for Japanese translation because only three people are working on Japanese translation and only two of them are committers. But I also want 2.0 to remain stable and seeing mod_rewrite regression happened even with current model, it's hard for me to tell which one is really better. At the moment, I'm +1 on this given that the waiting period is long enough. As I understand it, current proposal says that even -0 would prevent the lazy consensus. If no one is bothered enough to give -0 on the matter, it probably should go in. -- Yoshiki Hayashi
Re: [PROPOSAL-VOTE] Adopt lazy consensus for backports...
On Tue, Nov 16, 2004 at 10:43:15PM -0600, William A. Rowe, Jr. wrote: I entirely agree - stability of the already-done version 2.0 is paramount to me. However we need to make some edge case expections for that code which only one or two voulenteers are familiar with. e.g. Win32 service code is only known by 4 members, Novell by only one, and ldap only three of us ever pay attention. 'Platform maintainers' should have some way to get measurable and tested code improvements back into 2.0. I'd be fine with us defining some exceptions to the 'RTC' area (and making it CTR and hence lazy consensus): stuff like platform specific code, or experimental modules. But, remember, experimental modules as a concept disappears in 2.2: the only way to introduce a new module is to roll it into the next minor release branch. However, I strenuously object to core code changes being merged into stable without 3 +1s first. The real solution to Brad's problem of not having enough code visibility for your changes is to push out more frequent branches *not* making stable turn into unstable. Pushing out a new 2.(x+2).0 release every few months (or even 6 months!) would go a long way to solving the 'black hole' dilemma. Yet, I don't believe that lapsing back into CTR is the right solution. -- justin
