Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #12968 > unrolled thread

Evolving away from source package realms

Back to article view | Back to linux.debian.project

Contents

  Evolving away from source package realms Didier Raboud <odyx@debian.org> - 2022-10-07 15:40 +0200
    Re: Evolving away from source package realms Charles Plessy <plessy@debian.org> - 2022-10-12 02:00 +0200
      Re: Evolving away from source package realms Scott Kitterman <debian@kitterman.com> - 2022-10-12 02:40 +0200
        Re: Evolving away from source package realms Charles Plessy <plessy@debian.org> - 2022-10-16 06:40 +0200
          Re: Evolving away from source package realms Tobias Frost <tobi@debian.org> - 2022-10-16 11:30 +0200
          Re: Evolving away from source package realms Nilesh Patra <nilesh@debian.org> - 2022-10-16 11:50 +0200
            Re: Evolving away from source package realms Charles Plessy <plessy@debian.org> - 2022-10-18 00:20 +0200
              Re: Evolving away from source package realms Thomas Goirand <zigo@debian.org> - 2022-10-18 13:10 +0200
                Re: Evolving away from source package realms Russ Allbery <rra@debian.org> - 2022-10-18 16:30 +0200
                  Re: Evolving away from source package realms Thomas Goirand <zigo@debian.org> - 2022-10-19 17:50 +0200
                  Re: Evolving away from source package realms Bastian Blank <waldi@debian.org> - 2022-10-19 20:50 +0200
                Re: Evolving away from source package realms "M. Zhou" <lumin@debian.org> - 2022-10-18 17:30 +0200
    Re: Evolving away from source package realms Pierre-Elliott Bécue <peb@debian.org> - 2022-10-12 09:40 +0200
      Re: Evolving away from source package realms Russ Allbery <rra@debian.org> - 2022-10-13 01:30 +0200
        Re: Evolving away from source package realms Tobias Frost <tobi@debian.org> - 2022-10-13 07:20 +0200
          Re: Evolving away from source package realms Russ Allbery <rra@debian.org> - 2022-10-13 09:20 +0200
            Re: Evolving away from source package realms Tobias Frost <tobi@debian.org> - 2022-10-13 14:50 +0200
          Bug#1021714: lists.debian.org: Request for new mailing list: collab-maint (was: Evolving away from source package realms) Santiago Ruano Rincón <santiagorr@riseup.net> - 2022-10-13 14:30 +0200
            Bug#1021714: lists.debian.org: Request for new mailing list: collab-maint (was: Evolving away from source package realms) Andreas Metzler <ametzler@bebt.de> - 2022-10-16 18:40 +0200
        Re: Evolving away from source package realms "M. Zhou" <lumin@debian.org> - 2022-10-18 04:40 +0200
      Re: Evolving away from source package realms Thomas Goirand <zigo@debian.org> - 2022-10-13 09:20 +0200
    Re: Evolving away from source package realms Nilesh Patra <nilesh@debian.org> - 2022-10-12 10:20 +0200
    Re: Evolving away from source package realms Johannes Schauer Marin Rodrigues <josch@debian.org> - 2022-10-12 11:00 +0200
      Re: Evolving away from source package realms Timo Röhling <roehling@debian.org> - 2022-10-19 20:00 +0200
    Re: Evolving away from source package realms Didier Raboud <odyx@debian.org> - 2022-10-23 16:50 +0200
      Re: Evolving away from source package realms Raphael Hertzog <hertzog@debian.org> - 2023-01-19 10:40 +0100

Page 1 of 2  [1] 2  Next page →

#12968 — Evolving away from source package realms

(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!

[toc] | [next] | [standalone]

#12987

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

[toc] | [prev] | [next] | [standalone]

#12988

On October 11, 2022 11:40:20 PM UTC, Charles Plessy <plessy@debian.org> 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

[toc] | [prev] | [next] | [standalone]

#13000

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.

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

[toc] | [prev] | [next] | [standalone]

#13001

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
on sponsoring, restriction to upload privilieges will likely impair my ability to
contribute to Debian in this areas.

-- 
tobi

[toc] | [prev] | [next] | [standalone]

#13002

[Multipart message — attachments visible in raw view] — view raw

Hi Charles,

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.
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

[toc] | [prev] | [next] | [standalone]

#13004

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

[toc] | [prev] | [next] | [standalone]

#13006

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)

[toc] | [prev] | [next] | [standalone]

#13007

Thomas Goirand <zigo@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
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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#13009

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)

[toc] | [prev] | [next] | [standalone]

#13011

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

[toc] | [prev] | [next] | [standalone]

#13008

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.

[toc] | [prev] | [next] | [standalone]

#12989

[Multipart message — attachments visible in raw view] — view raw

Didier Raboud <odyx@debian.org> 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 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

[toc] | [prev] | [next] | [standalone]

#12992

Pierre-Elliott Bécue <peb@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
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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#12993

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
 

[toc] | [prev] | [next] | [standalone]

#12994

Tobias Frost <tobi@debian.org> 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 (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#12997

On Wed, Oct 12, 2022 at 10:19:28PM -0700, Russ Allbery wrote:
> Tobias Frost <tobi@debian.org> 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/msg00003.html

Cheers,
-- 
tobi


> 
> -- 
> Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>
> 

[toc] | [prev] | [next] | [standalone]

#12996 — Bug#1021714: lists.debian.org: Request for new mailing list: collab-maint (was: Evolving away from source package realms)

[Multipart message — attachments visible in raw view] — view raw

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ó:
> 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

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-collab-maint@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-c-m@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

[toc] | [prev] | [next] | [standalone]

#13003 — Bug#1021714: lists.debian.org: Request for new mailing list: collab-maint (was: Evolving away from source package realms)

On 2022-10-13 Santiago Ruano Rincón <santiagorr@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ó:
[...]
> 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:
[...]

Hello,

I am not sure this is the right way.

* It is already possible to avoid personal e-mail adresses as maintainer
  using team+foo@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'

[toc] | [prev] | [next] | [standalone]

#13005

On Wed, 2022-10-12 at 16:09 -0700, Russ Allbery wrote:
> Pierre-Elliott Bécue <peb@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:
https://lists.debian.org/debian-devel/2022/04/msg00105.html
https://salsa.debian.org/debian/grow-your-ideas/-/issues/34

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.project

csiph-web