Re: DMB appointment process [was: Call for nominations: Developer Membership Board restaffing]

On Tue, Jun 10, 2025 at 12:58:10PM +0200, Simon Chopin wrote:
> For the sake of clarity: appointments should still have clearly defined
> durations and existing members should explicitly reapply.

+1

> A common risk in FOSS communities is one of volunteers burning out.
> Having periodic checkpoints where one must explicitly assess whether
> they still have the time and energy to serve is fairly healthy.

+1

On Wed, Jun 11, 2025 at 12:16:34PM +0530, Utkarsh Gupta wrote:
> So something like a 2-year term a volunteer commits to. Perfectly fine
> (not ideal) to step down at any point in time. And should ask TB to
> run again when their membership is about to expire (like T-30 days or
> something).

To save on admin, would you consider it sufficient to use Launchpad's
team membership expiry feature? We could set the term to two years in
Launchpad, and allow members to self-renew with the usual explicit
affirming action. If a member doesn't want to make a further two year
commitment, they could then allow their Launchpad team membership to
lapse with no further action. It'd be nice to communicate with the DMB
and TB at the time, of course, but we don't have to make that a
requirement.

I'd be happy to document what the TB and DMB take the team membership
term, expiry and self-renewal to *mean* in a policy document - that
would be a straightforward, bounded and one-off task.

This would save a bunch of chasing round, especially at asynchronous
times as terms lose alignment.

Otherwise, we'd be creating an asynchronous administrative task for the
TB, which the TB has never had a good process to handle, and in practice
I think will just lapse all the time.

Robie

Re: DMB appointment process [was: Call for nominations: Developer Membership Board restaffing]

Hi Simon,

On Tue, Jun 10, 2025 at 4:28 PM Simon Chopin <schopin@ubuntu.com> wrote:
> For the sake of clarity: appointments should still have clearly defined
> durations and existing members should explicitly reapply.

That's fair. And also what I had in mind especially when LP membership
(currently at least) is expiry based.

So something like a 2-year term a volunteer commits to. Perfectly fine
(not ideal) to step down at any point in time. And should ask TB to
run again when their membership is about to expire (like T-30 days or
something).

> A common risk in FOSS communities is one of volunteers burning out.
> Having periodic checkpoints where one must explicitly assess whether
> they still have the time and energy to serve is fairly healthy.

Definitely. Agreed.

> Case in point: I'm not running again, but I don't think I could have
> ever explicitly quit.

Well, you could've communicated to us regardless. ;)

Anyway, thank you for serving your time in DMB. Hope you can step up
again in the future.

- u

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

Re: DMB appointment process [was: Call for nominations: Developer Membership Board restaffing]

Hi folks,

On lun. 09 juin 2025 12:25:54, Utkarsh Gupta wrote:
[snip]
> > So I wonder if it's worth continuing with elections at all? What if the
> > Technical Board were to just appoint DMB members as they felt
> > appropriate with a simple announcement, inviting prospective members to
> > apply to the TB directly?
>
> That makes a whole lot of sense, honestly. Unless doing poorly, those
> in DMB should be able to continue serving the board till they'd like -
> I see no reason why we should remove them especially when we don't
> have more volunteers to replace them with, as we've all noted this
> time and also many times in the past.
>
> I think the Techboard should delegate DMB and could/should rotate the
> seats however they see fit.

For the sake of clarity: appointments should still have clearly defined
durations and existing members should explicitly reapply.

A common risk in FOSS communities is one of volunteers burning out.
Having periodic checkpoints where one must explicitly assess whether
they still have the time and energy to serve is fairly healthy.

Case in point: I'm not running again, but I don't think I could have
ever explicitly quit.

Cheers,
Simon

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

Re: DMB appointment process [was: Call for nominations: Developer Membership Board restaffing]

Thanks for the feedback! I'll ask the TB to do this then, at their (our)
next meeting.

On Thu, Jun 05, 2025 at 03:06:21PM +0200, Simon Chopin wrote:
> > I do not know the ruling/processing, would the decision to switch need
> > to be an election itself?
> > Or is that something that can be discussed here and then decided by
> > the TB to make it official?
>
> The precise delegation path that led to the DMB having the powers it had
> today is hard to figure out, but at least its most technically powerful
> right — managing the Core Dev team — was handled by the TB before,
> according to https://ubuntu-news.org/2009/12/09/call-for-nominations-ubuntu-developer-membership-board/

Nice find!

> For me, that makes a simple vote from the current TB enough to enact any
> change regarding the way the DMB works.

I agree. My understanding is that everything the DMB does is under the
authority of the TB, and therefore the TB has the authority to change
that as they feel appropriate.

I prefer to seek this kind of change by consensus - which it appears we
have - but for such a significant structural change a formal TB decision
seems like the right way, and the members to be directly appointed can
be affirmed at the same time.

Robie

Re: DMB appointment process [was: Call for nominations: Developer Membership Board restaffing]

Hi Robie,

On Thu, Jun 5, 2025 at 12:23 PM Robie Basak <robie.basak@ubuntu.com> wrote:
> Getting enough volunteers has been a struggle for a number of years now.
> Resignations and absentees have also caused considerable difficulties in
> making decisions, as the DMB requires a simple majority of all board
> members to make most decisions.

