Thread: advocating LTS release and feature-train release cycles

advocating LTS release and feature-train release cycles

From
Zenaan Harkness
Date:
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


Re: advocating LTS release and feature-train release cycles

From
Arthur Silva
Date:


On Sun, May 31, 2015 at 6:44 AM, Zenaan Harkness <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)
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?

Re: advocating LTS release and feature-train release cycles

From
Adrian Klaver
Date:
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


Re: advocating LTS release and feature-train release cycles

From
Jan de Visser
Date:
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.



Re: advocating LTS release and feature-train release cycles

From
Zenaan Harkness
Date:
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


Re: advocating LTS release and feature-train release cycles

From
Tomas Vondra
Date:

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


Re: advocating LTS release and feature-train release cycles

From
Andrew Sullivan
Date:
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


Re: advocating LTS release and feature-train release cycles

From
Jan de Visser
Date:

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.

Re: advocating LTS release and feature-train release cycles

From
Adrian Klaver
Date:
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