[HACKERS] EOL for 7.4 and 8.0
Hello, We need to make sure and send out multiple announcements of this. At least 2 during the month of July. JD -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4 and 8.0
On 06/24/2010 09:04 AM, Joshua D. Drake wrote: Hello, We need to make sure and send out multiple announcements of this. At least 2 during the month of July. Ach. I drafted an annoucement ... did I ever send it out? If not, will do so immediately. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4 and 8.0
On Thu, 2010-06-24 at 10:34 -0700, Josh Berkus wrote: On 06/24/2010 09:04 AM, Joshua D. Drake wrote: Hello, We need to make sure and send out multiple announcements of this. At least 2 during the month of July. Ach. I drafted an annoucement ... did I ever send it out? Not sure actually. I was just thinking that since it is only a month... You might want to mention the EOL of 8.1 in Nov too. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 509.416.6579 Consulting, Training, Support, Custom Development, Engineering -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4 and 8.0
On 6/24/10 11:03 AM, Joshua D. Drake wrote: On Thu, 2010-06-24 at 10:34 -0700, Josh Berkus wrote: On 06/24/2010 09:04 AM, Joshua D. Drake wrote: Hello, We need to make sure and send out multiple announcements of this. At least 2 during the month of July. Ach. I drafted an annoucement ... did I ever send it out? Not sure actually. I was just thinking that since it is only a month... You might want to mention the EOL of 8.1 in Nov too. Darn, looks like I didn't. Announcing now. -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Migration is really only half the story, or not even that much. Every time you move to a new Postgres version you have to do extensive work to revalidate your application. If you don't do that you're just asking for trouble. But it can be painful, expensive and disruptive. I know of places where it can take weeks or months of effort. So the less often you have to do it the better. This would be true even if we had had a perfect working inplace upgrade mechanism for years, which as you and Greg point out is not true. I don't agree with this - migration is much more important than you make out. Testing and validation can be a pain, but it can be done concurrently while your main production site is still chugging along and taking orders. At some point, however, migration *will* cause production downtime[1]. This is one of the Achilles' heel of Postgres, and I'm frankly surprised it has taken us this long to get pg_migrator to a somewhat working state. I don't have any clients who don't/can't upgrade because they can't manage the downtime, but I have more than one avoiding upgrade because of revalidation costs. Well, I certainly had many clients who had major problems dealing with the implicit casts removed in 8.3, but there are also some in which the sheer size of the database is a factor as well. I think Robert Treat can probably chime in on some upgrade woes here too. [1] Okay, there are some tricks to work around this or severely minimize the downtime /Bucardo_plug, but it's still a truism that upgrading versions is a pain and nearly always involves production downtime. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200912040846 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksZEqMACgkQvJuQZxSWSsgGyACdEyfIqwFsFrt9ZnQ2DNPVYIWP j08AoK+cLC84HSjlIbzJY8Gz/gAa6D74 =AzuV -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Mark wrote: Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Andrew wrote: But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. All of this ignores a huge reason why we have an implicit obligation to support past releases for a long time: our horrible lack of an upgrade option. That's only now starting to get remedied somewhat with pg_migrator, Bucardo, and Slony, but the default way is still to do a dump-and-restore. Until we can make this process take minutes instead of days for large databases, people are going to end up stuck to what version they are on. Knowing they are going to have to do it all over again later is not going to be very confidence inspiring. Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200912021218 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksWokQACgkQvJuQZxSWSsg5kACfdd9nZtHSG/KcOAIOGxVZ81/o TUEAniaG4vWo4CY4v+3DlByJ4AZ6JXKP =MyN9 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Wed, Dec 2, 2009 at 12:22 PM, Greg Sabino Mullane g...@turnstep.com wrote: Mark wrote: Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Andrew wrote: But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. All of this ignores a huge reason why we have an implicit obligation to support past releases for a long time: our horrible lack of an upgrade option. That's only now starting to get remedied somewhat with pg_migrator, Bucardo, and Slony, but the default way is still to do a dump-and-restore. Until we can make this process take minutes instead of days for large databases, people are going to end up stuck to what version they are on. Knowing they are going to have to do it all over again later is not going to be very confidence inspiring. Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Dave Page wrote: On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: ... 8.1 in RHEL5 ... +1 for letting 7.* and 8.0 die whenever no-one's motivated to bother supporting it anymore. Presumably you'll be on the hook until 2014 for 8.1 security patches I can't see the community wanting to support it for that long -1 for letting 8.1 die while someone major still supporting it, even if that means EOLing 8.2 before 8.1. As a PG user, it's confidence inspiring to see a project that can provide 7-years of support on a version. As a Red Hat customer, I'd feel happier if my database were not considered dead by the upstream community. It also feels more in the spirit of open-source to me -- where if one member is willing to put in work (Red Hat/Tom), the benefits are shared back; and in exchange the rest of the community can help with that contribution. I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm certainly not going to argue against doing the same for 8.1. Frankly, I think we could do 7.4 and maybe 8.0 six months earlier. I think the best would be to say 7.4 and 8.0 end in Jan 2011, and 8.1 switches to only high-priority security patches at that date. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Robert Haas wrote: Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. Agreed. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. Agreed. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Robert Haas wrote: Again, to emphasize: many people are using 7.4, or 8.0, or 8.1, not because they necessarily want to, but they can't easily afford the downtime to upgrade. Cutting them off arbitrarily early won't win us any friends. Once pg_migrator (or better, in-place upgrades) is working well, we can start setting EOL on versions based on number of years of some other criteria. At the moment it doesn't seem likely that pg_migrator is *ever* going to support upgrading from 7.4 or 8.0 or 8.1 to any later version. I'm not saying that's good, but nobody's expressed much interest in making in-place upgrade work even from an 8.2 base, let alone any older version. For that matter, there's been no concerted effort to resolve the limitations of the 8.3 - 8.4 upgrade. It isn't technically impossible for the 8.3 - 8.5 path to be smoother than the current 8.3 - 8.4 path, but nobody seems excited about working on it. Migration is really only half the story, or not even that much. Every time you move to a new Postgres version you have to do extensive work to revalidate your application. If you don't do that you're just asking for trouble. But it can be painful, expensive and disruptive. I know of places where it can take weeks or months of effort. So the less often you have to do it the better. This would be true even if we had had a perfect working inplace upgrade mechanism for years, which as you and Greg point out is not true. I don't have any clients who don't/can't upgrade because they can't manage the downtime, but I have more than one avoiding upgrade because of revalidation costs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I wrote: No, it should be longer. June is practically around the corner as far as business planning is concerned. Make it a year. Since it's mid November, why not just say 2011? This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. - -- Greg Sabino Mullane g...@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200912011122 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAksVQtgACgkQvJuQZxSWSsj26ACgr/QRKytEc9dWYar0gY6HJZ0C YYsAni96hrCF0AmBIjY/Fg5vHS+LauKT =ELLh -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, Dec 1, 2009 at 4:41 PM, Tom Lane t...@sss.pgh.pa.us wrote: Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... Presumably you'll be on the hook until 2014 for 8.1 security patches for RHEL 5 (looking at http://www.redhat.com/security/updates/errata/)? I can't see the community wanting to support it for that long, so I'd suggest we can (respectfully) ignore your commitments in that regard. I'm for EOLing *at least* 7.4 and 8.0 by January 2011, and I'm certainly not going to argue against doing the same for 8.1. Frankly, I think we could do 7.4 and maybe 8.0 six months earlier. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, 1 Dec 2009, Tom Lane wrote: Greg Sabino Mullane g...@turnstep.com writes: This thread never got resolved. I think we can all agree that EOL for 7.4 is a when, not an if? Can we get -core to take a stance here and pick a date? I like the clean smooth lines of January 2011, and thus saying that 2010 is the last year in which we'll backpatch things to the 7.4 branch. But I'll stick to whatever core thinks is best. Just let the advocacy team know so we can start work on it. If we're going to set the date that far off, I'd be inclined to EOL 8.0 at the same time. It'll be six years old by then. You could make a good argument for nuking 8.1 at the same time --- it'll turn five in November 2010. Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. I have no personal commitment to 8.0 at all because Red Hat never shipped that in a RHEL release ... Just curious, but since you do all the back patching as it is, and building the source tarballs is simple enough ... What are RedHats EOL dates for the various releases? Doesn't mean that packagers have to make new packages ... I personally think new packages shouldn't be made for anything older then *maybe* 3 releases (8.2, 8.3 and 8.4), but even that I think tends to be a bit excessive ... but doing source tar balls is easy enough ... Marc G. FournierHub.Org Hosting Solutions S.A. scra...@hub.org http://www.hub.org Yahoo:yscrappySkype: hub.orgICQ:7615664MSN:scra...@hub.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Marc G. Fournier scra...@hub.org writes: What are RedHats EOL dates for the various releases? Dave already mentioned a public page for that: http://www.redhat.com/security/updates/errata/ Based on track record so far, Red Hat isn't going to care about anything but high-priority security issues towards the end of the life cycle, but theoretically I'm on the hook till 2014 for 8.1.x. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
is there a reason why we can't follow a similar 4+3 life cycle? packagers r produced for the first 4y after .0 release and only source updates for year 5 thru 7? if we could advertise such on the web, there would be no question as to when bug reports are accepted (n+4y) and when only security ... and after y7, it's just not supported at all ... that would kill packager requirements on 8.0, 8.1 (as of last month) and totally kill 7.4 as of nov '10 Sent from my iPhone On 2009-12-01, at 14:33, Tom Lane t...@sss.pgh.pa.us wrote: Marc G. Fournier scra...@hub.org writes: What are RedHats EOL dates for the various releases? Dave already mentioned a public page for that: http://www.redhat.com/security/updates/errata/ Based on track record so far, Red Hat isn't going to care about anything but high-priority security issues towards the end of the life cycle, but theoretically I'm on the hook till 2014 for 8.1.x. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Scrappy wrote: is there a reason why we can't follow a similar 4+3 life cycle? packagers r produced for the first 4y after .0 release and only source updates for year 5 thru 7? if we could advertise such on the web, there would be no question as to when bug reports are accepted (n+4y) and when only security ... and after y7, it's just not supported at all ... that would kill packager requirements on 8.0, 8.1 (as of last month) and totally kill 7.4 as of nov '10 What packagers produce is surely up to them. If RedHat or Devrim or Dave want to produce a package that's their prerogative. And IMNSHO 4 years is too short a period for non-security bugs. We have seen odd behaviour issues past those dates. The time between these periodic debates seems to be getting shorter and shorter. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Andrew Dunstan and...@dunslane.net writes: The time between these periodic debates seems to be getting shorter and shorter. No, this is just a continuation of the unresolved thread from a month or so ago. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Personally I'll still be on the hook for maintaining 8.1 in RHEL5 so I'd be just as happy to keep it alive a bit longer, but if the community doesn't want to deal with it that makes perfect sense. Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Smith g...@2ndquadrant.com writes: Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. Well, actually, if it's just what will RH support, I just today got launch commit on this: https://bugzilla.redhat.com/show_bug.cgi?id=489479 which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014, but whether many people will still be using it is another question. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Greg Smith g...@2ndquadrant.com writes: Some people consider the extended support and easy upgrades of the RHEL5 versions valuable enough that they have a strong preference to use the version of PostgreSQL that ships with it. Right now, when such people ask me about using 8.1 in that context, I tell them while it would be better if they ran something more recent, the performance of that version is reasonable and the bugs they might run into aren't that serious. This is not the case at all for either 7.4 or 8.0, which have been completely indefensible as versions to consider deploying for quite some time already. Well, actually, if it's just what will RH support, I just today got launch commit on this: https://bugzilla.redhat.com/show_bug.cgi?id=489479 which might change things a bit. PG 8.1 will be *in* RHEL5 until 2014, but whether many people will still be using it is another question. Having 8.4 available and supported in RHEL5 will be nice. Maybe it was spurred by the talk I gave on 8.4 a couple of weeks ago at RH HQ? (j/k). But the issue for me is not what vendors support but how often we ask someone to upgrade if they want to stay on a community supported base. As I remarked before, other things being equal, I think five years is a reasonable interval, and given that many users don't upgrade right on a .0 release, I think a release lifetime of about six years is therefore about right as a target. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Well, actually, if it's just what will RH support, I just today got launch commit on this... What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. That makes supporting 8.1 quite a bit more valuable to the community than the earlier releases IMHO. Moving forward, I was hoping that we all get RHEL6 as a deployment option in the not so distant future for a platform that integrates 8.4 from day one; I didn't think that deploying RHEL5 was going to be the only choice for too much longer. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
Greg Smith g...@2ndquadrant.com writes: What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. Okay, but how much of the argument for that hinges on it being the only thing Red Hat will support on RHEL5? Moving forward, I was hoping that we all get RHEL6 as a deployment option in the not so distant future for a platform that integrates 8.4 from day one; I didn't think that deploying RHEL5 was going to be the only choice for too much longer. I don't believe I'm allowed to say anything about RHEL6 release schedules. However, if you are paying attention to what has shipped in recent Fedora releases, it's not hard to figure out that it will have PG = 8.4. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [CORE] [HACKERS] EOL for 7.4?
On Tue, 2009-12-01 at 17:14 -0500, Tom Lane wrote: However, if you are paying attention to what has shipped in recent Fedora releases, it's not hard to figure out that it will have PG = 8.4. I thought RHEL 6 would ship with 8.3. It will be perfect if it skips 8.3. -- Devrim GÜNDÜZ, RHCE Command Prompt - http://www.CommandPrompt.com devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz signature.asc Description: This is a digitally signed message part
Re: [CORE] [HACKERS] EOL for 7.4?
Tom Lane wrote: Greg Smith g...@2ndquadrant.com writes: What I was trying to suggest was that right now, there are situations where a new deployment on 8.1 is still completely reasonable and possible to justify in the Enterprise Linux space, whereas I don't know of any situation where 7.4/8.0 can be similarly defended as a good idea. Okay, but how much of the argument for that hinges on it being the only thing Red Hat will support on RHEL5? Sure, at some point in 2010, we may reach a point where it would be ill advised to build a new system using RHEL5/PG8.1. I was suggesting more that there are completely reasonable reasons to deploy 8.1 even right now in 2009, and people are doing so. That gives the release a lot more future than 7.4 and 8.0, which anyone sensible gave up on a while ago. I'm all for dropping those older ones, but I don't think getting more aggressive than that and bundling 8.1 in while you're at it is so wise. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.com
Re: [HACKERS] EOL for 7.4?
On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. We'd want to do a full publicity around this, including a how do I upgrade page and an what does EOL mean for an OSS project page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. +1 -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Andreas 'ads' Scherbaum wrote: On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. Nobody that I have seen is arguing against EOLing 7.4. We'd want to do a full publicity around this, including a how do I upgrade page and an what does EOL mean for an OSS project page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. +1 The only burden of significance I have seen actually mentioned, as opposed to supposed, is from Dave Page. What I and others have been arguing is necessary to do EOL right is a serious amount of notice, by way of press releases etc. We can't expect users to keep polling our web site to see if there's an EOL. That means we need to prepare for an EOL months or a year in advance, ISTM. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
I think that's the key argument here. We have several customers, which need a very careful and time consuming evaluation before they can go into production with a new platform, which is quite time consuming and needs significant preparation for them. Announcing an EOL early in time would give them the required time before the version used disappears. So, should we announce it for June? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. Nobody that I have seen is arguing against EOLing 7.4. True. But as Josh pointed out: some people/projects/companies need more motivation to actually consider an upgrade at all. What I and others have been arguing is necessary to do EOL right is a serious amount of notice, by way of press releases etc. We can't expect users to keep polling our web site to see if there's an EOL. That means we need to prepare for an EOL months or a year in advance, ISTM. Months. The software will not stop working once we announced the EOL. And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. Bye -- Andreas 'ads' Scherbaum German PostgreSQL User Group European PostgreSQL User Group - Board of Directors Volunteer Regional Contact, Germany - PostgreSQL Project -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, 2009-11-12 at 23:09 +0100, Andreas 'ads' Scherbaum wrote: On Thu, 12 Nov 2009 15:23:06 -0500 Andrew Dunstan wrote: Andreas 'ads' Scherbaum wrote: On Tue, 03 Nov 2009 10:32:17 -0800 Josh Berkus wrote: The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. I know several customers who decided to move from 7.3 only after the EOL was announced. If 7.3 would not has see an EOL, they would never ever have moved to a newer version. Nobody that I have seen is arguing against EOLing 7.4. True. But as Josh pointed out: some people/projects/companies need more motivation to actually consider an upgrade at all. We have discussed in the past EOLing 7.4 I thought at the end of this year. IMO 7.4 and 8.0 both need to be EOL. Can we just set a date and call it good? March 31st sounds good. Let's write up a quick announcement, add the letters EOL to the download pages and call it good. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 needs significant preparation for them. Announcing an EOL early in time would give them the required time before the version used disappears. So, should we announce it for June? No, it should be longer. June is practically around the corner as far as business planning is concerned. Make it a year. Since it's mid November, why not just say 2011? And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911121815 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkr8lykACgkQvJuQZxSWSsi6xACdHU7xKgsfG+/zE2StXp97mdjC XGoAn3LvIjzh1RKmD9K0Zyrg9W3LuHxt =jCVo -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, 2009-11-12 at 23:16 +, Greg Sabino Mullane wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 needs significant preparation for them. Announcing an EOL early in time would give them the required time before the version used disappears. So, should we announce it for June? No, it should be longer. June is practically around the corner as far as business planning is concerned. Make it a year. Since it's mid November, why not just say 2011? If a business wants support they can buy it. There is no reason for this community to continue supporting it. And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. We can say 5 years from release though. Joshua D. Drake -- PostgreSQL.org Major Contributor Command Prompt, Inc: http://www.commandprompt.com/ - 503.667.4564 Consulting, Training, Support, Custom Development, Engineering If the world pushes look it in the eye and GRR. Then push back harder. - Salamander -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, Nov 12, 2009 at 11:16 PM, Greg Sabino Mullane g...@turnstep.com wrote: And yes, i'm +1 for having a rule for EOL, like 5 versions are supported. If we released on a consistent schedule, this *might* be possible. But we don't, so we can't say something like this. We've already done this. I think we said three years but I'm too lazy to go search right now. It's as meaningless now as it was then. The reality is we back branch as far back as is convenient and stop when we run into a major problem that isn't fixable in old versions. 7.4 and even 8.0 are already EOL in the sense that they're past your arbitrary cutoff and there's no guarantee that we'll keep releasing fixes but there's no particular reason to stop yet. Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
daveg wrote: On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. I question whether it makes sense to EOL a version just to encourage people to upgrade --- that logic really seems beyond our scope. It might be practical to do it, but I see it taking us in a direction that we might want to avoid. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Thu, Nov 12, 2009 at 9:40 PM, Bruce Momjian br...@momjian.us wrote: daveg wrote: On Fri, Nov 13, 2009 at 02:22:01AM +, Greg Stark wrote: Really I think you guys are on the wrong track trying to map Postgres releases to commercial support terms. None of the Postgres releases are supported in the sense that there's no warranty and no promises, it's all best effort. If you want a promise of anything then pay someone for that service. As with any open source software if you're running 7-year-old versions of the software you can't seriously expect the developers to take any interest in bugs you discover which don't affect current releases. Other projects don't release back branches at all. The most the developers are likely to do if your bugs require serious engineering is declare that the version you're using is too old. Claiming to support versions that are too old is giving users a false sense of comfort. Encouraging users to use these versions is actually harming them as when this happens they will be stuck with either living with the bug or doing an immediate unplanned upgrade. I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. I question whether it makes sense to EOL a version just to encourage people to upgrade --- that logic really seems beyond our scope. It might be practical to do it, but I see it taking us in a direction that we might want to avoid. I don't agree with because we want to force people to upgrade, but I do agree with Dave Gould's point about giving a false sense of comfort (I made this same point upthread somewhere, I think). ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote: I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. What would this mean? How would it be different than the status quo? -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Fri, Nov 13, 2009 at 02:47:56AM +, Greg Stark wrote: On Fri, Nov 13, 2009 at 2:35 AM, daveg da...@sonic.net wrote: I suggest we announce now that both 7.4 and 8.0 will EOL when 8.5 is expected to ship, or to comfort those who never use .0 versions when 8.5.1 ships. What would this mean? How would it be different than the status quo? I suppose it would mean posting periodic prominent notices, moving the sources to the OLD directory, that sort of thing. I thought that was the topic of this thread? -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] EOL for 7.4?
We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? Part of the reason I suggest this is because it seems that not much gets patched back that far any more. AFAICT, committers basically stop back-patching at the point where it becomes an inconvenience, and most of the time that happens before you get that far back. As a result, while 7.4 is technically supported, it's not really all that supported. We are also very close to six years from the original release, if that's a magic number for anyone. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. I think the objections to declaring a hard and fast release lifetime in advance were well taken, though. And they aren't really relevant to a discussion of whether it is now appropriate to EOL 7.4. Part of the reason I suggest this is because it seems that not much gets patched back that far any more. AFAICT, committers basically stop back-patching at the point where it becomes an inconvenience, and most of the time that happens before you get that far back. As a result, while 7.4 is technically supported, it's not really all that supported. Tom just backpatched something to 7.4 the other day. It's not a matter of convenience, but many things that get backpatched relate to features introduced in relatively recent releases, not surprisingly. e.g. see Peter's commit message from today, Backpatched back to 8.0, where this code was introduced. Very occasionally things are seriously hard to backpatch. But that's the exception, not the rule. We are also very close to six years from the original release, if that's a magic number for anyone. Actually, I think it's a pretty good lifetime for a release. Many users don't want to migrate as soon as a new version comes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating more than once every few years - five would be a good number here. (This has nothing to do with whether or not we have in place upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) So allowing for those two things, six years is an excellent lifetime. And 7.4 has been pretty darn robust, it should be noted. The fact that we have quite long release lifetimes and outstanding release stability is a major plus for us. I have had users tell me over and over that that's one of the reasons they use Postgres. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
2009/11/3 Andrew Dunstan and...@dunslane.net: Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. Didn't we discuss EOLing based on number of previous versions? As in if we now announced that 7.4 would EOL when we release 8.5? (Though based on previous track record, that means it really should've been EOLed when we released 8.4, I guess) We are also very close to six years from the original release, if that's a magic number for anyone. Actually, I think it's a pretty good lifetime for a release. Many users don't want to migrate as soon as a new version comes out, they want to let it settle down. And they also don't want to have to go through the pain of migrating more than once every few years - five would be a good number here. (This has nothing to do with whether or not we have in place upgrade. It's more to do with the effort involved in revalidating a large application against a new release.) So allowing for those two things, six years is an excellent lifetime. And 7.4 has been pretty darn robust, it should be noted. Yeah, if one version has to stick around for a long time, 7.4 was a good choice for it :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Andrew Dunstan and...@dunslane.net writes: Robert Haas wrote: Part of the reason I suggest this is because it seems that not much gets patched back that far any more. Tom just backpatched something to 7.4 the other day. A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. (Maybe this means we can announce today that we're going to EOL it in a distant future, say in a year.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Magnus Hagander wrote: 2009/11/3 Andrew Dunstan and...@dunslane.net: Robert Haas wrote: We had a discussion back in July about our maintenance policy and the upshot of that discussion was that there were relatively few objections to dropping support for 7.4 - I believe Andrew Dunstan was the only one who spoke against it, and it wasn't clear how strenuous his objections were - but there were objections even to setting an end-of-life date for any subsequent release. However, we never really took any action based on that conversation. Maybe it's time? I don't object to EOLing 7.4, although I have a certain nostalgia for it ... it's the first release that contains anything of mine in it ;-) What I want is a proper process for declaring an EOL, though. In particular, we should announce it loudly and well in advance (by which I mean several months). The PR team should swing into action with a press release along the lines of PostgreSQL release version n.n. will reach the end of its maintenance life on -mm-dd. No patches of any kind will be made after that date. Users of this version are advised to start planning now to upgrade to a more modern version. Didn't we discuss EOLing based on number of previous versions? As in if we now announced that 7.4 would EOL when we release 8.5? (Though based on previous track record, that means it really should've been EOLed when we released 8.4, I guess) Indeed I recall that at least once the plan was to EOL 7.4 with the release of 8.4(or rather keeping a max of 5 active release branches) but I guess we kinda forgot about that :) Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote: Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. Agreed Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
2009/11/3 Simon Riggs si...@2ndquadrant.com: On Tue, 2009-11-03 at 13:01 -0300, Alvaro Herrera wrote: Tom Lane escribió: A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. If it's all that stable, what's the point in EOLing it? The only extra pain it causes is having to check whether each patch needs to be backpatched to it or not. Agreed Unless there are unfixable data loss bugs in it, I say we keep it. There's a difference between doing it and promising it. As long as we are supporting it, we *have* to backpatch critical things, even if that is a lot of extra work. Normally it isn't, but the case will come up. Nothing prevents us from backpatching simple things, and still releasing minors, for a non-supported version. It's just that we don't promise to do it. Many people still run it, so why make them move? Many people still run 7.3... We made them move... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com PGDay.EU 2009 Conference: http://2009.pgday.eu/start -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. I see we've already removed it from the home page anyway. People that are running older releases need to be able to find info about our position with respect to earlier releases. Keeping the docs available is important, since people may need to read up on how to dump data so it can be upgraded. We need a link to older releases with mention something like 7.4 Considered Stable, no tracking or fixing of new bugs 7.3 Considered Stable, no tracking or fixing of new bugs 7.2 Considered Unstable; upgrade immediately to avoid data loss Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. There's no need to remove them in chronological order - we should remove them based upon whether its sensible to maintain them further. It also helps if we can say we support software over long periods of time; that's very important for embedded software. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
2009/11/3 Simon Riggs si...@2ndquadrant.com: On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. I see we've already removed it from the home page anyway. People that are running older releases need to be able to find info about our position with respect to earlier releases. Keeping the docs available is important, since people may need to read up on how to dump data so it can be upgraded. We need a link to older releases with mention something like 7.4 Considered Stable, no tracking or fixing of new bugs 7.3 Considered Stable, no tracking or fixing of new bugs 7.2 Considered Unstable; upgrade immediately to avoid data loss Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. There's no need to remove them in chronological order - we should remove them based upon whether its sensible to maintain them further. It also helps if we can say we support software over long periods of time; that's very important for embedded software. +1 Pavel -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Simon Riggs si...@2ndquadrant.com writes: Personally, I would be more inclined to keep 7.4 as a supported version and remove support for 8.0, possibly 8.1 also. That would be basically useless from a maintenance-effort perspective --- if you don't work back through the branches in a methodical way when back-patching, you're liable to make mistakes; and in any case you have to study each branch delta even if you don't bother to commit. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. This presumes a single group of packagers that does all releases. We'd be the only project that does that, AFAICS. Seems strange to limit tasks to just the same few people all the time. We could ask for volunteer maintainers for releases, rather than just say the X people that do all the work no longer wish to do it and so we're not going to let anyone else either. No volunteers, no releases. That is exactly how this current project got started in the first place - picking up the maintenance responsibility on code that the original authors no longer wished to maintain. As in all things, any major changes with respect to packages should be discussed publicly, with notice given of any changes. Anybody that feels it is worth supporting could then come forward to do so. I hope we can avoid a sarcastic over to you then Simon reply. I'm not volunteering for it, but we should give others the opportunity to do so. My belief is there is a substantial user community for 7.4, and for 7.3 also. There is no reason why we should act like a commercial company when we're a volunteer organisation. So suggestion: announce that 7.4 will be EOLd in 6 months unless volunteers come forward to support further releases. At the same time, announce what the EOL plans are for other releases, so people can begin planning upgrades. In most stable production systems the planning cycle can extend to years, rather than weeks or months. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 10:46 AM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: Robert Haas wrote: Part of the reason I suggest this is because it seems that not much gets patched back that far any more. Tom just backpatched something to 7.4 the other day. A quick look in the cvs history shows 5 commits to 7.4 since the last set of releases, 6 commits to 8.0, 8 to 8.1, 13 to 8.2, 18 to 8.3. A couple of these patches were Windows-specific and were made only back to 8.2 because we desupported Windows in older branches awhile back. So far as I can see, the others were all made as far back as applicable. I think the lack of churn in 7.4 just means it's gotten pretty darn stable. I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting it. Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support it. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 5:23 PM, Robert Haas robertmh...@gmail.com wrote: Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support it. If there are few or no patches that have to be back-patched then that seems like an argument against EOLing it -- we can support it basically for free! Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. The dangers I see are: 1) The committers waste time back patching minor bug fixes to a release we would rather people not be using anyways. 2) Relatively few people are using it so perhaps the reason we haven't found any major bugs recently is because nobody's pushing it hard any more. 3) We're effectively making a promise we have no intention of delivering on. We claim we support it but when we find that hard-to-fix security problem or data corruption problem we'll suddenly EOL it leave people hanging. I think all of these are pretty minor problems in practice. The first because the committers themselves don't seem to be concerned, the second because these releases got pushed pretty hard for pretty long already, and the third because as Steve Crawford mentioned EOLing software doesn't instantly render it useless. It's not like we make any real support commitments unless you actually contract one of our employers anyways. And even if a bug isn't fixed you can usually engineer your application to work around the problem anyways by, for example, avoiding use of hash indexes or using password authentication instead of SSL certs, or whatever. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
All, So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month. The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I can think of several here in SF who have been working on upgrade plans for the past 3 years. An EOL is what's needed to give them a kick in the pants. The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. This isn't just a matter of supporting these users; it's a matter of what new developers think of Postgres. Programmers judge PG based on the version they first encounter, and they often don't check to see if later versions exist or what features they have. We'd want to do a full publicity around this, including a how do I upgrade page and an what does EOL mean for an OSS project page. If this goes well, we could EOL 8.0 after 8.5 comes out, and thus decrease our maintenance burden. This will also create some favorable spin around how long we do keep patching stuff ... how many other OSS projects batch-fix 5 years? Also, as Greg points out, 7.4 is just waiting for some exploit which is horribly hard to backpatch for us to desupport it on short notice, and that is NOT a service to our users. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. Those last 3 words seem to be a big sticking point, so much so that we're not even going to ask whether somebody else is willing to try. I see no reason to act that way and certainly no benefit for our users. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Many people still run [7.4], so why make them move? Many people still run 7.3... We made them move.. A nitpick. Nobody made anyone move. PHP 4 was EOL some time ago but is still in widespread use. We still see occasional postings regarding 7.3 and sometimes even earlier. The software doesn't suddenly stop working when it hits EOL. It is just an expectations-setting statement to end-users that the release is no longer likely to receive attention from the core team. Users are, of course, free to use/self-support the software as they see fit. It's open-source, after all. Cheers, Steve (who is in favor of 7.4 EOL despite one remaining 7.4 server in my upgrade queue) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 10:04 -0800, Steve Crawford wrote: Users are, of course, free to use/self-support the software as they see fit. It's open-source, after all. I've heard that a lot recently: It's open source, after all. Is this project not open source any more? Surely this project should be encouraging people within the project to take on new tasks. I don't think anybody should be forced to do anything they don't want to do. So if particular developers want to avoid patching certain releases, I respect that. But I don't see why *this* project cannot allow others to take on the tasks those developers choose not to perform. Why are we forcing people into a position where they have to set up their own independent project, what others would call a fork, in order to support software? Why are we not even willing to ask whether someone is willing? It all seems very strange to me. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 03, 2009 at 10:32:17AM -0800, Josh Berkus wrote: So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month. The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I can think of several here in SF who have been working on upgrade plans for the past 3 years. An EOL is what's needed to give them a kick in the pants. The same goes for other OSS projects. There's quite a few random OSS apps which were created on PG 7.4 and have never offered their users an upgrade path (Gnuworld comes to mind). They need an EOL announcement to get them motivated to upgrade. +1 -dg -- David Gould da...@sonic.net 510 536 1443510 282 0869 If simplicity worked, the world would be overrun with insects. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Simon, Why are we not even willing to ask whether someone is willing? It all seems very strange to me. Mostly because, I think, nobody can picture how this would be structured or where the people would come from. Surely a 7.4 maintainer would do only one platform? Or only source? Can we call 7.4 a maintained version if it's only patched for Debian? Also, given the other needs we have for technical skills, this would depend on finding people who were good enough to put out stable packages for 7.4, but wasn't interested in contributing to the project in any other way. If these people are available for other tasks, we'd *far* rather have them testing 8.5, reviewing code, updating drivers, writing docs, making tools, etc. So I don't think that anyone is opposed to your proposal, they just don't (or at least I don't) see a practical way to pursue it. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 1:32 PM, Josh Berkus j...@agliodbs.com wrote: Also, as Greg points out, 7.4 is just waiting for some exploit which is horribly hard to backpatch for us to desupport it on short notice, and that is NOT a service to our users. That is along the line of my concerns as well. Based on a quick look through my pgsql-bugs email, it seems that we don't get many bug reports for 7.4 or even 8.0. Mostly, the fixes that are being back-patched to 7.4 are problems that were found on (much) later releases and happened to go all the way back. We are supporting 7.4 to the extent that the 7.4 code overlaps with the 8.4 code (soon, the 8.5 code), but are we supporting the code in 7.4 that IS NO LONGER IN HEAD? I suspect we are to a point, but not really - and I don't believe that the removed code is bug-free any more than I believe that HEAD is bug-free. I don't really object to supporting 7.4 on the grounds that it is a lot of work. It obviously isn't, or the committers would have stopped doing it before now. I'm more concerned about the perception that the code is more supported than it really is. If we don't want to actually EOL 7.4, then perhaps we should decide for which releases we'd be willing to fix a major bug that affected only that release and for which we would not, and then publish that information so that users can make an informed decision. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Is a somewhat related question how long are the various commercial support organizations committed to supporting 7.4? I guess support companies might support their client's systems for longer or shorter times than the community patches the old versions. No doubt it's easier for them if the community does the backpatching. But if any of those companies has a lot of 7.4 clients, they might be tempted to deal with backpatches for their clients even after the community stops. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 2:24 PM, Greg Sabino Mullane g...@turnstep.com wrote: That will get some, but not others. What really makes people upgrade their database is when their database driver stops working against it. :) ROFL. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 The other Greg wrote: Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. I hope this is not the case, for sane definitions of readily. We have an implicit promise to support 7.4 until we state that we've stopped doing so. Stopping because a patch is hard seems a real crappy excuse. For the record, I'd like to see a year's notice. How about Dec. 1, 2010? February is completely not reasonable. Companies need a lot more time to make plans, get approval, test, etc. 2) Relatively few people are using it so perhaps the reason we haven't found any major bugs recently is because nobody's pushing it hard any more. Or maybe it's a relatively stable branch that people are happy with. As far as few people, where do you get that idea, except anecdotally? I can assure I know of a number of companies that are using it (and some using 7.3, but shame on them). These companies do not advertise their usage of Postgres, and their use of the database stays the same so no bugs are revealed, but they are out there. Josh writes: The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. That will get some, but not others. What really makes people upgrade their database is when their database driver stops working against it. :) - -- Greg Sabino Mullane g...@turnstep.com PGP Key: 0x14964AC8 200911031423 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iEYEAREDAAYFAkrwg4cACgkQvJuQZxSWSsipyQCfb3ZMEnscjrQzj02j/6eGFWdj 3csAoIGwgvA5Y/GfBV47FddjvpZfUGEg =RQOY -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. It's not handover of responsibility that's the issue, it's that dividing up existing responsibility entails more communication and synchronization overhead. If we have a separate set of people back-patching and releasing old branches, then every time we make a bug fix, we have to explain the patch to them; every time we have a release, we have to get their concurrence on release schedule. And we have to track whether patches that should be back-patched have been. The added overhead of all that would easily exceed the time savings of pushing off the responsibility, IMO. (As an example, it's already been determined among core and -packagers that there will be no 8.4.2 during November, because we can't get everyone's time to make a release this month. Putting even more people in the loop does NOT make that better. And they can't be out of the loop --- for instance, if it's a security update, 7.4.x had better come out at the same time as the other branches.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Nov 3, 2009, at 10:32 AM, Josh Berkus wrote: So I'm going to make a case in favor of EOL'ing 7.4. In fact, I'd be in favor of doing so in, say, February after an announcement this month +1 And, frankly, I think that we still need a published deprecation policy -- or at least a set of guidelines. That was my point in starting this discussion back in July. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 7:24 PM, Greg Sabino Mullane g...@turnstep.com wrote: Realistically we're going to EOL it as soon as the first major bug is found that *doesn't* back patch readily. There's relatively low cost to supporting it up until that bug is found, and apparently it hasn't been found it. I hope this is not the case, for sane definitions of readily. We have an implicit promise to support 7.4 until we state that we've stopped doing so. Stopping because a patch is hard seems a real crappy excuse. For the record, I'd like to see a year's notice. How about Dec. 1, 2010? February is completely not reasonable. Companies need a lot more time to make plans, get approval, test, etc. It seems like a fine excuse to me. I certainly don't feel i have any authority to tell Tom or Alvarro what to work on in their spare time. If you feel the urge to do it if Tom thinks it's too much work to be worthwhile then, well, more power to you, thanks. These companies are free to keep using the software with the known problems or pay someone to support it and do the pointless work fixing bugs in five-year-old versions if they want. It looks to me like our support policy and past success at back patching has engendered a false sense of security for users. *All* our support is best-effort and what I described is effectively our policy for all back branches. The only question is which branches, in our best judgement, we think we're likely to run into such a problem. It's not likely for 8.3 currently because we know there aren't very many major changes in 8.4 that fixed potential major design bugs. It's certainly likely for 7.4 at this point and really 8.0 and 8.1 wouldn't surprise me either. That doesn't mean we have to stop back patching to 7.4, 8.0, and 8.1 today. But if we think it's likely we'll run into some major bug which requires a redesign to fix then we should perhaps make some statement to that effect, call these back branches EOL today, and just release back branches on a best effort basis until that occurs. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Josh Berkus wrote: ...The main reason I'm in favor of this is that we have a lot of users using 7.4 out of inertia, and they need a message that 7.4 is not supported to get them to upgrade. I'm not entirely sure that inertia is the culprit. From what I've seen, since 7.4 is a good, stable release, checking/fixing everything required for an upgrade (casting, time-calculation changes, administrative procedures, perhaps switching from C to UTF8, client-deployment planning and so on) combined with risks of the unknown and 24x7 availability requirements makes the required expenditure a tough sell - especially in a lean and mean economy. I suspect 7.4 will remain in somewhat widespread use for quite some time after EOL. EOL _does_, however, give IT some powerful ammo to use to in persuading management to devote the required resources to an upgrade. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 10:49 -0800, Josh Berkus wrote: Why are we not even willing to ask whether someone is willing? It all seems very strange to me. Mostly because, I think, nobody can picture how this would be structured or where the people would come from. Surely a 7.4 maintainer would do only one platform? Or only source? Can we call 7.4 a maintained version if it's only patched for Debian? Only if you turn off the buildfarm for them. Also, given the other needs we have for technical skills, this would depend on finding people who were good enough to put out stable packages for 7.4, but wasn't interested in contributing to the project in any other way. If these people are available for other tasks, we'd *far* rather have them testing 8.5, reviewing code, updating drivers, writing docs, making tools, etc. These are currently hypothetical problems. Some people may care, if so, they can work out the problems. We might find some people that are willing to take on responsibility and grow into the role. We will probably end up with more new developers, not less. So I don't think that anyone is opposed to your proposal, they just don't (or at least I don't) see a practical way to pursue it. Why not ask for volunteers and let them work it out? Perhaps there are people not willing to receive the kick in the pants you advocate elsewhere. Ask people, let them decide. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, 2009-11-03 at 15:01 -0500, Tom Lane wrote: Simon Riggs si...@2ndquadrant.com writes: On Tue, 2009-11-03 at 12:29 -0500, Robert Haas wrote: You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. With respect to all the people you just mentioned, I don't see any reason why other people could not perform the duties you describe. Of course, it might require a little effort, as we might expect of any handover of responsibility. It's not handover of responsibility that's the issue, it's that dividing up existing responsibility entails more communication and synchronization overhead. If we have a separate set of people back-patching and releasing old branches, then every time we make a bug fix, we have to explain the patch to them; every time we have a release, we have to get their concurrence on release schedule. And we have to track whether patches that should be back-patched have been. The added overhead of all that would easily exceed the time savings of pushing off the responsibility, IMO. This is essentially the delegation isn't worth it argument. Which doesn't really wash because there clearly is delegation already. There was also a time when those people started and needed to work things out. I'd hold my hand up and say I love to do things myself rather than delegate, but I won't be arguing that makes sense ahead of knowing: if there is a delegatee at all, how they would want to operate, who they are and what they know. (As an example, it's already been determined among core and -packagers that there will be no 8.4.2 during November, because we can't get everyone's time to make a release this month. Putting even more people in the loop does NOT make that better. And they can't be out of the loop --- for instance, if it's a security update, 7.4.x had better come out at the same time as the other branches.) You're also presupposing that we would need to synchronize things in the way you say. It seems strange to be in a position where we either release everything in lock-step, or just jettison it completely. So we can have everything or nothing. All I'm saying is that some people may be willing to live with something rather than nothing. I might be wrong and nobody gives a damn, but as a project I feel we should at least check to see whether people care enough to act. Or maybe do it for the experience. Who knows without asking? -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
Robert Haas wrote: I'm not averse to EOL'ing 7.4, but I don't think it's fair to claim that we already stopped supporting it. Well, that would be overstating my position. We haven't stopped supporting it, but there's less and less stuff that applies that far back. I think it's better to draw a line in the sand and say we're going to stop supporting this release on this date rather than letting it go on and on and then waking up and realizing hmm, nothing ever applies that far back any more, I guess we don't support it. I think you are mis-diagnosing the reason not everything gets backpatched that far. It's not that we can't, it's that we don't always need to. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] EOL for 7.4?
On Tue, Nov 3, 2009 at 12:13 PM, Simon Riggs si...@2ndquadrant.com wrote: On Tue, 2009-11-03 at 16:37 +, Dave Page wrote: On Tue, Nov 3, 2009 at 4:29 PM, Simon Riggs si...@2ndquadrant.com wrote: Unless there are unfixable data loss bugs in it, I say we keep it. Many people still run it, so why make them move? There are non-trivial amounts of effort required to produce and test packages for each branch we maintain. That affects all of the packagers to varying degrees and should not be overlooked. This presumes a single group of packagers that does all releases. We'd be the only project that does that, AFAICS. Seems strange to limit tasks to just the same few people all the time. We could ask for volunteer maintainers for releases, rather than just say the X people that do all the work no longer wish to do it and so we're not going to let anyone else either. No volunteers, no releases. That is exactly how this current project got started in the first place - picking up the maintenance responsibility on code that the original authors no longer wished to maintain. As in all things, any major changes with respect to packages should be discussed publicly, with notice given of any changes. Anybody that feels it is worth supporting could then come forward to do so. I hope we can avoid a sarcastic over to you then Simon reply. I'm not volunteering for it, but we should give others the opportunity to do so. My belief is there is a substantial user community for 7.4, and for 7.3 also. There is no reason why we should act like a commercial company when we're a volunteer organisation. So suggestion: announce that 7.4 will be EOLd in 6 months unless volunteers come forward to support further releases. At the same time, announce what the EOL plans are for other releases, so people can begin planning upgrades. In most stable production systems the planning cycle can extend to years, rather than weeks or months. But the effort is distributed across multiple people working at different companies. There are many people involved in packaging PostgreSQL and we may not even know who all of them are, though we probably do know the major ones. Plus Peter updates translations, Marc stamps releases, Tom and others backpatch bug fixes, etc. You're not going to take all those little dribs and drabs of responsibility and transfer them to one person, or even one group of people. We certainly don't have to EOL 7.4. But neither can we maintain an infinite collection of back-branches forever. So we just need to decide whether it's time. If so, we pick a date and announce it. If not, we go on as we are and come back around to this topic in another six months. Personally, I think it would be reasonably to make the announcement that 7.4 will be EOL when 8.5 is released, but YMMV, BANI. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
