All,

Encouraging collaboration between Debian and Ubuntu seems like a good
thing to me since there is a lot of work/code re-use and people overlap
between these projects.

However what is not clear to me from the discussion is what the
differences ought to be, and if there are contexts where collaboration
and merging things with Ubuntu is not a good idea for Debian.

Establishing those boundaries and clarifying what we believe may help
people who are involved in both Debian and Ubuntu to guide their actions
when wearing different hats.

Answers may also help us to understand what you as future DPL believe
what Debian should be going forward.

May I ask the nominees to share their thoughts on this?

Some detailed topics for consideration:

- Ubuntu uses Snap and the Snap Store, is that something which Debian
should adopt as part of the improved collaboration with Ubuntu?

- Ubuntu has a different system installer than Debian, is merging them
within scope?

- Ubuntu is aligned with corporate/governmental interests that can have
a preference for non-GPL software. What are the concerns
collaborating along that effort? I'm thinking about replacing
CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

- Ubuntu is generally more relaxed about copyright licensing and
software freedom perspective than Debian, and Ubuntu includes and make
use of more non-free content than what is in Debian. Is collaborating
on expanding that in scope for Debian?

- Ubuntu doesn't support some architectures/ports that we have in
Debian, and Ubuntu support/assume some CPU features that Debian
doesn't. Is harmonizing the set of support in scope?

- Ubuntu has a fixed time-based release schedule, as that something we
should adopt?

/Simon

-----BEGIN PGP SIGNATURE-----

iQNoBAEWCAMQFiEEo8ychwudMQq61M8vUXIrCP5HRaIFAmfdNdgUHHNpbW9uQGpv c2Vmc3Nvbi5vcmfCHCYAmDMEXJLOtBYJKwYBBAHaRw8BAQdACIcrZIvhrxDBkK9f V+QlTmXxo2naObDuGtw58YaxlOu0JVNpbW9uIEpvc2Vmc3NvbiA8c2ltb25Aam9z ZWZzc29uLm9yZz6IlgQTFggAPgIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgBYh BLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XQkBQkNZGbwAAoJENc89jjFPAa+BtIA /iR73CfBurG9y8pASh3cbGOMHpDZfMAtosu6jbpO69GHAP4p7l57d+iVty2VQMsx +3TCSAvZkpr4P/FuTzZ8JZe8BrgzBFySz4EWCSsGAQQB2kcPAQEHQOxTCIOaeXAx I2hIX4HK9bQTpNVei708oNr1Klm8qCGKiPUEGBYIACYCGwIWIQSx0r0Tdb7LeEz0 +MTXPPY4xTwGvgUCZ9F0SgUJDWRmSQCBdiAEGRYIAB0WIQSjzJyHC50xCrrUzy9R cisI/kdFogUCXJLPgQAKCRBRcisI/kdFoqdMAQCgH45aseZgIrwKOvUOA9QfsmeE 8GZHYNuFHmM9FEQS6AD6A4x5aYvoY6lo98pgtw2HPDhmcCXFItjXCrV4A0GmJA4J ENc89jjFPAa+wUUBAO64fbZek6FPlRK0DrlWsrjCXuLi6PUxyzCAY6lG2nhUAQC6 qobB9mkZlZ0qihy1x4JRtflqFcqqT9n7iUZkCDIiDbg4BFySz2oSCisGAQQBl1UB BQEBB0AxlRumDW6nZY7A+VCfek9VpEx6PJmdJyYPt3lNHMd6HAMBCAeIfgQYFggA JgIbDBYhBLHSvRN1vst4TPT4xNc89jjFPAa+BQJn0XTSBQkNZGboAAoJENc89jjF PAa+0M0BAPPRq73kLnHYNDMniVBOzUdi2XeF32idjEWWfjvyIJUOAP4wZ+ALxIeh is3Uw2BzGZE6ttXQ2Q+DeCJO3TPpIqaXDAAKCRBRcisI/kdFotaNAP9N1hIvwiT5 R6Jim55iCCNmE+M3AEcaKqz3iqRgbG8vogD7B2rrGS9GZujCLJhBzI2gE2dIz29l ffet8y27DYblCAc=
=Ty9k
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Mar 21, 2025 at 10:48:08AM +0100, Simon Josefsson wrote:

