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 2 of 2 — ← Prev page 1 [2]

#12995

On 10/12/22 09:25, Pierre-Elliott Bécue wrote:
> I can understand your train of thoughts, but to be honest with myself,
> I'd rather keep the social limitation rather than enforce a technical
> limitation that would prevent me to upload any package and force me to
> do $process and wait for someone else's being available to validate it
> and give me access.
> 
> I really think it's not the matter, to me the matter is package
> ownership. While new contributors should feel that it's mandatory to
> discuss with maintainers, having people clamped so tightly to their
> packages that you don't know if these are actually packages or
> src:THE_ring is the issue to me.
> 
> Cheers! :)

I wouldn't have say it better. +1

Cheers,

Thomas Goirand (zigo)

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

#12990

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

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

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

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

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

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


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

-- 
Best,
Nilesh

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

#12991

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

Hi,

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

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

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

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

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

Am I misunderstanding what you are proposing?

Thanks!

cheers, josch

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

#13010

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

Hi,

* Johannes Schauer Marin Rodrigues <josch@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
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 │
⠈⠳⣄⠀⠀⠀⠀   ╰────────────────────────────────────────────────────╯

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

#13014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thoughts?
OdyX

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

#13154

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

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 <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web