9.5 feature count

On Sun, Jun 14, 2015 at 02:12:16PM -0400, Bruce Momjian wrote:

I have run a script to count the number of "<listitem>" items in the
major release notes of each major version of Postgres back to 7.4:

7.4 280
8.0 238
8.1 187
8.2 230
8.3 237
8.4 330
9.0 252
9.1 213
9.2 250
9.3 187
9.4 217
9.5 176

The 9.5 number will only change a little by 9.5 final.

FYI, all final releases have 5-10 listed major items which are repeats
of other items, so the final 9.5 count will be slightly higher.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

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

Bruce Momjian wrote:

I have run a script to count the number of "<listitem>" items in the
major release notes of each major version of Postgres back to 7.4:

7.4 280
8.0 238
8.1 187
8.2 230
8.3 237
8.4 330
9.0 252
9.1 213
9.2 250
9.3 187
9.4 217
9.5 176

The 9.5 number will only change a little by 9.5 final.

I think doing this kind of "analysis" can lead to bad incentives; should
we split two items that are unrelated but touch similarly-sounding parts
of the code, should we merge items that are actually pretty much the
same thing? It's either pointless, because people in-the-know actually
realizes that it doesn't actually mean anything, or confusing because
people think that some releases are bigger than others because they have
"more features".

Maybe there's a reasonable way to measure releases (my 8.0 is bigger
than your 9.1!), but I don't think this is it.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

On Fri, Jun 26, 2015 at 11:09 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Maybe there's a reasonable way to measure releases (my 8.0 is bigger
than your 9.1!), but I don't think this is it.

I agree with the sentiment, but I don't think that anyone actually
thinks of it that way. Most people tend to think of a release in terms
of the big, exciting features, or the smaller features that happened
to scratch their particular itch.

--
Peter Geoghegan

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

On Fri, Jun 26, 2015 at 11:13:19AM -0700, Peter Geoghegan wrote:

On Fri, Jun 26, 2015 at 11:09 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Maybe there's a reasonable way to measure releases (my 8.0 is bigger
than your 9.1!), but I don't think this is it.

I agree with the sentiment, but I don't think that anyone actually
thinks of it that way. Most people tend to think of a release in terms
of the big, exciting features, or the smaller features that happened
to scratch their particular itch.

I agree. I think the count tells us how focused we are in working on a
few big things or many small things, e.g. when we don't have many big
features in a major release, the count tends to be high as we clean up
previously-released big features.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

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

On 27 August 2015 at 23:20, Bruce Momjian <bruce@momjian.us> wrote:

On Fri, Jun 26, 2015 at 11:13:19AM -0700, Peter Geoghegan wrote:

On Fri, Jun 26, 2015 at 11:09 AM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:

Maybe there's a reasonable way to measure releases (my 8.0 is bigger
than your 9.1!), but I don't think this is it.

I agree with the sentiment, but I don't think that anyone actually
thinks of it that way. Most people tend to think of a release in terms
of the big, exciting features, or the smaller features that happened
to scratch their particular itch.

I agree. I think the count tells us how focused we are in working on a
few big things or many small things, e.g. when we don't have many big
features in a major release, the count tends to be high as we clean up
previously-released big features.

Anything where Hot Standby == {one line changes in default settings} has
been distilled too far to draw any meaningful conclusions. They simply
reflect the editing style in use at that time, which has changed over time.

--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/&gt;
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services