- Ubuntu is aligned with corporate/governmental interests that can have
a preference for non-GPL software. What are the concerns
collaborating along that effort? I'm thinking about replacing
CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

not that it matters much for the question, but Sequoia is LGPL licenced,
as stated in the first sentence on https://sequoia-pgp.org/contribute/
and in it's git repos.


--
cheers,
Holger

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

When this virus is over, I still want some of you all to stay away from me.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEuL9UE3sJ01zwJv6dCRq4VgaaqhwFAmfdRxcACgkQCRq4Vgaa qhwQ3A//WoV4RkqoU0pM3ooX6Yrd/PgqQNbf6W3wNe3hPUEQDUdCPPX8WAqdCSyH ScGviyAEjhRRyqUMyf8QFP+VoMQmm35jkeouQsPScRJtYW7bnpP/ghRB9sCL+AH9 hpnhoI/BT/aLFsstc0r1EIZqFuleWM8SX4XoaNXlX0+HEGyl8X1NYvqHcMM80Oh1 qLeIrrX5zCHVJpycymqwZgx57EtPSOBHdgnh6n639vQC6OpSazK+VP6USSg04a0C QksxKdTLvG8iWD9Ue2vkBZOVp4aTHqggq3zD0ZaQ5220n9cJPQTM65/IMAOtP0XY nOw6W3Hvhp1MgLqC9EAZHBmMuoZpo+n0xe3lbLCIGBaL6GCVfc2xSJxw963EuMJc F1MF3VJxQtlUHpvZBwoG76DvZSFDRZqLP4/GY1cbIL57r/8HwViQtN/oNn7+l0NV VZ65VNpeZ+Z1PKF+rnIM2yuUZtqi/OBjPHK0OeBCiLLHMbamISlJhpaJs8Ruvky0 IVkwNGNPaWHYC0B+ZHgiWnU8FFcPKqW4R/LmSd4il1K3Uh59s2q8NKoB//neOp/0 hOFeG/nPwQCnf8MvvhuX58w/DofT5bV/DEgjZ

Hello,

Encouraging collaboration between Debian and Ubuntu seems like a good
thing to me since there is a lot of work/code re-use and people overlap >between these projects.

it is to me too :)

However what is not clear to me from the discussion is what the
differences ought to be, and if there are contexts where collaboration
and merging things with Ubuntu is not a good idea for Debian.

Merging of bugfixes and build fixes from Ubuntu, this is what I mean

Establishing those boundaries and clarifying what we believe may help
people who are involved in both Debian and Ubuntu to guide their actions
when wearing different hats.

Indeed, but this isn't a decision that eventually a DPL has to make.
I would expect CTTE or some similar team to vote on this, and as DPL
I would not expose my view, to not pose any risk of flaming/changing people's mindset on the topic.

Answers may also help us to understand what you as future DPL believe
what Debian should be going forward.

If you ask specific technical things, this is now that DPL role is about, if you ask about directions, I'm ok
with an answer :)

May I ask the nominees to share their thoughts on this?

I'm happy to answer this, since I'm not DPL, I'll share my personal opinions on this matter

- Ubuntu uses Snap and the Snap Store, is that something which Debian
  should adopt as part of the improved collaboration with Ubuntu?

no for me, but I admit having snaps for special cases such as firefox/thunderbird is indeed a smart/fast/good idea, specially to avoid backporting of new releases/toolchain to stable releases
Again, CTTE is the best team to decide on this.

- Ubuntu has a different system installer than Debian, is merging them
  within scope?

why should it be? Distro can live with their own specific installer, with no issues at all.
At some point, if people wants to have one single installer, the teams can join together, share patches, create one common repo between Debian and Ubuntu,
but this is a decision that DPL has no power to take, fortunately

- Ubuntu is aligned with corporate/governmental interests that can have
  a preference for non-GPL software.  What are the concerns
  collaborating along that effort?  I'm thinking about replacing
  CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