Indeed.

> So I wonder if it's worth continuing with elections at all? What if the
> Technical Board were to just appoint DMB members as they felt
> appropriate with a simple announcement, inviting prospective members to
> apply to the TB directly?

That makes a whole lot of sense, honestly. Unless doing poorly, those
in DMB should be able to continue serving the board till they'd like -
I see no reason why we should remove them especially when we don't
have more volunteers to replace them with, as we've all noted this
time and also many times in the past.

I think the Techboard should delegate DMB and could/should rotate the
seats however they see fit.

> If volunteers were to increase in number in the future, we could go back
> to the election process.

Yep, of course.

> Here's a concrete proposal:
>
> [...]
> Feedback appreciated.

+1 for me - I have thought about it in the past but then dismissed it
because this wasn't how we did things in Ubuntu but I'm glad you felt
the same. :)

- u

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

Re: Splitting up linux-firmware

On 6/4/25 3:43 AM, Juerg Haefliger wrote:
>> Rather than doing it only in Ubuntu, how would you feel about making
>> such a change upstream first?
>
> That's a daunting task :-)

Yeah it's a lot of front loaded work, but the maintenance payoff is very
big. It could mean that the moment that new firmware is uploaded it's
required that the new "YAML" WHENCE file has the fields filled out
properly and every time there is a cherry pick or rebase your work of
figuring out what architectures, what subsystem, whether firmware is
needed is done for you.

>
>
>>
>> My thought is that WHENCE doesn't have enough detail.
>> * We don't know what host architectures firmware is for.
>> * We don't know what kernel version is a minimum requirement for a firmware.
>> * We don't know what kernel driver a given firmware goes with (to even
>> decide if it should be packaged!)
>> * We don't know what subsystem a given firmware goes with.
>
> Yes to all of them. But compiling that information and maintaining it
> is quite an effort. In the past I had this naive pipe dream of using modinfo
> data but as you're likely aware it provides insufficient and incomplete
> information. I did try to add some MODULE_FIRMWARE globs to drivers that
> construct the firmware names at runtime based on HW info but some subsystem
> maintainers didn't like it whereas it's common practice in other places. IIRC.

I don't think it needs to be 100% correct on a commit that converts
WHENCE to YAML. Sure, try to but don't break your back doing it.

We can use some hints like Debian packaging do for firmware that is for
all architectures (ie keyword 'all'). I think initially unless it's
blatantly obvious most firmware should be marked that way.

If subsystems "aren't known" we can have a keyword 'unknown' initially,
and then collectively get it corrected.

Likewise for kernel version just pick the oldest supported LTS for now.

Then we can have a call to arms for firmware owners to come help correct
the metadata.

>
>>
>> I feel like if we switched WHENCE to a (more) machine readable format
>> like YAML we can also encode new mandatory fields all of this information.
>
> Sounds good to me. I'll play around with it some.

Great!

>
>>
>> By doing it this way there will be less delta for Ubuntu to maintain,
>> and we can even end up with firmware packages that are architecture
>> specific.
>>
>> You can turn linux-firmware into a metapackage that depends upon all of
>> the subpackages.
>
> Yes. That is part of the plan but I realize it's not what I wrote initially.
>
>
>>
>> IMO picking a new package name for "graphics" firmware is wrong though.
>> There are plenty of firmwares in the drm subsystem that enable other
>> kinds of accelerators and have their own firmware.
>>
>> So I'm personally akin to making package names match subsystems.
>>
>> IE:
>>
>> linux-firmware-drm
>> linux-firmware-sound
>> linux-firmware-platform
>
> I'm not (yet) very attached to any particular grouping and/or naming. As long
> as people have the ability to uninstall packages with big blobs that they
> don't need.
>
> So maybe linux-firmware-drm is another metapackage that depends on:
> linux-firmware-drm-amd
> linux-firmware-drm-intel

Yes this sounds great. Basically if the subsystem firmware size is
getting unwieldy (<cough> nvidia) then split it up by vendors. If it's
relatively small just call it by subsystem.

> ...
>
>
>>
>> Thanks,
>
> Thanks for the feedback. It's much appreciated.
>
> ...Juerg
Sure.

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

Re: Splitting up linux-firmware

On 6/5/25 1:07 AM, Robie Basak wrote:
> On Mon, Jun 02, 2025 at 07:43:01PM +0200, Heinrich Schuchardt wrote:
>> Swapping GPUs and other hardware typically is not synchronized with system
>> installation or upgrades.
>>
>> My hope is that when moving the NVMe with my installed system from one
>> computer to another it still boots into the graphical desktop and has WiFi
>> and Ethernet.
>

> Indeed it's a longstanding property of a default Ubuntu installation
> that does not use proprietary drivers that this is possible. Please do
> not break that.

It's been a very long time since there has been any modern hardware that
"requires" proprietary wifi drivers.

The only hardware I know of is Broadcom "WL" which is 15+ years old.

>
> Note that there are other packages in a similar category. For example
> both amd64-microcode and intel-microcode are reverse Depends (not
> Recommends) of linux-image-generic in Noble.
>
>

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