Re: Request MRE approval for PostgreSQL

2024-01-23 Thread Christopher James Halse Rogers



On Thu, Jan 18 2024 at 11:21:18 -0500, Sergio Durigan Junior 
 wrote:

On Thursday, January 18 2024, Christopher James Halse Rogers wrote:


 On Wed, Jan 17 2024 at 21:09:58 -0500, Sergio Durigan Junior
  wrote:
 On Wednesday, January 17 2024, Christopher James Halse Rogers 
wrote:



  Hi there!

 Hey, Chris,
 Thanks for the review.


  On Sat, Jan 13 2024 at 00:08:35 -0500, Sergio Durigan Junior
   wrote:

  Hello,
  In the same spirit as Christian's formal request for an SRU
  exception
  for open-vm-tools, Athos and I would like to formally request 
the

  approval of the PostgreSQL MRE wiki page.
  We (the Server team) have been doing such MREs for a number of
 years
  now, but it came to our attention recently that we don't 
actually

 have
  the MRE policy for PostgreSQL formally defined in a wiki page, 
as

 is
  usual for more recent packages.
  I don't know much about the history behind why such page doesn't
  exist,
  but we would like to fix it by proposing the following document:
https://wiki.ubuntu.com/PostgreSQLUpdates

  It looks like a good documentation of current practice, and
 current
  practice looks (mostly) good.
  A couple of questions:
  * Checking the PostgreSQL policy, they say that a pg_dump/restore
cycle between minor updates is *normally* not needed. Has it
 *ever*
been needed in the past? Presumably we would not take such an
 update
(at least, not under this MRE)?
 Athos and I have been doing this MRE for a bit more than a year 
now,

 and
 so far we have never seen a situation where a pg_dump/restore cycle
 was
 needed.  I'm Cc'ing Christian, who used to handle the MREs before
 us, in
 case he knows something more.


  * I notice a number of the updates are of the form “Fix FROB
 index. If
you have any FROB indexes, you must run FROBINATE REINDEX to 
get

 the
fixes”. How do we notify users of this? It's in the 
changelog,

 which
is not nothing, and a debconf notice would be *way* too
disruptive. Is there anywhere else we should be pushing such
 “you
really should check this” notifications?

 That's a good question.  My default answer for such scenarios tends
 to
 be "let's put it in a d/NEWS file", but I appreciate the fact that 
not

 everybody will have apt-listchanges installed.  Nonetheless, maybe
 that's a good compromise between having the entries buried in the
 changelog vs. having a debconf notice.  WDYT?


 Ooooh, yes. d/NEWS would definitely be an improvement!


Cool.

Just to clarify: does this mean that this request is approved pending
the d/NEWS addition to the wiki page?


I'd like an answer to the other question before approving - what 
happens if a pg_dump/pg_restore cycle *is* required across a minor 
update. Presumably the answer is “that update will not fall under 
this MRE”, but we should document both that decision and how we 
expect to pick up when this would apply.


Once that has a satisfactory answer, yes, it looks good to approve to 
me.


Cheers,
Chris



--
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release


New component-mismatches for source universe -> main

2024-01-23 Thread process-component-mismatches-diff
The following universe packages have new reverse dependencies
in main or got seeded. They need to get a MainInclusionReport and be
promoted, or the reverse dependencies in main need to be dropped:

MIR: #2048760 (Confirmed for Ubuntu Security Team) [MIR] python-cssselect

Please see https://ubuntu-archive-team.ubuntu.com/component-mismatches.txt
for the full report.

Please contact https://launchpad.net/~ubuntu-archive for problems with this
notification.

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release


Transition entanglement: delay glibc upload?

2024-01-23 Thread Simon Chopin
Hi Release Team,

It seems we have a few big transitions either in progress (perl,
python) or about to start in the coming weeks (php, armhf 64bit time_t).
My original plans for glibc would add fuel to that fire, as I projected
to upload it to -proposed in about 2 weeks.

A possible way to reduce the friction introduced by a new glibc verison
would be to delay it until after Feature Freeze: fewer packages would
pick up the new symbols and thus wouldn't get blocked waiting for the
glibc rdeps autopkgtests to clear.

I can see a couple of downsides to that approach:

* Fewer packages would pick the new ABIs, which presumably bring in some
  sort of improvement in one form or another.
* The newer glibc would be tested for less time, although presumably
  that's somewhat offset by it taking less time to reach the release
  pocket from -proposed.

WDYT?

Cheers,
Simon

-- 
Ubuntu-release mailing list
Ubuntu-release@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-release