Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Evolving away from source package realms
1 view
Skip to first unread message
Didier Raboud
Oct 7, 2022, 9:40:04 AM10/7/22
to
(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.
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?
Best,
OdyX
P.S. I'll be away from Debian lists next week, so don't take absence of
response for disdain!
P.S.2. Sorry if I mixed "DD" with "uploading DDs"; as we're talking source
packages, it probably went easier without specifying it everytime. Non-
uploading DD, know that your work and opinion is valued and respected!
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.
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?
Best,
OdyX
P.S. I'll be away from Debian lists next week, so don't take absence of
response for disdain!
P.S.2. Sorry if I mixed "DD" with "uploading DDs"; as we're talking source
packages, it probably went easier without specifying it everytime. Non-
uploading DD, know that your work and opinion is valued and respected!
Barak A. Pearlmutter
Oct 8, 2022, 6:20:03 AM10/8/22
to
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
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
Gerardo Ballabio
Oct 10, 2022, 4:00:03 AM10/10/22
to
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.
> 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.
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
Scott Kitterman
Oct 10, 2022, 10:20:03 AM10/10/22
to
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
Charles Plessy
Oct 11, 2022, 8:00:02 PM10/11/22
to
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
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
Scott Kitterman
Oct 11, 2022, 8:40:02 PM10/11/22
to
Scott K
Pierre-Elliott Bécue
Oct 12, 2022, 3:41:07 AM10/12/22
to
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! :)
--
PEB
Nilesh Patra
Oct 12, 2022, 4:20:02 AM10/12/22
to
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: [...]
> 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
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
Johannes Schauer Marin Rodrigues
Oct 12, 2022, 5:01:13 AM10/12/22
to
Hi,
Quoting Didier Raboud (2022-10-07 15:24:23)
(the "hegemony" thread, right?), but...
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
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
> 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!)
(the "hegemony" thread, right?), but...
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
Russ Allbery
Oct 12, 2022, 7:30:03 PM10/12/22
to
Pierre-Elliott Bécue <p...@debian.org> 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
> 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.
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) <https://www.eyrie.org/~eagle/>
Tobias Frost
Oct 13, 2022, 1:20:02 AM10/13/22
to
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.
> 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?
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
Russ Allbery
Oct 13, 2022, 3:20:03 AM10/13/22
to
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?).
Thomas Goirand
Oct 13, 2022, 3:20:03 AM10/13/22
to
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
> 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! :)
Cheers,
Thomas Goirand (zigo)
Santiago Ruano Rincón
Oct 13, 2022, 8:30:03 AM10/13/22
to
Package: lists.debian.org
Severity: wishlist
Dear list masters and fellow Debian peers,
I hereby would like to propose to create a mailing list for
collaborative maintenance.
Name: debian-collab-maint
Rationale:
El 13/10/22 a las 07:02, Tobias Frost escribió:
Other than the salsa Debian group, I think it would be useful to have a
mailing list to share the responsibility of packages, and at the same
time, reduce the personal "ownership" of them. Packages with Maintainer:
debian-co...@lists.debian.org are declared to have an open an
collaborative maintenance. Rules are yet to be defined and discussed
within the project (following this thread?). In any case, concerned
packages have to be in the Salsa Debian group. However, it should be
optional for packages in the Salsa Debian group to have Maintainer:
d-...@l.d.o.
This mailing list would also make it possible to follow and keep track
of bugs and etc of the related packages. I am aware it is currently
possible to individually subscribe to a package's tracker, but the scope
is different from a collaborative maintenance.
Short Description: Debian Collaborative Package Maintenance
Long Description:
List for collaborative maintenance of packages in the Salsa Debian
group:
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
Category: Developers
Subscription Policy: Open
Post Policy: Open
Web Archive: yes
thanks,
-- Santiago
Severity: wishlist
Dear list masters and fellow Debian peers,
I hereby would like to propose to create a mailing list for
collaborative maintenance.
Name: debian-collab-maint
Rationale:
El 13/10/22 a las 07:02, Tobias Frost escribió:
mailing list to share the responsibility of packages, and at the same
time, reduce the personal "ownership" of them. Packages with Maintainer:
debian-co...@lists.debian.org are declared to have an open an
collaborative maintenance. Rules are yet to be defined and discussed
within the project (following this thread?). In any case, concerned
packages have to be in the Salsa Debian group. However, it should be
optional for packages in the Salsa Debian group to have Maintainer:
d-...@l.d.o.
This mailing list would also make it possible to follow and keep track
of bugs and etc of the related packages. I am aware it is currently
possible to individually subscribe to a package's tracker, but the scope
is different from a collaborative maintenance.
Short Description: Debian Collaborative Package Maintenance
Long Description:
List for collaborative maintenance of packages in the Salsa Debian
group:
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group
Category: Developers
Subscription Policy: Open
Post Policy: Open
Web Archive: yes
thanks,
-- Santiago
Tobias Frost
Oct 13, 2022, 8:50:02 AM10/13/22
to
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/msg00003.html
Cheers,
--
tobi
Charles Plessy
Oct 16, 2022, 12:40:03 AM10/16/22
to
Le Wed, Oct 12, 2022 at 12:14:35AM +0000, 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
>
> What fraction of security issues we've had in Debian do you think
> narrower upload permissions would have prevented?
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
Tobias Frost
Oct 16, 2022, 5:30:03 AM10/16/22
to
On Sun, Oct 16, 2022 at 01:06:23PM +0900, Charles Plessy wrote:
> Le Wed, Oct 12, 2022 at 12:14:35AM +0000, 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
> Le Wed, Oct 12, 2022 at 12:14:35AM +0000, 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.
on sponsoring, restriction to upload privilieges will likely impair my ability to
contribute to Debian in this areas.
--
tobi
Nilesh Patra
Oct 16, 2022, 5:50:02 AM10/16/22
to
Hi Charles,
On Sun, Oct 16, 2022 at 01:06:23PM +0900, Charles Plessy wrote:
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
On Sun, Oct 16, 2022 at 01:06:23PM +0900, Charles Plessy wrote:
> Le Wed, Oct 12, 2022 at 12:14:35AM +0000, 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.
> >
> > 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.
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.
Many people do need archive-wide previledges. Tobias gave a rather crisp reason
in their mail.
> Have a nice Sunday,
You too!
--
Best,
Nilesh
Andreas Metzler
Oct 16, 2022, 12:40:03 PM10/16/22
to
On 2022-10-13 Santiago Ruano Rincón <santi...@riseup.net> wrote:
> Package: lists.debian.org
> Severity: wishlist
> Dear list masters and fellow Debian peers,
> I hereby would like to propose to create a mailing list for
> collaborative maintenance.
> Name: debian-collab-maint
> Rationale:
> El 13/10/22 a las 07:02, Tobias Frost escribió:
[...]
> Package: lists.debian.org
> Severity: wishlist
> Dear list masters and fellow Debian peers,
> I hereby would like to propose to create a mailing list for
> collaborative maintenance.
> Name: debian-collab-maint
> Rationale:
> El 13/10/22 a las 07:02, Tobias Frost escribió:
> Other than the salsa Debian group, I think it would be useful to have a
> mailing list to share the responsibility of packages, and at the same
> time, reduce the personal "ownership" of them. Packages with Maintainer:
[...]
> mailing list to share the responsibility of packages, and at the same
> time, reduce the personal "ownership" of them. Packages with Maintainer:
Hello,
I am not sure this is the right way.
* It is already possible to avoid personal e-mail adresses as maintainer
using team...@tracker.debian.org
* Scalability: If this was used for many packages the mailing would just
be too noisy. Take a look at e.g. debian-qa-packages@ldo, which is
imho unreadable.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Charles Plessy
Oct 17, 2022, 6:20:02 PM10/17/22
to
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,
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.
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.
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,
M. Zhou
Oct 17, 2022, 10:40:03 PM10/17/22
to
On Wed, 2022-10-12 at 16:09 -0700, Russ Allbery wrote:
https://lists.debian.org/debian-devel/2022/04/msg00105.html
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
> Pierre-Elliott Bécue <p...@debian.org> 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:
>
> >
>
> 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?
>
https://lists.debian.org/debian-devel/2022/04/msg00105.html
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34
Thomas Goirand
Oct 18, 2022, 7:10:02 AM10/18/22
to
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
> 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.
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)
Russ Allbery
Oct 18, 2022, 10:30:02 AM10/18/22
to
Thomas Goirand <zi...@debian.org> 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
> 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).
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.
M. Zhou
Oct 18, 2022, 11:30:03 AM10/18/22
to
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.
Thomas Goirand
Oct 19, 2022, 11:50:03 AM10/19/22
to
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
> I think there's some merit for being able to
> restrict and expand your own permissions
original proposal.
Cheers,
Thomas Goirand (zigo)
Timo Röhling
Oct 19, 2022, 2:00:03 PM10/19/22
to
Hi,
* Johannes Schauer Marin Rodrigues <jo...@debian.org> [2022-10-12 10:49]:
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 │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
* Johannes Schauer Marin Rodrigues <jo...@debian.org> [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
>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.
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 │
⠈⠳⣄⠀⠀⠀⠀ ╰────────────────────────────────────────────────────╯
Bastian Blank
Oct 19, 2022, 2:50:03 PM10/19/22
to
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
> 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.
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
Didier Raboud
Oct 23, 2022, 10:51:00 AM10/23/22
to
(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.
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
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
> 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*.
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
Gerardo Ballabio
Oct 24, 2022, 6:50:03 AM10/24/22
to
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
> 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)"
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.
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
Raphael Hertzog
Jan 19, 2023, 4:40:03 AM1/19/23
to
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 <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
On Sun, 23 Oct 2022, Didier Raboud wrote:
> (Sorry for the delay in getting back to that thread. #life)
> 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.
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 <her...@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
0 new messages