Date: Tue, 21 Apr 2026 16:18:40 -0400
From: Bruce Momjian <bruce@momjian.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, David Geier <geidav.pg@gmail.com>,
	PostgreSQL-development <pgsql-hackers@lists.postgresql.org>
Subject: Re: First draft of PG 19 release notes
Message-ID: <aefboPsBA2NC_6e-@momjian.us>
References: <3407474c-9154-43b8-bff3-0cb3ebe53934@gmail.com>
 <aeTZfV96OtDUO923@momjian.us>
 <neyhppguim77qlq5h7hzchfsbgisipp7jxahztc3ekq3ev56l7@wj365ie267sq>
 <aeUWhHp2R_VO2zo-@momjian.us>
 <zdlyd6k6tto55tgn26wp5oeytmeipihn2ika4olm43kdgpxkhr@lsfb4zgo4oxq>
 <aeUgyfc4xKpXvxwT@momjian.us>
 <cueuimvdjht6pmpcsctwkx7f7tyha7qfuspuvhdpbkpmzclgcl@ly4ezmrcqp6i>
 <CAApHDvrZnPbbEr-PsNK1semY+rJKDGM2SS7MYNtta8a3Vb7Uzg@mail.gmail.com>
 <aeXtnlCj5_7SGroL@momjian.us>
 <CAApHDvoms82wjymG3KvHVRfYi68PXzYXRm-bR0tHgnATB+a4sQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAApHDvoms82wjymG3KvHVRfYi68PXzYXRm-bR0tHgnATB+a4sQ@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/aefboPsBA2NC_6e-%40momjian.us>
Precedence: bulk

On Mon, Apr 20, 2026 at 10:40:13PM +1200, David Rowley wrote:
> > I can't follow rules that require me to consistently identify if a patch
> > is a performance improvement, and if it is significant enough for the
> > release notes.  If someone else can do that, please go ahead and stop
> > blaming me for something I can't do.  I thought if it was easy, someone
> > else since PG 17 would have either given me rules or done it.
> 
> I don't think anyone expects you to do anything that makes this job
> harder than it already.  I expect a careful process change could make
> this job easier for you.
> 
> > Can committers mention when they want something to be included in the
> > release notes?  What we can do is to have all the hackers point out the
> > missing items after I done creating the release notes, as messy as that
> > is.
> 
> I wondered if the job could be made easier if we were to tag fixup
> commits for commits that fix some recent feature commit. You could
> pretty much ignore every single one of those for the release notes. If
> that fixup information was more structured, it might also be very
> interesting.
> 
> > One thing we can easily do is to add text to the release notes stating,
> > "This release includes minor performance improvements that are too
> > numerous to mention."
> 
> If the WIP draft contained the items of lesser importance, we might be
> able to do some aggregation of those into something meaningful enough.
> It might be much easier for people closer to the particular items to
> aggregate them than it is for a single person to do it for all
> commits. I'm aware that you already do quite a bit of this aggregation
> already.

I had some more time to think about the items you list above.  My first
reaction was that it wasn't workable, but I then realized it is not
workable because you can't do this level of analysis once the release
note items are written.  This idea of aggregating items and getting
people to choose items makes a lot of sense if we are using a list of
commits with git commit text that were not included already.

Let me work on creating such a list and we will see how it goes.  I am
traveling now so it will be delayed.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.