Re: [HACKERS] Time-based Releases WAS: 8.5 release timetable, again
On Sat, Aug 29, 2009 at 12:19 AM, Josh Berkusj...@agliodbs.com wrote: I'd think the advantages for our commercial adopters (who pay the salaries for many of the people on this list) would be obvious; if they know with a small margin of error when the next version of PostgreSQL is coming out, they can plan testing and deployment of their new products. See Kevin's post; many companies need to schedule serious testing hardware months in advance, and every ISV needs to plan new product deployments up to a year in advance. We bitch a lot in the community about the super-old versions of PG which commercial software is using, but our variable release cycle is partly to blame. It also works on the other end - with time based releases you can also schedule obsolescence. It is just as critical knowing when the community will stop bug fixes and security fixes when you are trying to schedule major rollouts and planning product development. Canonical (my employer) certainly believe in time based releases, and that is one of the major reasons for the growth of Ubuntu and the Ubuntu Community. We now use time based releases for almost all our sponsored projects (some 6 monthly, some monthly), and are lobbying various projects and other OS distributions to get into some sort of cadence with releases so everyone benefits. It makes us happier (especially when we are choosing what we can commit to providing security updates for the 5 year releases), and our users happier, and I think you happier with less support issues. (In fact the one project I'm personally aware of that doesn't have time based releases also has the worst reputation for bug fixes and updates and caused us trauma because of it, so I'll be pushing to get that fixed too :-P) Certainly our project experiences with waiting for feature X have all been negative. The windows port never got into 7.4 despite holding it up 4 months. HOT held up 8.3 for three to five months, depending on how you count it, in what I think everyone feels was our most painful beta period ever. Most recently, we let HS/SR hold up 8.4 for 2 months ... and they still weren't ready. I would like to see us go to an annual release timeline in which we release in the same month every year. Any time we say variable release date what it really means is later release date. We've never yet released something *early*. Yes please. You may even want to seriously consider shorter release cycles. Tighter cycles can actually reduce stress, as people are less concerned with slippage. With our projects on one month cycles, it doesn't matter that much if a feature isn't good enough for a release - it just goes out with the next months release or the one after if you really underestimated the work. With longer cycles, the penalties of missing deadlines is much greater which can lead to cutting corners if people are not disciplined. Of course, PG already has its own historical cadence to start from where as we had the luxury of adopting time based releases at the start or relatively early in development. For PostgreSQL, with the regular commit fests you might end up to a similar process to GNU Bazaar except with yearly major releases and 2 month development releases, documented at http://doc.bazaar-vcs.org/latest/developers/cycle.html. This is a smaller project, but had to address a number of similar concerns that PostgreSQL would have to so may be a good basis for discussion. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ -- 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] Time-based Releases WAS: 8.5 release timetable, again
Stuart Bishop wrote: Canonical (my employer) certainly believe in time based releases, and that is one of the major reasons for the growth of Ubuntu and the Ubuntu Community. We now use time based releases for almost all our sponsored projects (some 6 monthly, some monthly), and are lobbying various projects and other OS distributions to get into some sort of cadence with releases so everyone benefits. It makes us happier (especially when we are choosing what we can commit to providing security updates for the 5 year releases), and our users happier, and I think you happier with less support issues. The release cycle is quite independent of the release lifetime. In any case, I don't accept this analogy. The mechanics of a Linux distribution are very different from the mechanics of a project like PostgreSQL. The prominent OSS project that seems to me most like ours is the Apache HTTP project. But they don't do timed releases AFAIK, and theirs is arguably the most successful OSS project ever. I'm especially resistant to suggestions that we should in some way coordinate our releases with other projects' timings. Getting our own developers organized is sufficiently like herding cats that I have no confidence that anyone will successfully organize those of a plethora of projects. I am not saying timed releases are necessarily bad. But many of the arguments that have been put forward to support them don't seem to me to withstand critical analysis. I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. 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] Time-based Releases WAS: 8.5 release timetable, again
Andrew Dunstan and...@dunslane.net writes: I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. I would agree with you, except that every single time we have done that, it's led to a scheduling disaster: the release was invariably far later than anyone expected, and more often than not shipped without the critical feature anyhow. Review the archives. 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] Time-based Releases WAS: 8.5 release timetable, again
On Tue, Sep 8, 2009 at 7:54 PM, Andrew Dunstanand...@dunslane.net wrote: The release cycle is quite independent of the release lifetime. If you have dates on releases, it is easier to set dates on release lifetime. If you know the releases come out once a year at about the same time, and you want to have a set number of versions in play, you can state at release time when the community will stop support. This gives everyone a clear picture to people what versions they should be targeting and when upgrades will be required. In any case, I don't accept this analogy. The mechanics of a Linux distribution are very different from the mechanics of a project like PostgreSQL. The prominent OSS project that seems to me most like ours is the Apache HTTP project. But they don't do timed releases AFAIK, and theirs is arguably the most successful OSS project ever. We find it works for stuff other than Ubuntu too. IIRC original concerns where you could do it for a small open source project, but it would be impossible to do when juggling as many moving parts as a Linux distribution. You might find the document I cited is for a project with similar issues to PostgreSQL and may address your concerns. It seems to work for other large projects too, such as Gnome, as well as smaller ones. People are discussing switching for reasons Joshua cited (maintaining momentum, planning, enterprise adoption etc.), because people find it a good idea on other projects they work with, or maybe because they read too many articles on agile and lean development practices. It seems to be working fine for me personally (I work on launchpad.net, which is an Open Source mostly-web application using generally Lean/Agile development methodologies, a one month release cycle and a team of about 30 spread over all timezones). I'm especially resistant to suggestions that we should in some way coordinate our releases with other projects' timings. Getting our own developers organized is sufficiently like herding cats that I have no confidence that anyone will successfully organize those of a plethora of projects. I tend to think it will evolve naturally as more people switch to time based releases. Its natural to sync in with the OS releases your developers care about because it makes their lives easier, and its natural for the distributions to get in sync too because it makes their developer's lives easier. But only hindsight will tell of course :-) With a yearly schedule, it probably doesn't matter much except for distributions with a 2 or 3 year cycle - you would still end up with latest PostgreSQL a maximum of I think 8 months after the official release. I am not saying timed releases are necessarily bad. But many of the arguments that have been put forward to support them don't seem to me to withstand critical analysis. I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. This is why you want your cycle as small as possible - if you have a 6 month cycle for instance, the feature would be available a maximum of 6 months after it is ready. With the feature based release cycle, what if it still isn't ready for prime time after three months of slippage? Having one feature slip hurts, but having all features slip hurts more. Josh cited several examples where he felt similar situations had hurt PostgreSQL development. Of course, if you think it is critical enough you can let it slip and if it is critical enough people will understand - we let one of the 10 Ubuntu releases slip once and people generally understood (you want to get a LTS release right since you have to live with your mistakes for 5 years). There was some flak but we are still here. I personally suspect PostgreSQL would want a 1 year cycle for major releases while a full dump/reload is required for upgrades. When this changes, 6 or even 4 months might actually be a good fit. -- Stuart Bishop stu...@stuartbishop.net http://www.stuartbishop.net/ -- 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] Time-based Releases WAS: 8.5 release timetable, again
I personally suspect PostgreSQL would want a 1 year cycle for major releases while a full dump/reload is required for upgrades. When this changes, 6 or even 4 months might actually be a good fit. For some DBA specialist is 1 year cycle too much fast. I thing, so 1 year cycle is perfect for databases. Migration to new database releases is some different then migration to new program. You have to be more carefully, because wrong database could to destroy your data. Normal use case for using a new version contains one year waiting. I afraid so too much short cycle can break clean postgresql's release process. regards Pavel Stehule -- 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] Time-based Releases WAS: 8.5 release timetable, again
In any case, I don't accept this analogy. The mechanics of a Linux distribution are very different from the mechanics of a project like PostgreSQL. The prominent OSS project that seems to me most like ours is the Apache HTTP project. But they don't do timed releases AFAIK, and theirs is arguably the most successful OSS project ever. I can't find information about HTTPD release planning so I'll take your word for it. On the other hand, I have to point out that Apache is releasing HTTPD major versions an average of once every 3 years. I don't think we want to go to 3 years, do we? I'm especially resistant to suggestions that we should in some way coordinate our releases with other projects' timings. Agreed, that's impossible. I'd prefer just to time things so that we're not trying to do committer-critical tasks during high summer vacation season. I am not saying timed releases are necessarily bad. But many of the arguments that have been put forward to support them don't seem to me to withstand critical analysis. There are several reasons to have a timed release schedule, which are detailed in the paper I linked. The benefits of having timed releases are for our contributors and for our users. I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. Historically, any feature which hasn't been ready for the originally planned release date needed far more than an extra month to be ready -- up to an additional year. HOT is the only exception I can think of to this in our 13-year history. I agree that HS is critical to adoption of PostgreSQL. However, the way to make it succeed is to have deadlines and meet them. Not work on it until it's ready. I personally suspect PostgreSQL would want a 1 year cycle for major releases while a full dump/reload is required for upgrades. When this changes, 6 or even 4 months might actually be a good fit. For some DBA specialist is 1 year cycle too much fast. I thing, so 1 year cycle is perfect for databases. Migration to new database Pavel is right. Upgrade-in-place will become easier, but it will never become painless. So DBAs will always want to put off upgrades to once in 2-3 years. If we went to releases ever 6 months, that would mean users skipping 5 versions. Also, we backpatch fixes a lot more than Ubuntu does AFAIK. So we'd still have to patch back 5 years, which would be 10 versions ... I don't think so. Once/year is the right length for us. It's 2x to 3x faster than any other mission-critical DBMS. -- Josh Berkus PostgreSQL Experts Inc. 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] Time-based Releases WAS: 8.5 release timetable, again
Andrew Dunstan wrote: In any case, I don't accept this analogy. The mechanics of a Linux distribution are very different from the mechanics of a project like PostgreSQL. The prominent OSS project that seems to me most like ours is the Apache HTTP project. I'd think that File Systems might be more like postgres - with a shared obsession about data loss risks, and concerns about compatibility with any on-disk format changes. I wonder if the ext4 or btrfs guys use time-based release schedules, or if they'll release when it's ready. I see the ZFS guys have target dates for completing features that are still in beta, but also that they change as needed.[1] [1] http://opensolaris.org/os/project/zfs-crypto/ Anyone know how the F/OSS filesystem guys schedule their releases? I agree it's quite different than a distro - which, if I understand correctly, is mostly a matter of identifying completed and stable features rather than completing and stabilizing features. I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. Perhaps if sufficiently interesting features get in outside of a time-based schedule, an extra release could be made after the commit fest it gets in? If hot-standby + streaming-replication + index_only_scans + magic-fairy-dust-powered-shared-nothing-clusters all happened to get in 3 months after a time-based release, it'd be nice to see it sooner rather than waiting 9 months for a time-based window. -- 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] Time-based Releases WAS: 8.5 release timetable, again
Josh Berkus wrote: I can't find information about HTTPD release planning so I'll take your word for it. On the other hand, I have to point out that Apache is releasing HTTPD major versions an average of once every 3 years. I don't think we want to go to 3 years, do we? I'd say it depends on the flexibility of some hypothetical future module layer. If I understand right, much of the functionality in apache comes from modules - and those modules that are under heavy development may have different release cycles. I realize this doesn't work for many of the big features; but some of those seem to have over 1 year development cycles anyway. -- 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] Time-based Releases WAS: 8.5 release timetable, again
On Tue, Sep 8, 2009 at 2:06 PM, Ron Mayerrm...@cheapcomplexdevices.com wrote: Andrew Dunstan wrote: In any case, I don't accept this analogy. The mechanics of a Linux distribution are very different from the mechanics of a project like PostgreSQL. The prominent OSS project that seems to me most like ours is the Apache HTTP project. I'd think that File Systems might be more like postgres - with a shared obsession about data loss risks, and concerns about compatibility with any on-disk format changes. I wonder if the ext4 or btrfs guys use time-based release schedules, or if they'll release when it's ready. I see the ZFS guys have target dates for completing features that are still in beta, but also that they change as needed.[1] [1] http://opensolaris.org/os/project/zfs-crypto/ Anyone know how the F/OSS filesystem guys schedule their releases? I agree it's quite different than a distro - which, if I understand correctly, is mostly a matter of identifying completed and stable features rather than completing and stabilizing features. I would argue that it would be an major setback for us if we made another release without having Hot Standby or whatever we are calling it now. I would much rather slip one month or three than ship without it. Perhaps if sufficiently interesting features get in outside of a time-based schedule, an extra release could be made after the commit fest it gets in? If hot-standby + streaming-replication + index_only_scans + magic-fairy-dust-powered-shared-nothing-clusters all happened to get in 3 months after a time-based release, it'd be nice to see it sooner rather than waiting 9 months for a time-based window. That's somewhat true, but major patches are also more likely to come with bugs. I think we ought to try to time major patches near the beginning of the release cycle, not the end. Indeed, I'd be much more inclined to support a proposal to branch the tree and do an out-of-sequence release just BEFORE committing a bunch of major features rather than just after. Otherwise, PostgreSQL's reputation for being a solid product with solid releases will suffer. ...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] Time-based Releases WAS: 8.5 release timetable, again
All, There's some very good reasons for the health of the project to have specific release dates and stick to them. Help me understand why? We've cited this before, but here's the definitive paper on the subject: http://www.cyrius.com/publications/michlmayr-phd.pdf summary here: http://robertogaloppini.net/2007/04/02/open-source-production-time-based-release-management/ Further evidence since then with Debian, Parrot, and several other projects which have moved from feature-based releases to time-based releases is that each release had just as many features despite the more rigid time, and that contributors and users were far better able to organize their lives around a defined schedule. Thus, each person was able to contribute more because they knew exactly when they had to do it. I don't know about you, but I personally work better when I have an actual deadline. I'd think the advantages for our commercial adopters (who pay the salaries for many of the people on this list) would be obvious; if they know with a small margin of error when the next version of PostgreSQL is coming out, they can plan testing and deployment of their new products. See Kevin's post; many companies need to schedule serious testing hardware months in advance, and every ISV needs to plan new product deployments up to a year in advance. We bitch a lot in the community about the super-old versions of PG which commercial software is using, but our variable release cycle is partly to blame. For our contributors, it's a lot harder to get funding to do paid contract work on features if you can't tell your sponsor when the next release is coming out. The alternative? 100% of the evidence I've seen is that feature-based release cycles get progressively longer as the project gets bigger. Eventually you find yourself only doing a release every 3.5 years, like MySQL or Debian used to. And your developers start leaving because they never see the fruits of their contributions, and your users start leaving because there's never anything new. Certainly our project experiences with waiting for feature X have all been negative. The windows port never got into 7.4 despite holding it up 4 months. HOT held up 8.3 for three to five months, depending on how you count it, in what I think everyone feels was our most painful beta period ever. Most recently, we let HS/SR hold up 8.4 for 2 months ... and they still weren't ready. I would like to see us go to an annual release timeline in which we release in the same month every year. Any time we say variable release date what it really means is later release date. We've never yet released something *early*. -- Josh Berkus PostgreSQL Experts Inc. 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
