Re: Evolving away from source package realms
Hi, Quoting Didier Raboud (2022-10-07 15:24:23) > (This is the continuation of an unspecified thread in the debian-private list > that generated enough positive content that I deemed it smart enough to jump > off from it, to a public mailing list. I'm not quoting anything from anyone, > but there's certainly inspiration from various participants, so thanks for > that!) I have read the thread on debian-private that you are probably referring to (the "hegemony" thread, right?), but... > Looking at how Ubuntu is structured (with topic teams) made me wonder if some > variation of that couldn't reasonably be applied to Debian, by dividing our > giant set in subsets (topic teams, baskets, ...), under clearer team's > responsibilities, and onboarding processes. That would imply that certain > people would have more power: the "PostgreSQL server" subset team would have > authority and (technical) upload rights upon their packages. And others would > have less power: not being able to upload these anymore. The flip-side of > such a setup, in which a large set of uploading-DDs would see their power > over the "PostgresSQL server" set largely reduced, is that they would also > "care less" (why investigating an RC bug if I can't NMU anyway). FWIW, I'd > happily limit my uploading rights to forbid me to upload a Gnome package, a > kernel package, or a PostgreSQL package, provided that there would be > documented onboarding processes, should that ever interest me. > > But I argue that we're already _socially_ in such an environment: all > contributors (including uploading DDs) not already in any given team go > through onboarding processes, Salsa MRs' reviews, vetting and review before > they do upload directly (modulo NMUs, of course). It's just not enforced by > the archive. > > The last aspect would also be to completely remove the source-package-level > realms; within a subset, there would be no package-specific maintainers or > vetoes; disputes would move "out" from source-package-level to subset-level. > That's not to say that within-subset disputes wouldn't happen nor could be > escalated; it's rather to stipulate that the realms' boundaries wouldn't be > the source-packages', but the subset's. > > In the current situation in which there's quite some friction around "merged- > usr/" (and in the lingering situation around init systems), I'd see a "Debian > core" subset made of base-files, libc, authority over the filesystem layout, > dpkg, apt; and a "Debian system core" subset with authority over supported > and > default init systems, kernel, initramfs, firmware*. > > Was I rumbling in my bubble, or does any of this make sense? I do not think that what you are proposing solves the problems that were identified in that thread. I think the problem that was identified was, that it is currently in the power of individual maintainers have too much power over the packages they maintain. Thus, it is for example possible, that maintainers block contributions (with patches) of others. I think many in the thread concluded that maintaining a distribution is a team effort and requires the contributions and cooperation of many and that source packages cannot be seen as an entity that can be looked at in isolation. If I understand what you write correctly, then you propose to put into place a technical barrier for uploading other people's packages. But that will not reduce the ownership (or hegemony) of developers over their packages and thus not address the problems that were identified. Am I misunderstanding what you are proposing? Thanks! cheers, josch signature.asc Description: signature
Re: Keysigning in times of COVID-19
Hi Enrico, thanks for bringing this up. Quoting Enrico Zini (2020-08-06 17:54:21) > What do you think could be alternative key signing policies, that would be > acceptable to you, that would not require traveling and meeting face to face? I'm currently in the situation of sponsoring a very skilled prospective new DM with a couple of packages. My mentee is signing all their git commits and git tags as well as their emails to me with the same GPG key. This has now been going on for a few months. So I'm in the situation, that I know that somebody owning a certain private key is either (correct me if I'm wrong): - doing a lot of good work - being impersonated by an evil third party that always intercepts their contributions to Debian (git commits to salsa) as well as their (encrypted!) emails to me and replaces the signature with their own My question to you guys is: how valuable is it, that I (or anybody else) is meeting the individual owning this key in person and indeed verifies (how skilled are *you* in spotting a counterfeit ID?) that a nation state thinks that the person of such name does really exist. What added value does the connection to a government ID give to Debian? Why would it be wrong of me to sign the key of this person? No matter who is behind that key: the person with that key has shown to produce great contributions for a couple of months *or* there is a really dedicated evil person trying some scheme over a really long period of time with me. If the latter is the case, would a person with that much commitment not also be able to fool me with a fake national ID? So in my opinion (and please correct my assumptions if they are wrong), an acceptable key signing policy would also be one, where a prospective DM has shown over several months to produce work that is always signed with the same key and maybe even communicated (for example via email, maybe even encrypted) using that GPG key. Thanks! cheers, josch signature.asc Description: signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
Hi, Quoting Lars Wirzenius (2016-12-06 16:06:30) > On Tue, Dec 06, 2016 at 03:50:12PM +0100, Johannes Schauer wrote: > > Actually, this is a great argument for why this information should be in a > > deb822 field in the source package itself. > > FWIW, I think this is the kind of information that should be kept out > of the source package, since changing it would require an upload and > that's not going to happen for stable. I'd prefer such information be > kept somewhere it's easy to change. why would it be important to change that kind of information for a package in stable? The audience interested in this field is interested in uploads to unstable, so is it not sufficient if the information is up-to-date there? If you want to make a change to stable, then you have to go through the stable release team anyways first. What do you think? cheers, josch signature.asc Description: signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
Hi, Quoting Holger Levsen (2016-12-06 15:15:53) > On Tue, Dec 06, 2016 at 03:08:54PM +0100, Adam Borowski wrote: > > > https://tracker.debian.org/pkg/multistrap > > I see that https://wiki.debian.org/LowThresholdNmu lists you as > > [[JohannesSchauer|Johannes 'josch' Schauer]] while the maintainer field is > > Johannes Schauer <jo...@debian.org>, that obviously breaks a string match. > > the email on the wiki page is also a different one… maybe whoever implemented or understands the algorithm that is used by the PTS to parse the wiki page should precisely explain the conditions used for the matching in said wiki page? Right now I do not see any way to verify whether an entry in the wiki page is actually properly formatted. The fact that I didn't know that there were consumers like the PTS which expect a certain formatting explains why I didn't take great care when I inserted my name into the list. So maybe the wiki page could also get a list of machine consumers at the top? Actually, this is a great argument for why this information should be in a deb822 field in the source package itself. Thanks! cheers, josch signature.asc Description: signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
Hi, Quoting Adam Borowski (2016-12-06 09:36:08) > On Tue, Dec 06, 2016 at 09:18:49AM +0100, Johannes Schauer wrote: > > What I currently find inconvenient about the LowThresholdNmu page is, that > > it > > is external to the source package. So after having found a package I want to > > fix I have to manually look up on that wiki page whether the maintainer is > > fine > > with NMUs and if it applies to the source package at hand. > > I wouldn't even think of making a NMU without looking at the PTS, and that > page states "LowNMU" right to the maintainer's name. cool! That's really helpful! Can we also have that being displayed in the bts where people are usually coming from if they want to fix a bug? Unfortunately, I don't see where it says LowNMU in the pts. For example if I look at my package multistrap, the string LowNMU occurs nowhere: https://tracker.debian.org/pkg/multistrap Thanks! cheers, josch signature.asc Description: signature
Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
Hi,
Quoting Ian Jackson (2016-12-05 23:04:48)
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> > A similar proposal: Have a way of declaring the package to be under
> > collective maintenance (put it under collab-maint on alioth +
> > Maintainer: collect...@debian.org or somesuch?) That'd move closer to a
> > model where individuals don't own that particular package.
I very much like that idea.
What I currently find inconvenient about the LowThresholdNmu page is, that it
is external to the source package. So after having found a package I want to
fix I have to manually look up on that wiki page whether the maintainer is fine
with NMUs and if it applies to the source package at hand. It would be great if
that information could somehow live inside the source package.
People who would favor this approach probably already have their packaging SCM
in collab-maint or use dgit, so I'm more wondering about a good way of how to
encode this information in source packages themselves and what it means to put
it there.
Suppose, we'd just put something like collect...@debian.org into the Maintainer
field. What would it actually mean? Would it be sufficient to mean that the
declarations from the LowThresholdNmu page apply? And would it have to be an
actually active email address? Would it maybe have to be like for team
maintained packages where an actual human address still has to be in the
Uploaders field? I also see some overlap with the packa...@qa.debian.org value
for the Maintainer field.
> This is all very well and good, but frankly, Lars (and the others in this
> conversation) are not the problem. The problem maintainers won't put
> themselves on a LowThresholdAdoption list either.
>
> We already have ways of dealing with maintainers who are simply
> absent or busy, and not actively resisting. Our processes for that
> are rather cumbersome but it is possible to use them effectively.
>
> What we lack is a way of dealing with maintainers who are determined
> not to lose control of their packages. (And I do mean "control".)
I think the thread has derailed here a little bit but I think that Lars and
Tollef are aware that their proposals are orthogonal to the problem you brought
up in your original message. I think this sub-thread is now about how to change
the culture in Debian to one where we are (even more) more encouraging towards
weak-ownership of packages. I took the liberty to adjust the subject line
accordingly.
Thanks!
cheers, josch
signature.asc
Description: signature
Re: Replace the TC power to depose maintainers
Hi, Quoting Holger Levsen (2016-12-02 13:11:05) > I'm just commenting on this single issue (and aspect of it…) here+now… > > On Thu, Dec 01, 2016 at 07:20:36PM +0100, Stefano Zacchiroli wrote: > > On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote: > > > 3. Abolish maintainership entirely. > > This is the obviously right solution. > > while I can see where you are coming from and where you want us to go, > (and while I like the direction…) I'm not sure such a move would be > beneficial, because of unintended consequences: > > motivation. being able to say "I'm the maintainer of $foo" is a *great* > motivation for many. Taking this away *might* cause a lot more harm that > gain. Why would this be taken away? If the majority of recent debian/changelog entries are by you, I would claim that it's no problem for you to still call yourself the maintainer because apparently that's what you are doing: maintaining a package. It's just that others could potentially also upload fixes. But it doesn't take away the work you do or that you are doing most of it. That you are doing most of it will still be visible. Counter example to your argument: People have repeatedly called me "the sbuild maintainer" and that is despite: - my first sbuild upload was only a little more than a year ago - the package is still team maintained - I only added myself to the Uploaders field four weeks ago I agree, it feels great to be called the maintainer of $foo, but in my experience people call you "the maintainer" even if you haven't maintained that thing for a very long time, the package is team maintained and you are not even in the Uploaders field. cheers, josch signature.asc Description: signature
Re: Replace the TC power to depose maintainers
Hi,
Quoting Ian Jackson (2016-12-02 12:43:52)
> Stefano Zacchiroli writes ("Re: Replace the TC power to depose maintainers"):
> > On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> > > 3. Abolish maintainership entirely.
> >
> > This is the obviously right solution.
>
> I can see why this is attractive. But as I say I we need a way to
> deal with disagreements that aren't (for any reason) resolved by
> amicable discussion.
>
> The current resolution to such disagreements is that the "maintainer",
> who is usually the person who produced the previous version, decides.
> This approach has the virtue of stability.
>
> And it is this very rule which is the problem. If you propose to
> solve the stop-energy maintainer deathgrip problem by abolishing
> maintainership entirely, you need to replace it with something.
are you talking about technical disagreements? Isn't that what the TC is for?
In a world without maintainership and multiple people having different ideas
about a technical problem concerning a package, if discussions between them
have lead to no conclusion, would not the TC have the last word about what is
best for the distribution as a whole?
> Otherwise it really will be chaos, with people uploading contra-reverts of
> each others' reverts.
Personally, I doubt that this would happen. In a world without maintainership,
I'd expect anybody doing an upload to do it with the best interest of the
distribution as a whole at heart. If the content of the upload goes against
what other people had in mind, then I'd expect them to discuss and find a
solution. I would not expect the result to be multiple counter-reverting
uploads from the involved parties. That'd just be rude.
> If we simply remove maintainership and say "do as you like" we are actually
> encouraging such hostile behaviour.
I see it differently. If we remove maintainership, then we are telling our
fellow developers that we trust them with the power they wield. So I see saying
"do as you like" not as an encouragement of hostility but as an encouragement
of mutual help and progress.
> I would like to make a counterargument in defence of maintainership. I am a
> believer in stability, and in relying on the judgement of our people.
I believe the same. You are making my argument. :)
> Ownership supports an emotional connection with the work which I think is
> very valuable in a project with many volunteers.
I don't think the emotional connection is lost without the Maintainer field.
The uploader's name will still be in debian/changelog. It will maybe be in the
Uploaders field. It might also be in the dgit history. The "ownership" I feel
by having my name attached somewhere is not lost by allowing more people than
myself to upload.
> Of course there are downsides, but most maintainers - even most sole
> maintainers - in Debian manage their packages well.
I think the same. I think this is the reason why I think that abolishing
maintainership could work well: because the majority of us is doing excellent
work. I believe they will continue to do so whether or not they are given more
privileges over other's packages. In fact, I think that just because most of us
manage our packages well, we'll see an increase in package quality.
It was argued before that if a package is for example team-maintained then that
might mean that because there is no single name attached, nobody feels
responsible to fix bugs in that package and thus a team-maintained package
might loose quality. I don't think that this is the right causality. Sure,
packages are less maintained if nobody cares for them but I don't think that
the "caring" for packages automatically increases by having one's name in the
Maintainer field.
Personally, I don't care for my packages because I have my name in that field
but because I love the software, I love to get more and more acquainted with
the ins and outs of all the technical details the package offers. Because I
love the satisfaction of squashing lintian warnings. Because I love to make
uploads that close lots of bugs. Because I like the satisfaction I get by
knowing that my work just made somebody else's life better. My name will be in
the changelog entries and in the emails I write to the bts. I don't think that
I will take any different amount of care of the packages that currently have me
in the Maintainer or Uploader field if we abolish the former.
> Let me give some personal experience:
>
> I'm the kind of person who always trips over weird edge cases; I have
> high standards of reliability and error handling; and I often feel I
> have a clear vision of what the tool I was using ought to have done.
>
> As a result, over the years and decades I have filed a great many
> bugs. Some of these bugs are extremely obscure. Some of them are
> difficult to fix. Some of them are consequences of erroneous upstream
> design decisions.
>
> In the vast majority of cases my interactions with the maintainers of
>
