Re: End of Life Policy
On Nov 20, 2004, at 12:11 PM, Paul Querna wrote: No, I do not want to make it forbidden. Rather, I would like a set date where we do not provide _any_ implied support as the HTTPd project. We don't provide any implied support anyway. Sure, we'd like to release perfect software, but we make no warranties[1], and we definitely shouldn't be making any implied warranties that might contradict our license. In other words, setting dates like this goes against our license and in my opinion goes against our philosophy. -aaron [1] Excerpt from the Apache License 2.0: 7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
Re: End of Life Policy
On Nov 20, 2004, at 10:32 AM, Paul Querna wrote: I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. As long as there are people willing to work on bug fixes or other improvements, who are we to stop them? They can of course always fork, but I'd rather have them contribute their bug fixes back to us. Official policies are just red tape. -aaron
Re: End of Life Policy
Paul Querna wrote: So, we are nearing a new stable branch. For the first time in a long time we will have a no-longer-developed-but-stable-branch in wide use. (2.0.x) I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Thoughts? -Paul Querna Why drive artificial constraints on any of our release processes? If a sizeable number of people (ie, a community) are interested in maintaining 2.0 for the next 20 years, then why prevent it 'by decree'? Bill
Re: End of Life Policy
On Monday 22 November 2004 09:11, Bill Stoddard wrote: Why drive artificial constraints on any of our release processes? If a sizeable number of people (ie, a community) are interested in maintaining 2.0 for the next 20 years, then why prevent it 'by decree'? Id certainly have to agree with this logic. By the standard proposed (6-12 months following new stable release), 1.3 would have been dead, buried, and have a house built on top of it by now. Still, we have recently seen in this very list that there IS a community using 1.3 for various reasons. While I can understand at a certain point scaling back development resources and focus request towards a particular branch, I also believe that no arbitrary EOL cycle should be implemented on a community supported product. There are no real commercial support oblications imcumbant on Apache to continue to provide access and support for patch roll-in for old versions, is there? My own personal $.02 is that EOL should be little more than pulling the status updates from being sent out and not actively requesting backports from 2.x to 1.3.x. Anything beyond that should be driven by community... or lack thereof Eventually when no one is supporting the codebase and security issues pile up with warnings on the website and release files that this is an old version provided for legacy users only. we do not recommend production systems run this version, instead use [insert new branch here], they will upgrade and 1.3.x (and later 2.0.x) will die a natural death. If there are coorporate costs involved in legacy version support then I can perhaps understand an EOL but with a mostly community-developed and -supported product, I see little reason to introduce an arbitrary limitation on the life of a branch. -- Wayne S. Frazee Any sufficiently developed bug is indistinguishable from a feature. pgpVsm4ZBmYeU.pgp Description: PGP signature
Re: End of Life Policy
On Sat, Nov 20, 2004 at 01:11:16PM -0700, Paul Querna wrote: Jeff Trawick wrote: The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. No, I do not want to make it forbidden. Rather, I would like a set date where we do not provide _any_ implied support as the HTTPd project. Come on, this is silly. The implied support is only ever how developers spend their time, be that bugzilla triage or writing code etc. In a free software project no policy gets to dictate how developers must spend their time, neither can you predict exactly how many months or years it will be before developers stop caring about 1.3 or 2.0 or 2.2. joe
Re: End of Life Policy
On Sat, 20 Nov 2004 13:11:16 -0700, Paul Querna [EMAIL PROTECTED] wrote: Jeff Trawick wrote: On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. No, I do not want to make it forbidden. Rather, I would like a set date where we do not provide _any_ implied support as the HTTPd project. If people continue back porting changes, thats great, but I would like a time line to help support our users. It is not fair to them to leave the branch with an indeterminate status. I have to plead continued confusion ;) people ... backporting changes and then doing a release *is* something done by the HTTPd project. May I suggest that we ignore 2.0 stagnation/freeze/whatever as part of plans for 2.2 adoption, and instead concentrate on positive aspects? There is a set of features which will entice early adopters; these same early adopters will prove (painfully or not) that 2.2 is production ready, and more and more folks will join the bandwagon as modules become available and they see that 2.2 is where most developer focus lies. It is time to prominently advertise What's coming with Apache httpd 2.2 on http://httpd.apache.org. Besides new features, documentation on some other items could aid support of 2.2: * how to get involved with testing * porting modules from 2.0 to 2.2 * supporting 2.0 and 2.2 in same module source (many folks have no choice in the matter; let 'em know it is okay and we still respect them) * porting modules from 1.3 to 2.2 (this is an opportunity to do a better job helping folks move off of 1.3, but this time move them directly to 2.2)
End of Life Policy
So, we are nearing a new stable branch. For the first time in a long time we will have a no-longer-developed-but-stable-branch in wide use. (2.0.x) I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Thoughts? -Paul Querna
Re: End of Life Policy
If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. Remember Jim's comments - many users will be 'stuck' on 2.0 for some time into the future while their vendors are preparing their 2.2 builds of add-in modules. Bill At 12:32 PM 11/20/2004, Paul Querna wrote: So, we are nearing a new stable branch. For the first time in a long time we will have a no-longer-developed-but-stable-branch in wide use. (2.0.x) I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Thoughts? -Paul Querna
Re: End of Life Policy
William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. It does not help an Apache User who maintains any number of servers with httpd-2.0.x. I want the policy to provide an insight for these users -- so they know how long they have to start an upgrade cycle within their environment. Remember Jim's comments - many users will be 'stuck' on 2.0 for some time into the future while their vendors are preparing their 2.2 builds of add-in modules. Yes, but if we set a 10 month end of official support policy, it will also encourage these vendors. If in 8 months, 2.2 turns out to be a major dud, we can reconsider this policy. These are all example time lines, but I believe we need some sort of initial minimum supported policy, as a service to our users. -Paul
Re: End of Life Policy
On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. There are more than 3 httpd developers who promise their own customers that their 2.0-based servers will be supported for some years to come with no migration steps required to get critical fixes, and it will be only natural for those folks to want to share any such fixes with the rest of the world.
Re: End of Life Policy
Jeff Trawick wrote: On Sat, 20 Nov 2004 11:45:31 -0700, Paul Querna [EMAIL PROTECTED] wrote: William A. Rowe, Jr. wrote: If we simply leave 2.0 as no-features / critical bugfixes / security bugfixes / any other nice patches someone wants to craft and get votes for - that would be sufficient. That is how I would want to leave it. The problem is, this does not set *any* expectations for how long we will provide these fixes. The PMC would have to be willing to specifically forbid maintenance of 2.0 in order to determine such a date. No, I do not want to make it forbidden. Rather, I would like a set date where we do not provide _any_ implied support as the HTTPd project. If people continue back porting changes, thats great, but I would like a time line to help support our users. It is not fair to them to leave the branch with an indeterminate status. There are more than 3 httpd developers who promise their own customers that their 2.0-based servers will be supported for some years to come with no migration steps required to get critical fixes, and it will be only natural for those folks to want to share any such fixes with the rest of the world.
Re: End of Life Policy
Paul Querna, Saturday, November 20, 2004 13:32 I would like to have a semi-official policy on how long we will provide security backports for 2.0 releases. I suggest a value between 6 and 12 months. Support 2.0 for the lesser of: *) Until the next stable release after 2.2 (2.4 or 3.0) *) 12-24 months from 2.2 release Rationale: Don't stop supporting 2.0 until 2.2 is widely used. Getting usage statistics is tricky, with people disabling server version string. Have a poll? ;-) Widely used should be quantifiable, the definition is debatable and the timeframe may not be predictable. Say over 50%, like 2/3 of the combined users of 2.0 and 2.2 use 2.2, 1/3 use 2.0. Or 75/25. Or shall we still include 1.3? ;-) Many distrobutions will provide their own security updates anyways, so this would be a service to only a portion of our users. I use a distribution, but I prefer tarballs to package hell for things like Apache. The distributions may patch something as quickly, but on an older version. It can take some months or even years before the package uses the newer version which may have a non-security bugfix. Anything less than a year seems like pulling the rug out from under people. Why stop supporting the software before it even gets widely adopted? How long since 2.0 came out, and there are people still stuck with 1.3, due to valid concerns. As always, this is open source, and I would not stop anyone from continuing support for the 2.0.x branch. My goal is to help set our end user's expectations for how long they have to upgrade to 2.2. Maybe it can be done with communication through the available channels (web, mail, tarballs)? We strongly urge you to migrate those old 2.0.x or (ack) 1.3.x modules to 2.2.x within the first ( 6 M 24 ) months after the 2.2.x release! Maybe put a timed nag message at the end of the ./configure script: alert people of the support window, advise them to upgrade modules. Not necessarily explicitly dropping security backports, which makes it look like the developers drop the ball, but turning it around on the user, to let them know that it's them who chose to drop the ball. 24 months is a *** eternity though... :p Leif