Again, CTTE for this.
As clang maintainer, I might have an idea about it (and the idea is that I would like gcc to keep being the default).
(and the answer is no to all, but if CTTE wants to adopt some of all of them, I'm strongly fine with it)

If you want me to say that GPL is better than other licenses, I won't do it.

I personally don't like tivoization issues (hey GPL-3!) in my $dailyjob, and for this reason we keep
using old unpatched versions or forks of essential tools, and this is something that corporate companies have
to deal with, so MIT/GPL-2 is usually my best choice w.r.t. licensing.

Also, if Ubuntu chooses some DFSG licensing, I don't see any issue in Debian having them in main.
Are we saying that there are First class and Second class DFSG licenses?
Do we want to go down that rabbit hole? I don't.

In this case, ftpmasters should be the best people/team to speak with, not DPL

- Ubuntu is generally more relaxed about copyright licensing and
  software freedom perspective than Debian, and Ubuntu includes and make
  use of more non-free content than what is in Debian.  Is collaborating
  on expanding that in scope for Debian?

Ubuntu has restricted, multiverse, Debian has non-free.
I don't see much differences, but I don't see/think anybody ever wanted to do such a thing.

- Ubuntu doesn't support some architectures/ports that we have in
  Debian, and Ubuntu support/assume some CPU features that Debian
  doesn't.  Is harmonizing the set of support in scope?

I don't get if you want less Debian archs, or more Ubuntu architectures, but to me
looks like a no (and this is something that buildd/admins should decide eventually, not DPL).

- Ubuntu has a fixed time-based release schedule, as that something we
  should adopt?

I like fixed releases (not strictly fixed, but some sort of timeline is good for people in general).

but the decision on this has to be made by Release Team.

To summarize, as DPL I wouldn't answer to any of these questions, because fortunately
Debian already has specific teams to deal with them.

thanks,

Gianfranco

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello again,

I *was* part of the Technical Committee, but "graduated" from it slightly over two years ago. Still,

Gianfranco Costamagna dijo [Fri, Mar 21, 2025 at 03:29:46PM +0000]:

Hello,
(...)

Establishing those boundaries and clarifying what we believe may help >>people who are involved in both Debian and Ubuntu to guide their actions >>when wearing different hats.

Indeed, but this isn't a decision that eventually a DPL has to make.
I would expect CTTE or some similar team to vote on this, and as DPL
I would not expose my view, to not pose any risk of flaming/changing people's mindset on the topic.
(...)

- Ubuntu uses Snap and the Snap Store, is that something which Debian
  should adopt as part of the improved collaboration with Ubuntu?

no for me, but I admit having snaps for special cases such as firefox/thunderbird is indeed a smart/fast/good idea, specially to avoid backporting of new releases/toolchain to stable releases
Again, CTTE is the best team to decide on this.
(...)

- Ubuntu is aligned with corporate/governmental interests that can have
  a preference for non-GPL software.  What are the concerns
  collaborating along that effort?  I'm thinking about replacing
  CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

Again, CTTE for this.
As clang maintainer, I might have an idea about it (and the idea is that I would like gcc to keep being the default).
(and the answer is no to all, but if CTTE wants to adopt some of all of them, I'm strongly fine with it)

I'm sorry, I disagree it's the Technical Committee's role to tackle such issues.

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

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

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

– Gunnar

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Mar 21, 2025 at 10:48:08AM +0100, Simon Josefsson wrote:

All,

Encouraging collaboration between Debian and Ubuntu seems like a good
thing to me since there is a lot of work/code re-use and people overlap between these projects.

However what is not clear to me from the discussion is what the
differences ought to be, and if there are contexts where collaboration
and merging things with Ubuntu is not a good idea for Debian.

Establishing those boundaries and clarifying what we believe may help
people who are involved in both Debian and Ubuntu to guide their actions
when wearing different hats.

Answers may also help us to understand what you as future DPL believe
what Debian should be going forward.

May I ask the nominees to share their thoughts on this?

Some detailed topics for consideration:

- Ubuntu uses Snap and the Snap Store, is that something which Debian
should adopt as part of the improved collaboration with Ubuntu?

I'm not sure what this means; tbh. snapd is maintained in Debian by
Zygmunt, you can install and use it. The snap store obviously contains
a lot of non-free software which isn't particularly well aligned with
Debian's values.

- Ubuntu has a different system installer than Debian, is merging them
within scope?

This is a question for the image and installer teams; I believe and I
have explained that in the previous thread that our approach to building
pools of debs on a disk and then installing those is far inferior to the
image based workflow. But again, this is not really a DPL topic.

- Ubuntu is aligned with corporate/governmental interests that can have
a preference for non-GPL software. What are the concerns
collaborating along that effort? I'm thinking about replacing
CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

That's a bit paranoid.

As the person driving the Sequoia thing out of personal interest,
let me assure you this is all down to GnuPG having forked the
standard and the implementation being sloppy. Others have already
explained that your premise even doesn't hold: Sequoia is LGPL
licensed. Also I did that in Debian so far for gpgv->sqv, but
it hasn't landed in Ubuntu yet.

clang and uutils have other things to offer.

- Ubuntu is generally more relaxed about copyright licensing and
software freedom perspective than Debian, and Ubuntu includes and make
use of more non-free content than what is in Debian. Is collaborating
on expanding that in scope for Debian?

Which specific non-free content are you interested in? There is no
significant difference between Debian and Ubuntu; except that the
components are named differently...

- Ubuntu doesn't support some architectures/ports that we have in
Debian, and Ubuntu support/assume some CPU features that Debian
doesn't. Is harmonizing the set of support in scope?

- Ubuntu has a fixed time-based release schedule, as that something we
should adopt?

These are questions and decisions for the release team.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 🙃

The first one (whether DDs who are also Ubuntu Devs should clearly separate their actions under their different tasks) is clearly a social issue, not a 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.

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

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

-----BEGIN PGP SIGNATURE-----

wr0EABYKAG8FgmffS/UJEOL2O0NT9FmJRxQAAAAAAB4AIHNhbHRAbm90YXRpb25z LnNlcXVvaWEtcGdwLm9yZ7Ug8a8AW89NTeF/vmmS+D8oYe+abNhiu3yp2rRQo8sZ FiEEYLMJPZYQjly5cULv4vY7Q1P0WYkAAHIvAP46l/B1UKptIwmQG4rcmzV1sw7z Wz0Smysn1QlHirYCCQD/fX/PItxN4+WaLcDaJ99Wp7jtNlWQtu6oTMDzGmaOpwQ=
=NmQZ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Simon,

Am Fri, Mar 21, 2025 at 10:48:08AM +0100 schrieb Simon Josefsson:

Encouraging collaboration between Debian and Ubuntu seems like a good
thing to me since there is a lot of work/code re-use and people overlap between these projects.

As I wrote in my other answer[1] I prefer collaboration with *any*
Debian derivative.

Some detailed topics for consideration:

- Ubuntu uses Snap and the Snap Store, is that something which Debian
should adopt as part of the improved collaboration with Ubuntu?

I do not consider this a topic that is relevant for the DPL. Following
our Do-O-Cracy principle I expect people who need Snaps to care for the
snap infrastructure (which is working as far as I'm informed) as well as
say flatpacks.

- Ubuntu has a different system installer than Debian, is merging them
within scope?

I also do not think that the DPL should decide about the installer. I'm
all for cooperation and seeking for synergies. But this is the decision
of the d-i team.

- Ubuntu is aligned with corporate/governmental interests that can have
a preference for non-GPL software. What are the concerns
collaborating along that effort? I'm thinking about replacing
CoreUtils with UUtils, GCC with Clang, GnuPG with Seqoia etc.

Same here: If someone decides to suport the said alternatives (as far
as I can see these exist) it might be picked up by any derivative. If maintainers of our dreivatives might care for the packages upstream in
Debian - great.

- Ubuntu is generally more relaxed about copyright licensing and
software freedom perspective than Debian, and Ubuntu includes and make
use of more non-free content than what is in Debian. Is collaborating
on expanding that in scope for Debian?

For me Debian equals to Debian main which contains software released
under DFSG free licenses. I don't see any change coming here, neither
do I see any good reason for this. I do not consider it as
"collaboration" if we might weaken this principle.

- Ubuntu doesn't support some architectures/ports that we have in
Debian, and Ubuntu support/assume some CPU features that Debian
doesn't. Is harmonizing the set of support in scope?

I do not see any good reason in droping features from Debian just
because one or more of our derivatives does not. We should decide on
our own what we are able to support. If we have the person-power to
support our release architectures that's great. I absolutely fail to
see in which way droping some architecture in Debian will help any
derivative.

- Ubuntu has a fixed time-based release schedule, as that something we
should adopt?

I like the principle: "Its ready when its ready." The only thing
I would love to enhance in our release cycle is that we should strive
to have as short as possible time from freeze to release.

Kind regards
Andreas.

[1] https://lists.debian.org/debian-vote/2025/03/msg00043.html

--
https://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)