Thread: advocating LTS release and feature-train release cycles
My comments advocating a (ubuntu/debian/linux-kernel/firefox) LTS release and feature-train release cycle: https://lwn.net/Articles/646740/ https://lwn.net/Articles/646743/ The parent article "PostgreSQL: the good, the bad, and the ugly": https://lwn.net/Articles/645020/ My summary (from one of my comments above): "For PostgreSQL may be: - normal release every 3 or 4 months - LTS release every 12, 18 or 24 months This model provides: - higher frequency normal releases to a) showcase new features to the public and b) reduce pressure on developers wanting to not miss an "infrequent annual" release; and - lower frequency LTS releases to a) focus testing, stability and long term support resources b) satisfy "conservative/ enterprise" RDBMS admins " Regards, Zenaan
My comments advocating a (ubuntu/debian/linux-kernel/firefox) LTS
release and feature-train release cycle:
https://lwn.net/Articles/646740/
https://lwn.net/Articles/646743/
The parent article "PostgreSQL: the good, the bad, and the ugly":
https://lwn.net/Articles/645020/
My summary (from one of my comments above):
"For PostgreSQL may be:
- normal release every 3 or 4 months
- LTS release every 12, 18 or 24 months
This model provides:
- higher frequency normal releases to
a) showcase new features to the public and
b) reduce pressure on developers wanting to not miss an "infrequent
annual" release; and
- lower frequency LTS releases to
a) focus testing, stability and long term support resources
b) satisfy "conservative/ enterprise" RDBMS admins
"
Regards,
Zenaan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I'm surprised it got no replies so far.
In my opinion a twice a year schedule would be good.
The LTS would be every 2 or 4 releases. Keeping 2 LTS versions supported at all moments.
Maybe this should be reposted to the hackers list?
On 06/01/2015 07:11 PM, Arthur Silva wrote: > > > On Sun, May 31, 2015 at 6:44 AM, Zenaan Harkness <zen@freedbms.net > <mailto:zen@freedbms.net>> wrote: > > My comments advocating a (ubuntu/debian/linux-kernel/firefox) LTS > release and feature-train release cycle: > https://lwn.net/Articles/646740/ > https://lwn.net/Articles/646743/ > > The parent article "PostgreSQL: the good, the bad, and the ugly": > https://lwn.net/Articles/645020/ > > My summary (from one of my comments above): > "For PostgreSQL may be: > - normal release every 3 or 4 months > - LTS release every 12, 18 or 24 months > > This model provides: > - higher frequency normal releases to > a) showcase new features to the public and > b) reduce pressure on developers wanting to not miss an "infrequent > annual" release; and > > - lower frequency LTS releases to > a) focus testing, stability and long term support resources > b) satisfy "conservative/ enterprise" RDBMS admins > " > > Regards, > Zenaan > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org > <mailto:pgsql-general@postgresql.org>) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > > > > I'm surprised it got no replies so far. > > In my opinion a twice a year schedule would be good. > The LTS would be every 2 or 4 releases. Keeping 2 LTS versions supported > at all moments. In my opinion, FWIW, that really does not change anything. Whether you are dealing with 20 new features over a year or 10 over half a year the same constraints apply, writing the code and getting it reviewed over a given time period. Add in the extra overhead costs of more frequent releases and I see no gain. > > Maybe this should be reposted to the hackers list? -- Adrian Klaver adrian.klaver@aklaver.com
On June 1, 2015 11:11:37 PM Arthur Silva wrote: > In my opinion a twice a year schedule would be good. > The LTS would be every 2 or 4 releases. Keeping 2 LTS versions supported at > all moments. > > Maybe this should be reposted to the hackers list? Pretty sure this would be shot down pretty quick. At this point it seems more likely to me that the time between releases will be longer rather than shorter.
On 6/2/15, Jan de Visser <jan@de-visser.net> wrote: > On June 1, 2015 11:11:37 PM Arthur Silva wrote: >> In my opinion a twice a year schedule would be good. >> The LTS would be every 2 or 4 releases. Keeping 2 LTS versions supported >> at >> all moments. >> >> Maybe this should be reposted to the hackers list? > > Pretty sure this would be shot down pretty quick. At this point it seems > more > likely to me that the time between releases will be longer rather than > shorter. Really, that sounds like an excellent way to test such an alternative - if pg development went to what every other major libre project does, we would not have a proper comparison of the outcome for the alternative (lengthening the release cycle, rather than shortening). I know how I think it'll pan out - but personal opions matter little here, only what the dev's choose. Whatever the outcome, this will be a great experiment in the long run, providing a data point we would be quite unlikely to have otherwise! Regards, Zenaan
On 06/02/15 04:27, Adrian Klaver wrote: > On 06/01/2015 07:11 PM, Arthur Silva wrote: > > In my opinion, FWIW, that really does not change anything. Whether > you are dealing with 20 new features over a year or 10 over half a > year the same constraints apply, writing the code and getting it > reviewed over a given time period. Add in the extra overhead costs of > more frequent releases and I see no gain. I disagree. The fact that we have 1 release per year means there's one deadline, and if you miss it you have to wait another year for the feature to be available in official release. That's a lot of pressure and frustration for developers. With more frequent releases, this issue gets less serious. Of course, it's not a silver bullet (e.g. does not change review capacity). >> Maybe this should be reposted to the hackers list? Yes. And there already are threads dealing with this topic. -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Tue, Jun 02, 2015 at 12:59:14PM +0200, Tomas Vondra wrote: > I disagree. The fact that we have 1 release per year means there's one > deadline, and if you miss it you have to wait another year for the feature > to be available in official release. That's a lot of pressure and > frustration for developers. With more frequent releases, this issue gets > less serious. Of course, it's not a silver bullet (e.g. does not change > review capacity). But it's the second part of this that is the main issue. For the people who are driving features in postgres now are overwhelmingly the most advanced users, who also want rock solid database reliability. After all, the simple use cases (the ones that basically treat the DBMS as an expensive version of a flat filesystem) have been solved for many releases quite well in Postgres. These are the cases that people used to compare with MySQL, and MySQL isn't any better at them any more than Postgres. But Postgres isn't really any better at them than MySQL, either, because the basic development model along those lines is low sophistication and is automatically constrained by round tripping between the application and the database. Anyone who wants to scale for real understands that and has already figured out the abstractions they need. But those are also the people with real data at stake, which is why they picked Postgres as opposed to some eventually-consistent mostly-doesn't-lose-data distributed NoSQL system. The traditional Postgres promise that it never loses your data is important to all those people too. Yet they're pressing for hot new features because it's the nifty database tricks you can do that allow you to continue to build ever-larger database systems. If the model switched to more frequent "feature releases" with less frequent "LTS" releases for stability, one of two things would happen: 1. There'd be pressure to get certain high-value features into the LTS releases. This is in effect the exact issue there is now. 2. The people who really need high quality and advanced features would all track the latest release anyway, because their risk tolerance is actually higher than they think (or more likely, they're doing the risk calculations wrong). The effect of this would be to put pressure on the intermediate releases for higher quality, which would result in neglect of the quality issues of the LTS anyway. And on top of the above, you'd split the developer community between those working on LTS and those not. Given that the basic problem is "not enough developers to get the quality quite right against the desired features", I don't really see how it helps. As nearly as I can tell, noting that I'm watching almost entirely from the sidelines, what really happened in the case that has everyone worried is that one highly-esteemed developer claimed something and maybe should have relinquished sooner given his workload. That happens; nobody's perfect. It's frustrating, but this is not the only community to have had that issue (cf. Linux kernel, for an approximately infinite series of examples of this). I am not sure that the answer to this is a rejigging of the basic development model. Hard cases make bad law. Best regards, A -- Andrew Sullivan ajs@crankycanuck.ca
On June 2, 2015 03:16:53 PM Zenaan Harkness wrote:
> On 6/2/15, Jan de Visser <jan@de-visser.net> wrote:
> > On June 1, 2015 11:11:37 PM Arthur Silva wrote:
> >> In my opinion a twice a year schedule would be good.
> >> The LTS would be every 2 or 4 releases. Keeping 2 LTS versions supported
> >> at
> >> all moments.
> >>
> >> Maybe this should be reposted to the hackers list?
> >
> > Pretty sure this would be shot down pretty quick. At this point it seems
> > more
> > likely to me that the time between releases will be longer rather than
> > shorter.
>
> Really, that sounds like an excellent way to test such an alternative
> - if pg development went to what every other major libre project does,
> we would not have a proper comparison of the outcome for the
> alternative (lengthening the release cycle, rather than shortening).
>
> I know how I think it'll pan out - but personal opions matter little
> here, only what the dev's choose.
>
> Whatever the outcome, this will be a great experiment in the long run,
> providing a data point we would be quite unlikely to have otherwise!
I was overly short. What I should have done is direct you to pgsql-hackers where release schedules have been extensively discussed recently. Reading those threads will give you an idea about what the thinking process of the people responsible for releasing pgsql is. And whether or not their thinking lines up with other projects is not really relevant in my opinion - all projects are different, not in the least because the people running them are different.
On 06/02/2015 03:59 AM, Tomas Vondra wrote: > > > On 06/02/15 04:27, Adrian Klaver wrote: >> On 06/01/2015 07:11 PM, Arthur Silva wrote: >> >> In my opinion, FWIW, that really does not change anything. Whether >> you are dealing with 20 new features over a year or 10 over half a >> year the same constraints apply, writing the code and getting it >> reviewed over a given time period. Add in the extra overhead costs of >> more frequent releases and I see no gain. > > I disagree. The fact that we have 1 release per year means there's one > deadline, and if you miss it you have to wait another year for the > feature to be available in official release. That's a lot of pressure > and frustration for developers. With more frequent releases, this issue > gets less serious. Of course, it's not a silver bullet (e.g. does not > change review capacity). That is the fundamental issue, wants versus resources to fulfill the wants. That issue remains regardless of the release cycle. The solution lies in either restricting the wants, increasing the resources(more developers, reviewers) or a some combination thereof. > >>> Maybe this should be reposted to the hackers list? > > Yes. And there already are threads dealing with this topic. > > -- > Tomas Vondra http://www.2ndQuadrant.com > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services > > -- Adrian Klaver adrian.klaver@aklaver.com