[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q to nominees: Rough plan on Debian/Ubuntu non-collaboration?



Gianfranco Costamagna dijo [Sat, Mar 22, 2025 at 09:07:22AM +0000]:
Hello, Gunnar, thanks for the answer. Which of these questions you think
belong to DPL role? They might belong to CTTE, Gars but I don't think they
still belong to DPL...

Sorry for top posting, my Android MUA doesn't allow me to properly quote
things

Yahoo Mail: Search, Organize, Conquer

Now _that_ is a brave advertisement for Yahoo Mail! FWIW, I didn't know it was
still a thing 😉

Thing is, probably they are not DPL-related. The reason I answered is that I
don't believe them to be Technical Committee-related. The examples were proposed
by you 🙃

GW> The first one (whether DDs who are also Ubuntu Devs should clearly separate
GW> their actions under their different tasks) is clearly a social issue, not a
GW> technical one, so CTTE has no say in it.

This is not something the DPL should tackle, nor the Technical Committee. Is
there a specific conflict you have in mind? If it is just for the general issue
of having different yardsticks with which to measure one's activity, I would
leave it to the judgement of each of the DD/DMs or UbuntuDs in question. Of
course, if (just picking a random UbuntuD name, I'm sure he won't mind -- and
it's not a credible acusation 😉) Julian decided apt should search for available
snaps and install them instead of fetching the right deb packages... Yes,
Technical Committee would probably overrule the apt maintainer.

GW> The second one, "should Debian and Ubuntu collaborate via snaps" — If I
GW> understand correctly, the question should be, "should Debian provision so
GW> it's easy to install snaps in your clean Debian system". And that roughly
GW> translates to, "is there a DD who has enough motivation to make the Snap
GW> ecosystem work in Debian?" So, as long as the Snap ecosystem does not have a
GW> frontal collision to the way we handle Debian (i.e. policy violations,
GW> forced binary name clashes or whatnot), it's also not in the Technical
GW> Committee's sphere.

Again, I'm replying to a hypothetical situation you presented as something that
the DPL would not take care of, and should leave in the hands of the Technical
Comittee. I just said, "it's not the TC who should intervene in that
hypothetical situation".

And yes, as Julian already answered — this has already happened, and the TC has
not complained.

GW> Third, the Technical Committee has no say regarding licenses. Of course, if
GW> somebody were to propose to replace gcc for clang in build-essential, or to
GW> remove coreutils from Priority:required and add uutils, TC would probably be
GW> invoked and have a say. But right now, we are so far away from such a
GW> possibility that I don't think the Committee should be invoked in any of the
GW> points raised in this mail.

Well, I don't see Debian hastily migrating from coreutils to uutils, but it
_could_ happen in due time. I don't see it as legally challenging (so no, it
would not be for ftpmasters to decide -- both licenses are perfectly free). But
replacing packages that are so central is usually a ripe topic for a
project-wide debate, that could either be solved via a GR, or –as I said in the
quoted message– the TC could be invoked for it. But not because the project were
migrating a core tool to a non-copylefted license — this would be, I guess, due
to stability and compatibility compromises we keep and whatnot. Still, for this
I'm over-futurizing.

  – Gunnar.

Attachment: signature.asc
Description: PGP signature


Reply to: