Re: Evolving away from source package realms

[Raphael Hertzog]

Hello,

On Sun, 23 Oct 2022, Didier Raboud wrote:
> (Sorry for the delay in getting back to that thread. #life)

Me even worse ;-)

> Specifically, this is something I'd like to discuss in more extensive terms.  
> I 
> think I'm postulating that Debian would be in a better place with a "Debian 
> core" topic team, in charge of certain "base source packages", but _ALSO_ of 
> core Debian decisions: filesystem layout, default init systems, etc; all 
> these 
> things which responsibility is _not_ clearly within a specific source 
> package's 
> realm.

But how would this new "Debian core team" take decisions? 

De we need consensus? Will they do a mini-GR among them if there's no
consensus? What level of formalization is really required?

At least, your proposal has the merit of empowering some persons to take
decisions on some topics... because our current model clearly doesn't work
well at that level as soon as we cross the boundary of a single package.

Some packaging teams have written "sub-policies" and this goes clearly
in your direction.

IMO we need to take inspiration from the Python community, everybody can
propose ideas and draft DEP[1], and there would be a Debian Steering
Council that would ack or nack the various DEP. Once acked, everybody
should be empowered to make changes as required by the DEP.

Whether the technical committee should be that council, or not, is not
clear to me.

Maybe depending on the scope of the DEP, and the number/set of packages it
affects, it could be validated by topic-team-councils...

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Evolving away from source package realms

[Gerardo Ballabio]

Didier Raboud wrote:
> What most respondents have gotten across as the bulk of my proposal seems to
be: "we could limit upload rights to certain packages"
>
> ... where what I was trying to get across was: "we could team-maintain the
core of Debian (and by extension, other subsets)"

Frankly, reading your original message, most of it seemed indeed to
revolve around the former, with "remove the source-package-level
realms" dropped in as a somewhat casual note near the end. I suspected
that that was your real focus (and already replied to that), but it
wasn't that clear.

> The problem I'm trying to describe (and therefore the mitigations/solutions I
put up for discussion) is that source package realms are not the right
granularity for Debian development anymore.

As I understand it, you may not be looking for the right "package
granularity" so much as you're looking for the right "developer
granularity".

If the problem is that the maintainer of some package isn't
collaborating -- specifically, refuses to apply a particular patch --
it doesn't really matter whether maintainership rights are assigned at
single package level or at another level. What matters is that you
don't want to have a single maintainer who can exercise veto power.

Larger "package realms" would probably be maintained by more people,
so that would indeed generate the intended effect, but as a more or
less accidental byproduct of a larger change that might have other
undesired consequences (specifically, several posters have expressed
the concern that this might be detrimental to developer motivation).
I'd prefer a proposal that addresses directly the specific issue.

In fact, I even wonder whether your proposal would actually solve
anything. In Debian, people only do the work that they want to do. If
you want to add more maintainers to a package and can't find
volunteers, you might work around that by "promoting" maintainers of
related packages to co-maintainers of the whole realm. But what will
happen in most cases is that the promotion will remain written on the
(electronic) paper -- most people will just keep working on their
packages like they've always been doing, will never exercise their
co-maintainer powers, and will probably decline to be involved in any
dispute that might arise over a package that happens to be "in their
realm" but that they have no direct interest in.

That said, there is some merit to the proposal of a "core team" that
collectively maintains a set of "core packages". There are already
delegated teams that maintains key parts of Debian -- release team,
FTP team, installer team, etc. -- so I suppose that a "core team"
would be a nice addition (pending a good round of yak-shaving over the
name).

But let's not forget that all existing teams have formed by
*voluntary* aggregation and their members generally choose whom to
work with. Trying to force the creation of a new team might not work
well. For example, several years ago the DPL of the time forced the
addition of a new FTP member. That resulted in the resignation of
other members.

Gerardo

Re: Evolving away from source package realms

[Didier Raboud]

(Sorry for the delay in getting back to that thread. #life)

What most respondents have gotten across as the bulk of my proposal seems to 
be: "we could limit upload rights to certain packages"

... where what I was trying to get across was: "we could team-maintain the 
core of Debian (and by extension, other subsets)"

The problem I'm trying to describe (and therefore the mitigations/solutions I 
put up for discussion) is that source package realms are not the right 
granularity for Debian development anymore. Quoting zack from a nice message 
on d-private (with his permission):

At a certain time in Octobre 2022, Stefano Zacchiroli wrote :
> The granularity of the package is no longer compatible with our modern
> collaborative software development works. And Debian implement a
> particularly strong version of it, which goes against the (now decades
> old, coming from the early agile days) software engineering wisdom that
> "strong code ownership" is bad for an engineering team. Many attempts
> have been made over time to mitigate this problem (e.g., team
> maintenance of group of interrelated packages, low threshold NMU, making
> NMUs more socially acceptable, etc.). But they are just that:
> mitigations, not actual solutions.
>
> Debian needs to get away from packages as unit of responsibility (...)

From that discussion starting point, I unrolled two thought threads: a) how to 
lower the walls of our source package castles; b) topic teams (ala Ubuntu).

From what I read, only a) got serious discussion.  I particularly like Russ' 
take, which I understand as follows: it'd be nice if it were easy to have 
smaller upload scope, _provided that_ there were an easy way to get upload 
rights back.

Something like "DDs can grant themselves upload rights to certain packages, 
with our without expiration; they can review and revoke these rights anytime. 
They can also get archive-wide upload rights, but this has an quite short 
expiration."  The latter part would be to allow BSPs, or archive-wide upload 
batches, but not (necessarily?) allow DDs to get constant archive-wide upload 
rights.

But but but... I think it would improve Debian's security to do that; but it 
doesn't really address any of the problems I was trying to address. :-)

Le vendredi, 7 octobre 2022, 15.24:23 h CEST Didier Raboud a écrit :
> Looking at how Ubuntu is structured (with topic teams) made me wonder if
> some variation of that couldn't reasonably be applied to Debian, by
> dividing our giant set in subsets (topic teams, baskets, ...), under
> clearer team's responsibilities, and onboarding processes. 

Le vendredi, 7 octobre 2022, 15.24:23 h CEST Didier Raboud a écrit :
> In the current situation in which there's quite some friction around
> "merged- usr/" (and in the lingering situation around init systems), I'd
> see a "Debian core" subset made of base-files, libc, authority over the
> filesystem layout, dpkg, apt; and a "Debian system core" subset with
> authority over supported and default init systems, kernel, initramfs,
> firmware*.

Specifically, this is something I'd like to discuss in more extensive terms.  I 
think I'm postulating that Debian would be in a better place with a "Debian 
core" topic team, in charge of certain "base source packages", but _ALSO_ of 
core Debian decisions: filesystem layout, default init systems, etc; all these 
things which responsibility is _not_ clearly within a specific source package's 
realm.

(disclaimer: I'm well aware of the social friction implied from moving towards 
such a situation. People change, their interests and viewpoints also do; folks 
join and leave Debian.  We should be able to discuss such setups in the 
abstract; without diving in "implementation details" (sic).)

Thoughts?
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Evolving away from source package realms

[Bastian Blank]

On Tue, Oct 18, 2022 at 07:25:39AM -0700, Russ Allbery wrote:
> This is probably my security brain from my day job, but I would prefer to
> be able to drop permissions that I'm not currently using, as long as I can
> get them back easily.  It reduces the blast radius of mistakes and
> compromises.

I would like to have the possibility of multiple credentials.  Currently
everything in Debian proper is related to one single OpenPGP key.  I
need that to do uploads pretty often.  But in addition it can be used to
overtake my account and with it all my privileged access.

So the possibility of using another set of credentials with restricted
upload access, aka upload access to packages I specified myself, would
be really nice to avoid needing access to the one mighty key all the
time.

Bastian

-- 
To live is always desirable.
-- Eleen the Capellan, "Friday's Child", stardate 3498.9

Re: Evolving away from source package realms

[Timo Röhling]

Hi,

* Johannes Schauer Marin Rodrigues  [2022-10-12 10:49]:

If I understand what you write correctly, then you propose to put into place a
technical barrier for uploading other people's packages. But that will not
reduce the ownership (or hegemony) of developers over their packages and thus
not address the problems that were identified.

This is my understanding as well, and I agree that Didier's proposal
attempts to solve a very different problem.

If we are looking for ways to limit the amount of damage any
individual DD can do (be it inadvertently or maliciously), wouldn't
it be better to assume that it *can* happen, no matter how hard we
try to prevent it, and have some ultima ratio available to undo the
damage? For example, roll back unstable by 24 hours from
snapshot.d.o?


Cheers
Timo

--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: Evolving away from source package realms

[Thomas Goirand]

On 10/18/22 16:25, Russ Allbery wrote:

I think there's some merit for being able to
restrict and expand your own permissions


As much as I understand, *self-controlling* your own rights is not the 
original proposal.


Cheers,

Thomas Goirand (zigo)

Re: Evolving away from source package realms

[M. Zhou]

On Tue, 2022-10-18 at 13:00 +0200, Thomas Goirand wrote:
> On 10/18/22 00:07, Charles Plessy wrote:
> > If it is
> > easy for those who need to get archive-wide priviledges, it is also easy
> > to start without that priviledge as a default.
> 
> I really would hate having 2 sets of uploading DDs. One with the 
> archive-wide privilege, and the one without. Then you'd need to ask for 
> that right, and potentially have to explain why you need it. This is a 
> terrible idea, with not enough justification (IMO).

I forecast that (if we had such separated privileges), the group of DDs
that do not have full permission will be greatly demotivated on helping
others' packages.

It's not worthwhile to do so while the only gain I can see is to prevent
some temporary flamewars. However, dealing that with a permanent change
in the privilege structure will reveal more downsides for long run.

For my own involvement in this community, my feeling is that the
thing that would most easily get worn out is motivation. To make the
community healthy, we should not try to demotivate contributors somehow.

Re: Evolving away from source package realms

[Russ Allbery]

Thomas Goirand  writes:

> I really would hate having 2 sets of uploading DDs. One with the
> archive-wide privilege, and the one without. Then you'd need to ask for
> that right, and potentially have to explain why you need it. This is a
> terrible idea, with not enough justification (IMO).

This is probably my security brain from my day job, but I would prefer to
be able to drop permissions that I'm not currently using, as long as I can
get them back easily.  It reduces the blast radius of mistakes and
compromises.

I think we're arriving, from different directions, at the importance of
"get them back easily."  But I think there's some merit for being able to
restrict and expand your own permissions even if it is entirely automated
via, say, a signed email to a control address.  Those sorts of speedbumps
in the way of mistakes or compromise are sometimes unappreciated on the
grounds that an attacker can just expand their permissions after a
compromise, but from a security standpoint there is *some* value in each
additional thing the attacker has to figure out how to do and each
additional detectable interaction they have with the system, as long as it
doesn't add pain for the legitimate user.

That might be a useful reframing of the idea: let those of us who would
like to (possibly temporarily) voluntarily restrict the scope of our
upload access have a way to do that, without implying that people who want
archive-wide upload rights need to change anything.

-- 
Russ Allbery (r...@debian.org)  

Re: Evolving away from source package realms

[Thomas Goirand]

On 10/18/22 00:07, Charles Plessy wrote:

If it is
easy for those who need to get archive-wide priviledges, it is also easy
to start without that priviledge as a default.


I really would hate having 2 sets of uploading DDs. One with the 
archive-wide privilege, and the one without. Then you'd need to ask for 
that right, and potentially have to explain why you need it. This is a 
terrible idea, with not enough justification (IMO).


Cheers,

Thomas Goirand (zigo)

Re: Evolving away from source package realms

[M. Zhou]

On Wed, 2022-10-12 at 16:09 -0700, Russ Allbery wrote:
> Pierre-Elliott Bécue  writes:
> 
> > 
> 
> Is there some way right now for me to say "any Debian contributor
> with
> upload rights should feel free to merge changes and upload this
> package
> without needing to consult me at all, and I will subscribe to the
> packages
> feed for the package and say something if something happens that I
> don't
> like" with a packaging repository on Salsa?  And if not, would that
> be a
> good way to start?
> 


In fact I've proposed a very similar idea several months ago:
https://lists.debian.org/debian-devel/2022/04/msg00105.html
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34

Re: Evolving away from source package realms

[Charles Plessy]

Hi Nilesh,

Le Sun, Oct 16, 2022 at 03:16:11PM +0530, Nilesh Patra a écrit :
> 
> IMHO the "risk assessment" for most DDs is already done via NM process.
> Usually people are mindful of when they upload, and do ask others
> for opinions when they do NMU's.

The risk assessment I suggest is for the archive, not for each people
individually.  Simple questions (please let's not discuss answers) such
as:

 - What if a DD gets their keys plus password lost and found or stolen
   by a third party ?
 - What if a DD turns so spiteful that harming Debian becomes more
   important than protecting their reputation ?
 - What if a hostile upload happens and is undetected for a while ?
 - What if a hostile upload happens and is removed before it does harm ?
 - What if a hostile upload happens and is blocked even before it
   reaches the mirrors ?  Will the world applause or will our reputation
   be harmed anyway ?
 - What is a hostile upload ?  Have we thought about all possible case ?

Not all answers to these questions imply that limiting upload rights is
of high importance.  But I think that it is important to take the time
to think about them.

> I can understand. However that is not true for a lot of DDs (including me).
> Many people do need archive-wide previledges. Tobias gave a rather crisp 
> reason
> in their mail.

That is very true.  Upload restrictions come with a cost.  The main
message I would like to pass is that maybe in the course the development
or maintenance of our infrastructures, that cost will drop.  If it is
easy for those who need to get archive-wide priviledges, it is also easy
to start without that priviledge as a default.

Have a nice day,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Evolving away from source package realms

[Nilesh Patra]

Hi Charles,

On Sun, Oct 16, 2022 at 01:06:23PM +0900, Charles Plessy wrote:
> Le Wed, Oct 12, 2022 at 12:14:35AM +, Scott Kitterman a écrit :
> > 
> > What fraction of security issues we've had in Debian do you think
> > narrower upload permissions would have prevented?
> 
> Exactly zero.  But my comment is not about the past, it is about the
> future.
> 
> I think that a proper risk assessment would be worth doing, an I also
> think that this mailing list is not a proper place for doing it, not
> because of secrecy but because of noise and lack of focus.  Discussing
> the conclusions here would of course be important.

IMHO the "risk assessment" for most DDs is already done via NM process.
Usually people are mindful of when they upload, and do ask others
for opinions when they do NMU's.
Risk assessment might as well be a slippery slope, as it would allow
some DDs over others to upload things which will create extra friction.

> On my side, I would be fine if my upload key would be restricted to the
> packages that me and my packaging team maintain.  I am very unlikely to
> need archive-wide privileges in the near future.

I can understand. However that is not true for a lot of DDs (including me).
Many people do need archive-wide previledges. Tobias gave a rather crisp reason
in their mail.

> Have a nice Sunday,

You too!

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: Evolving away from source package realms

[Tobias Frost]

On Sun, Oct 16, 2022 at 01:06:23PM +0900, Charles Plessy wrote:
> Le Wed, Oct 12, 2022 at 12:14:35AM +, Scott Kitterman a écrit :
> > 
> > What fraction of security issues we've had in Debian do you think
> > narrower upload permissions would have prevented?
> 
> Exactly zero.  But my comment is not about the past, it is about the
> future.
> 
> I think that a proper risk assessment would be worth doing, an I also
> think that this mailing list is not a proper place for doing it, not
> because of secrecy but because of noise and lack of focus.  Discussing
> the conclusions here would of course be important.
> 
> On my side, I would be fine if my upload key would be restricted to the
> packages that me and my packaging team maintain.  I am very unlikely to
> need archive-wide privileges in the near future.

Being a frequent participant of a Bug Squashing Party and also general active
on sponsoring, restriction to upload privilieges will likely impair my ability 
to
contribute to Debian in this areas.

-- 
tobi

Re: Evolving away from source package realms

[Charles Plessy]

Le Wed, Oct 12, 2022 at 12:14:35AM +, Scott Kitterman a écrit :
> 
> What fraction of security issues we've had in Debian do you think
> narrower upload permissions would have prevented?

Exactly zero.  But my comment is not about the past, it is about the
future.

I think that a proper risk assessment would be worth doing, an I also
think that this mailing list is not a proper place for doing it, not
because of secrecy but because of noise and lack of focus.  Discussing
the conclusions here would of course be important.

On my side, I would be fine if my upload key would be restricted to the
packages that me and my packaging team maintain.  I am very unlikely to
need archive-wide privileges in the near future.

Have a nice Sunday,

Charles

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy

Re: Evolving away from source package realms

[Tobias Frost]

On Wed, Oct 12, 2022 at 10:19:28PM -0700, Russ Allbery wrote:
> Tobias Frost  writes:
> > On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:
> 
> >> Is there some way right now for me to say "any Debian contributor with
> >> upload rights should feel free to merge changes and upload this package
> >> without needing to consult me at all, and I will subscribe to the
> >> packages feed for the package and say something if something happens
> >> that I don't like" with a packaging repository on Salsa?  And if not,
> >> would that be a good way to start?
> 
> > In my understanding this is exactly the purpose of the Debian group on 
> > salsa.
> > As [1] says:
> >  Direct commits to repositories in the Debian group by any Debian
> >  developer are implicitly welcome. No pre-commit coordination
> >  (e.g. merge-request or mail) is expected.
> 
> > [1] 
> > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
> 
> What I'm missing, and maybe this is just me not understanding, is the
> uploads part.  Does that also imply that anyone can just upload?  (And
> what about the minor protocol parts of that, such as what to put into
> Maintainer and Uploaders?)
> 
> But I was wondering if this was what the Salsa Debian group was supposed
> to be and we just haven't really used it very much (possibly because there
> aren't that many volunteers to upload random packages?).

(Of course I can only speak for myself,) but I always understood it that the
Debian group was designed for maintaining packaged together, and in my
interpretation of "maintaining" this includes uploading.

The salsa announcement [2] also more broadly talks about "allowing … to work
on your package"; this wording also implies for me that uploads are welcome…

In this spirit, I did several "Team uploads" already for projects in the
Debian group; nobody complained about that towards me so far…

(Maybe this would be a good opportunity to evaluate the project's oppinion
on this, and then document that in more clear words on the wiki?)

[2] https://lists.debian.org/debian-devel-announce/2017/12/msg3.html

Cheers,
-- 
tobi


> 
> -- 
> Russ Allbery (r...@debian.org)  
> 

Re: Evolving away from source package realms

[Thomas Goirand]

On 10/12/22 09:25, Pierre-Elliott Bécue wrote:

I can understand your train of thoughts, but to be honest with myself,
I'd rather keep the social limitation rather than enforce a technical
limitation that would prevent me to upload any package and force me to
do $process and wait for someone else's being available to validate it
and give me access.

I really think it's not the matter, to me the matter is package
ownership. While new contributors should feel that it's mandatory to
discuss with maintainers, having people clamped so tightly to their
packages that you don't know if these are actually packages or
src:THE_ring is the issue to me.

Cheers! :)


I wouldn't have say it better. +1

Cheers,

Thomas Goirand (zigo)

Re: Evolving away from source package realms

[Russ Allbery]

Tobias Frost  writes:
> On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:

>> Is there some way right now for me to say "any Debian contributor with
>> upload rights should feel free to merge changes and upload this package
>> without needing to consult me at all, and I will subscribe to the
>> packages feed for the package and say something if something happens
>> that I don't like" with a packaging repository on Salsa?  And if not,
>> would that be a good way to start?

> In my understanding this is exactly the purpose of the Debian group on salsa.
> As [1] says:
>  Direct commits to repositories in the Debian group by any Debian
>  developer are implicitly welcome. No pre-commit coordination
>  (e.g. merge-request or mail) is expected.

> [1] 
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group

What I'm missing, and maybe this is just me not understanding, is the
uploads part.  Does that also imply that anyone can just upload?  (And
what about the minor protocol parts of that, such as what to put into
Maintainer and Uploaders?)

But I was wondering if this was what the Salsa Debian group was supposed
to be and we just haven't really used it very much (possibly because there
aren't that many volunteers to upload random packages?).

-- 
Russ Allbery (r...@debian.org)  

Re: Evolving away from source package realms

[Tobias Frost]

On Wed, Oct 12, 2022 at 04:09:54PM -0700, Russ Allbery wrote:

> Is there some way right now for me to say "any Debian contributor with
> upload rights should feel free to merge changes and upload this package
> without needing to consult me at all, and I will subscribe to the packages
> feed for the package and say something if something happens that I don't
> like" with a packaging repository on Salsa?  And if not, would that be a
> good way to start?

In my understanding this is exactly the purpose of the Debian group on salsa.
As [1] says:
 Direct commits to repositories in the Debian group by any Debian developer are
 implicitly welcome. No pre-commit coordination (e.g. merge-request or mail) is
 expected.

[1] 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
 

Re: Evolving away from source package realms

[Russ Allbery]

Pierre-Elliott Bécue  writes:

> I really think it's not the matter, to me the matter is package
> ownership. While new contributors should feel that it's mandatory to
> discuss with maintainers, having people clamped so tightly to their
> packages that you don't know if these are actually packages or
> src:THE_ring is the issue to me.

I think a possible path forward is to provide a way for people to
explicitly opt out of package ownership and then see how much that
movement grows.  We've done various iterations of that in the past (the
Debian group on Salsa, the low-threshold NMU registration), but I feel
like Git plus Salsa provide useful tools to take this several steps
farther that we don't (so far as I know) have a clear way to opt in to.
In part because there are a few possible policies and it's not clear which
one we should pick.

Is there some way right now for me to say "any Debian contributor with
upload rights should feel free to merge changes and upload this package
without needing to consult me at all, and I will subscribe to the packages
feed for the package and say something if something happens that I don't
like" with a packaging repository on Salsa?  And if not, would that be a
good way to start?

Most of the language-specific teams essentially already implement this for
their packages and their team members, I think.

-- 
Russ Allbery (r...@debian.org)  

Re: Evolving away from source package realms

[Johannes Schauer Marin Rodrigues]

Hi,

Quoting Didier Raboud (2022-10-07 15:24:23)
> (This is the continuation of an unspecified thread in the debian-private list 
> that generated enough positive content that I deemed it smart enough to jump 
> off from it, to a public mailing list. I'm not quoting anything from anyone, 
> but there's certainly inspiration from various participants, so thanks for 
> that!)

I have read the thread on debian-private that you are probably referring to
(the "hegemony" thread, right?), but...

> Looking at how Ubuntu is structured (with topic teams) made me wonder if some
> variation of that couldn't reasonably be applied to Debian, by dividing our
> giant set in subsets (topic teams, baskets, ...), under clearer team's
> responsibilities, and onboarding processes.  That would imply that certain
> people would have more power: the "PostgreSQL server" subset team would have
> authority and (technical) upload rights upon their packages. And others would
> have less power: not being able to upload these anymore.  The flip-side of
> such a setup, in which a large set of uploading-DDs would see their power
> over the "PostgresSQL server" set largely reduced, is that they would also
> "care less" (why investigating an RC bug if I can't NMU anyway).  FWIW, I'd
> happily limit my uploading rights to forbid me to upload a Gnome package, a
> kernel package, or a PostgreSQL package, provided that there would be
> documented onboarding processes, should that ever interest me.
> 
> But I argue that we're already _socially_ in such an environment: all 
> contributors (including uploading DDs) not already in any given team go 
> through onboarding processes, Salsa MRs' reviews, vetting and review before 
> they do upload directly (modulo NMUs, of course).  It's just not enforced by 
> the archive.
> 
> The last aspect would also be to completely remove the source-package-level 
> realms; within a subset, there would be no package-specific maintainers or  
> vetoes; disputes would move "out" from source-package-level to subset-level. 
> That's not to say that within-subset disputes wouldn't happen nor could be 
> escalated; it's rather to stipulate that the realms' boundaries wouldn't be 
> the source-packages', but the subset's.
> 
> In the current situation in which there's quite some friction around "merged-
> usr/" (and in the lingering situation around init systems), I'd see a "Debian 
> core" subset made of base-files, libc, authority over the filesystem layout, 
> dpkg, apt; and a "Debian system core" subset with authority over supported 
> and 
> default init systems, kernel, initramfs, firmware*.
> 
> Was I rumbling in my bubble, or does any of this make sense?

I do not think that what you are proposing solves the problems that were
identified in that thread. I think the problem that was identified was, that it
is currently in the power of individual maintainers have too much power over
the packages they maintain. Thus, it is for example possible, that maintainers
block contributions (with patches) of others. I think many in the thread
concluded that maintaining a distribution is a team effort and requires the
contributions and cooperation of many and that source packages cannot be seen
as an entity that can be looked at in isolation.

If I understand what you write correctly, then you propose to put into place a
technical barrier for uploading other people's packages. But that will not
reduce the ownership (or hegemony) of developers over their packages and thus
not address the problems that were identified.

Am I misunderstanding what you are proposing?

Thanks!

cheers, josch

signature.asc
Description: signature

Re: Evolving away from source package realms

[Nilesh Patra]

On Fri, Oct 07, 2022 at 03:24:23PM +0200, Didier Raboud wrote:
> Looking at how Ubuntu is structured (with topic teams) made me wonder if some 
> variation of that couldn't reasonably be applied to Debian, by dividing our 
> giant set in subsets (topic teams, baskets, ...), under clearer team's 
> responsibilities, and onboarding processes.  That would imply that certain 
> people would have more power: [...]

Speaking only for _myself_ here: I see three drawbacks here:

1. I do upload a number of packages, quite frequently spanning across multiple 
teams.
   Now if you allow me to upload packages only from a bunch of teams, and also 
packages that
   sit in debian/ group. The process you state adds extra friction at my end to 
collaborate
   and adhere to more policies than I'd like to.
   My current uploading rights atleast give me the power to do emergency 
uploads, or upload
   when the members of a particular team are on a VAC and I _really_ need to 
fix something.

2. This pertains to people who seek sponsors. The current process for non-DDs 
is to upload
   to mentors.d.n or push to salsa and then ask a DD to upload for them. If you 
divide packages
   in that fashion, a sponsee will have to approach a DD from a particular team 
always. And if the people
   from the said team do not have the time, and some other drive-by sponsor can 
do so, this
   fragmentation prevents them from sponsoring a package. This makes the 
existing lack-of-sponsors problem even worse.

3. If members of a particular team go inactive for a while -- which is not an 
impossibility,
   it becomes extremely hard for someone else to join the team and/or make an 
upload.
   This leads to an even slower process. If you say that gaining upload 
permissions should
   be done at a central level, then that is still a problem since those 
volunteers handling permission requests
   would be bombarded with upload requests.


That being said, I am not against improving the status quo, but I feel 
restricting access in this
way is kinda counter-intuitive.

-- 
Best,
Nilesh


signature.asc
Description: PGP signature

Re: Evolving away from source package realms

[Pierre-Elliott Bécue]

Didier Raboud  wrote on 07/10/2022 at 15:24:23+0200:

> (This is the continuation of an unspecified thread in the debian-private list 
> that generated enough positive content that I deemed it smart enough to jump 
> off from it, to a public mailing list. I'm not quoting anything from anyone, 
> but there's certainly inspiration from various participants, so thanks for 
> that!)
>
> So. We should be having a public discussion about our per-source ownership, 
> _and_ about spread responsibilities.  A long-established specificity of 
> Debian 
> development is that we have had only one, super-powerful, authorization 
> scheme to the archive: become an uploading DD and get unrestricted, 
> unsupervised upload right upon all packages.  We solved the social friction 
> using processes, documentation, etc. (Yes, DM status opened restricted upload 
> rights to limited package sets).  There are two sides to that.
>
> As all uploading DDs _can_ upload, we get (theoretical) built-in failover: 
> when one goes emeritus (the ideal case), they can  be replaced by any other 
> without much process.  We also get low-cost emergency fixups; if I upload 
> something broken just before going (explicitly) VAC, anyone can revert and 
> upload.  Not having explicit barriers in place is (was?) a nice way to reduce 
> administrativia, and to address ownership disputes in the open; the only 
> restrictions on NMUs, orphaning and package salvaging, etc, are social, not 
> technical.  And by the nature of being social, we address them with 
> processes, 
> documentation, policy (and committees enforcing some of the rules).  In other 
> words, no technical barriers prevent me from uploading a broken 
> src:base-files; 
> but I will face social backlash (and possibly administrative measures), 
> because I would have broken agreed-upon social norms.
>
> The flip-side of this is also that we all _care_; as I _can_ upload src:base-
> files, I feel partly responsible for it.  I argue that uploading DDs care 
> about 
> all of Debian packages, not only because they care about Debian, but also 
> because they have the needed authorization (power) to fix any and all of 
> them.  
> What matters is not that the power is exercised, but that it exists.  The set 
> "all Debian source packages" is a concern for all of us; we're one large team 
> for one _very_ large set.  Attempts to split this set has worked by interest-
> groups so far; language-specific, desktop-environment-specific, etc.  (And it 
> has worked quite well for these groups, also because the subsets they care 
> about are reasonably self-contained).  But as we all care, we are also all 
> entitled to opinions (that might be conflicting) about OS-level design 
> decisions which (as was amply demonstrated by this mega-thread) cannot 
> reasonably be addressed by source-level ownership. Deciding that /lib is 
> going 
> to be a symlink cannot (and, for the avoidance of doubt, has not) be a single 
> source package maintainer(s)' decision.  But as things currently work, it 
> ends 
> up being implemented and steered as such, with our source-package-level 
> conflict-handling processes (TC, etc, etc).
>
> So, we have eachothers' backs, and we all care, how to move from there?
>
> Looking at how Ubuntu is structured (with topic teams) made me wonder if some 
> variation of that couldn't reasonably be applied to Debian, by dividing our 
> giant set in subsets (topic teams, baskets, ...), under clearer team's 
> responsibilities, and onboarding processes.  That would imply that certain 
> people would have more power: the "PostgreSQL server" subset team would 
> have authority and (technical) upload rights upon their packages. And others 
> would have less power: not being able to upload these anymore.  The flip-side 
> of such a setup, in which a large set of uploading-DDs would see their power 
> over the "PostgresSQL server" set largely reduced, is that they would also 
> "care less" (why investigating an RC bug if I can't NMU anyway).  FWIW, I'd 
> happily limit my uploading rights to forbid me to upload a Gnome package, a 
> kernel package, or a PostgreSQL package, provided that there would be 
> documented onboarding processes, should that ever interest me.
>
> But I argue that we're already _socially_ in such an environment: all 
> contributors (including uploading DDs) not already in any given team go 
> through onboarding processes, Salsa MRs' reviews, vetting and review before 
> they do upload directly (modulo NMUs, of course).  It's just not enforced by 
> the archive.

I can understand your train of thoughts, but to be honest with myself,
I'd rather keep the social limitation rather than enforce a technical
limitation that would prevent me to upload any package and force me to
do $process and wait for someone else's being available to validate it
and give me access.

I really think it's not the matter, to me the matter is package
ownership. While new contributors should 

Re: Evolving away from source package realms

[Scott Kitterman]

On October 11, 2022 11:40:20 PM UTC, Charles Plessy  wrote:
>Hi Didier,
>
>An interesting side effect of your proposal is that Debian's security
>will be higer as uploading permissions will not be broad by default.
>And I think that a lightweight processe can be designed to allow DDs to
>expand their permissions.
>
>Have a nice day,
>

What fraction of security issues we've had in Debian do you think narrower 
upload permissions would have prevented?

Scott K

Re: Evolving away from source package realms

[Charles Plessy]

Hi Didier,

An interesting side effect of your proposal is that Debian's security
will be higer as uploading permissions will not be broad by default.
And I think that a lightweight processe can be designed to allow DDs to
expand their permissions.

Have a nice day,

-- 
Charles

Re: Evolving away from source package realms

[Scott Kitterman]

On October 10, 2022 7:56:07 AM UTC, Gerardo Ballabio 
 wrote:
>Didier Raboud wrote:
>> The last aspect would also be to completely remove the source-package-level
>realms; within a subset, there would be no package-specific maintainers or
>vetoes; disputes would move "out" from source-package-level to subset-level.
>
>Uhm. This makes me wonder what the real goal of this proposal is.
>
>Is it about restricting the ability of DDs to upload any package
>(something that has never really caused any real issues so far as I'm
>aware)? Or is it really about having a way to work around
>uncollaborative maintainers of specific packages?
>
>If it's the latter, I'm afraid it could have more negative effects
>than positive. While "package-specific maintainership" does have its
>problems, it is essentially what has been keeping Debian working until
>now. People take care of their packages because, well, they're their
>packages. If packages aren't assigned to maintainers anymore, I fear a
>situation of "it's everybody's responsibility, therefore it's nobody's
>responsibility".
>
>There are in fact many team-maintained packages, and that's working
>well, but it works because people *voluntarily* agreed to collective
>maintainership, and those teams are usually rather small anyway, with
>an even smaller number of people taking the lead. Those will still
>have veto power.

I think this is generally correct.  Ultimately, I think moving in the suggested 
direction will ultimately add bureaucracy and take away motivation.

Today, who decides a technical question is relatively straightforward.  In the 
first instance the maintainer (or maintainers + uploaders) decides and people 
who disagree have the option to escalate to the tech ctte.  If we do away with 
maintainers, everything will either be free for all revert wars or some other 
structure will be needed to make decisions.  I don't find the idea of doing the 
same work with additional mandatory bureaucracy at all appealing.

There are circumstances within the archive where having more structure makes 
sense and that's where teams have naturally formed.

I deal with more than enough process and procedure when I'm paid to put up with 
it.  Let's not further bureaucratize Debian.

Scott K

Re: Evolving away from source package realms

[Gerardo Ballabio]

Didier Raboud wrote:
> The last aspect would also be to completely remove the source-package-level
realms; within a subset, there would be no package-specific maintainers or
vetoes; disputes would move "out" from source-package-level to subset-level.

Uhm. This makes me wonder what the real goal of this proposal is.

Is it about restricting the ability of DDs to upload any package
(something that has never really caused any real issues so far as I'm
aware)? Or is it really about having a way to work around
uncollaborative maintainers of specific packages?

If it's the latter, I'm afraid it could have more negative effects
than positive. While "package-specific maintainership" does have its
problems, it is essentially what has been keeping Debian working until
now. People take care of their packages because, well, they're their
packages. If packages aren't assigned to maintainers anymore, I fear a
situation of "it's everybody's responsibility, therefore it's nobody's
responsibility".

There are in fact many team-maintained packages, and that's working
well, but it works because people *voluntarily* agreed to collective
maintainership, and those teams are usually rather small anyway, with
an even smaller number of people taking the lead. Those will still
have veto power.

Gerardo

Re: Evolving away from source package realms

[Barak A. Pearlmutter]

I myself am *very* happy to have other Debian people (DDs, DMs) git
push and dput fixes to any of "my" packages. No need for an MNU or
delay or permission: just do it. Zero friction. In the unlikely event
you do something I'm uncomfortable with I'll just revert it and
discuss.

This has nothing to do with a mono repo. It's a social convention, and
can be done with per-package repos. In fact, I believe the
salsa.debian.org "debian" group is intended for this, with packages
having their packaging repos there treated in roughly the above
fashion. That's where I put my own packages, unless they belong in
some team group.

People interested in this communal maintenance idea should be aware of
the Low Threshold NMU list
https://wiki.debian.org/LowThresholdNmu
which is basically the same idea, and I think may have led to a bit of
confusion about what a repo being in salsa.debian.org/debian/ means.

--Barak Pearlmutter