New component-mismatches for source universe -> main

2024-01-18 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:

  o golang-1.20: golang-1.20-doc
[Reverse-Depends: Rescued from golang-1.20]
 

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


Re: Lubuntu LTS Requalification: 24.04 Noble Numbat

2024-01-18 Thread Alex Murray
On Thu, 2024-01-18 at 19:18:23 +, Simon Quigley wrote:

>
>>> The contacts are Simon, Dan and myself (Aaron), and Thomas, in that order.
>> 
>>> Simon therefore is the primary contact as he is the Lubuntu Release
>>> Manager, me and Dan are secondary contacts, and Thomas is the "if all else 
>>> fails"
>>> fallback by virtue of him being Team Lead.
>> 
>> Thanks.  With that clarification, I am +1 for the 3-year Lubuntu 24.04 LTS.
>
> Thanks, Steve! As always, I appreciate that you're willing to ask the 
> tough questions.
>

+1 from me too now this detail has been explicitly stated.

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


Re: Lubuntu LTS Requalification: 24.04 Noble Numbat

2024-01-18 Thread Simon Quigley
Hello,

I do appreciate the responses from my Lubuntu colleagues on this topic. 
That being said, Steve addressed me, so I at least owe him an 
acknowledgement. I will also address some common questions we have 
received recently.

Firstly, Thomas is correct, and I agree that the Lubuntu Constitution[1] 
(as ratified by the Ubuntu Community Council) clearly defines these 
roles and positions. With Lubuntu being a large player in the Ubuntu 
ecosystem, a one-time read-through of our governing document may be 
beneficial.

The reason Thomas Ward is Team Lead and I am Release Manager is simple: 
we both get to work on what we actually enjoy. I enjoy being Release 
Manager, and the responsibilities that come with it. Thomas enjoys being 
Team Lead because he is well-connected with the legal, financial, and 
infrastructure needs of the project, and that is what he enjoys doing. 
What I believe Thomas is trying to say is, he leaves the vast majority 
of day-to-day decisions to us, and is happy to delegate. After all, the 
Team Lead is just the head of the executive; he *is* required 
constitutionally speaking to run his decisions by the Lubuntu Council, 
and as a body, we do have the right to override him (which has not 
happened in recent memory, but the point still stands.) This all being 
said, there is no contention between Thomas and I; we're both actually 
quite happy with this arrangement, and have great mutual trust.

Thomas is skilled at being the head of the executive, that being said, I 
would remind him that, while I agree that this is a high-stakes 
discussion that should be dealt with by official leadership, Aaron did 
the right thing by responding in this case. His response was helpful, 
and actually gave Steve the information he needed to make his decision. 
Don't Punish Good Behavior™ :)

More responses in-line.

On 1/17/24 11:18 PM, Thomas Ward wrote:
> I was just about to reply with a decision from Team Lead and Council as 
> follows, which sort of affirms what Aaron said (though this DID need to come 
> from leadership, not Aaron):
> 
> Primary contact: Simon (tsimonq2)
> Secondary Contact: Dan (kc2bez)
> Third-tier contact (if Simon and Dan don't reply): Aaron (arraybolt3)

We'll be discussing this internally on a Lubuntu Council level after our 
next election cycle. I get the feeling that Dan and Aaron both need to 
be secondary contacts, but I'm okay with this being the decision for the 
time being. To be clear, this is only for Noble, and would not apply for 
e.g. point releases, which I have already explicitly delegated to both 
of them.

> For an all else fails contact, you can contact me - Thomas (teward) - as 
> Lubuntu Team Lead, I have executive authority to act if others are 
> unreachable or in cases where it requires executive overrule (see Simon's 
> reference to me dictating the "rest period" for Lubuntu started on Dec 20 
> instead of Simon's suggestion of Dec 25th through New Year).

I don't think that exactly was public, but I'm okay with it being public 
now. :)

> I'm also always open to pass on escalations if the others are unreachable, 
> Simon and Aaron both know I'm no stranger to dropping bags of work on them 
> when it's necessary.
> 
> (Note that my Lubuntu duties are independent of my other roles and hats)

(Thomas is actually pretty good about separating CC/etc. duties and 
Lubuntu duties, allow me to give him credit here.)

> Thomas
> 
> (Sorry for not replying in line, Outlook is the only mail client I have right 
> now and it's a pain for replying because it does top-replies).
> 
> -Original Message-
> From: Ubuntu-release  On Behalf Of 
> Steve Langasek
> Sent: Thursday, January 18, 2024 12:14 AM
> To: Aaron Rainbolt 
> Cc: Simon Quigley ; ubuntu-release@lists.ubuntu.com
> Subject: Re: Lubuntu LTS Requalification: 24.04 Noble Numbat
> 
> On Wed, Jan 17, 2024 at 10:34:04PM -0600, Aaron Rainbolt wrote:
>>> One of the points on https://wiki.ubuntu.com/RecognizedFlavors for
>>> LTS approval is
> 
>>> Flavor's support plan presented to Tech Board and approved; support plan
>>> should indicate period of time if beyond 9 months (3 yrs or 5 yr), key
>>> contacts, and setting expectations as to level of support.
> 
>>> Who are you identifying as the "contacts" for escalation of any
>>> issues regarding Lubuntu 24.04 LTS, from the technical board or the release 
>>> team?
> 
>> Perhaps this got missed, but in the Lubuntu Constitution (our personal
>> "how things work in our project" policy), this is very well-defined.
> 
> Well yes, that was not part of the information submitted to the Technical 
> Board as part of the qualification request.  It's healthy for a flavor to 
> have such structures in place and also speaks well of the maturity and health 
> of the Lubuntu flavor community; but please don't assume that members of the 
> broader Ubuntu community are conversant with such flavor-specific governance 
> details.

Well, let's fix that! :)

I li

Re: Request MRE approval for PostgreSQL

2024-01-18 Thread Sergio Durigan Junior
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?

Thanks,

-- 
Sergio
GPG key ID: E92F D0B3 6B14 F1F4 D8E0  EB2F 106D A1C8 C3CB BF14

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