advocating LTS release and feature-train release cycles

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?

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

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

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general