Re: Security review of tag2upload
Quoting Salvo Tomaselli (2024-06-26 10:29:53) > > I am sure that's also what you meant, Salvo, I just find it quite > > relevant to be explicit that it is the care that need a boost, not the > > amount of signatures. > > Well if you manually check very carefully every line and then don't sign… > it's > harder to discover it got modified. Yes, I agree. We can encourage upstream to... a) sign b) sign what is carefully checked c) carefully check (and not sign) Assuming good faith, I believe that in your earlier email you meant b) although you only wrote a). Now in your followup email you say that c) is not as good. I agree with your earlier, explicit point that a) is good. I agree with your earlier (assumed) implied point, that b) is good. I agree with you new point, that c) is not as good. My point is that *explicitly* encouraging b) is better than *implicitly* encouraging it by explicitly saying only a). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Security review of tag2upload
Quoting Salvo Tomaselli (2024-06-26 09:25:37) > > > > Building a source package is a lot more opaque and gives the attacker a > > lot more room to hide. Adding malicious code to tar to inject something > > into source packages is a lot quieter > > How many packages have a pubkey for the orig file? > > Perhaps we should encourage upstreams to sign more? What I have learned from all this, is that we should not encourage to sign more, but encourage to cautiously sign more. Both ourselves and our upstreams. My point being that signatures have little value if automated or done manually without related examination. I am sure that's also what you meant, Salvo, I just find it quite relevant to be explicit that it is the care that need a boost, not the amount of signatures. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [RFC] General Resolution to deploy tag2upload [and 1 more messages]
Quoting Ian Jackson (2024-06-17 14:13:00)
> Jonas Smedegaard writes ("Re: [RFC] General Resolution to deploy tag2upload
> [and 1 more messages]"):
> > Your WTF seems to be from a false assumption that git is central to
> > Debian package maintenance. It isn't. It is popular, but not central,
> > nor standardized.
>
> git is central to most software maintenance in the world at large.
> Not all, by any means. But, overwhelmingly, most.
>
> In Debian it's unstandardised *unless* you use dgit push or tag2upload.
> Then the git representation *is* standardised, albeit complex.
Has Debian standardized dgit for git source package representation?
Or do you simply mean that dgit is standardized by the dgit developers,
same as various other tools like git-buildpackage arguably has
standardized their various structures as well?
> > The topic of this GR is not streamlining Debian use of git, but allowing
> > a simpler path from existing messy git to acceptance into Debian.
>
> I don't think this is true. tag2upload (like dgit) imposes a taxonomy
> of git approaches, and defines precisely what each of these named
> approaches means.
Oh, if one of the proposers of the GR insists that the GR is indeed about
streamlining Debian use of git, then I'll back off.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: [RFC] General Resolution to deploy tag2upload [and 1 more messages]
Quoting Matthias Urlichs (2024-06-17 13:05:17) > On 17.06.24 12:14, Ian Jackson wrote: > > [1] "precisely the patches in d/patches" turns out to be extremely > > complicated in the general case. Different maintainer tooling > > interprets d/patches differently. dpkg-source and gbp do not agree! > > There are maintainer workflows and git trees with partially > > incompatible notions! > > That's an important point IMHO. > > Say I need to apply a security patch to some package's git tree on > Salsa. How can I be sure to even create the same source tree as the > previous uploader? I don't know which tool the maintainer used, nor the > options supplied to it, so I can't. > > Thus I need to ignore the maintainer's git tree in favor of "apt-get > source", manually apply the fix, upload that to the archive, then apply > the (hopefully) exact same patch to the actual git sources. Sorry but > WTF? [1] It seems you are looking at this backwards: You don't "need to" anything with git or salsa. What you "need to" do, if you want to contribute to a Debian package, is follow whatever is the maintenance style for that package. Your WTF seems to be from a false assumption that git is central to Debian package maintenance. It isn't. It is popular, but not central, nor standardized. The topic of this GR is not streamlining Debian use of git, but allowing a simpler path from existing messy git to acceptance into Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Security review of tag2upload
Quoting Louis-Philippe Véronneau (2024-06-17 07:40:51) > On 2024-06-16 2 h 23 p.m., Russ Allbery wrote: > > > > For the existing source package signatures, a simplified sequence looks > > like this: > > > > human --> (1) dpkg-buildpackage --> (2) debsign --> (3) archive > > > > For tag2upload, a simplified sequence looks like: > > > > human --> (1) Git --> (2) tag2upload --> (3) debsign --> (4) archive > > Please excuse my naiveté, but how do you actually know that your package > "works" with the tag2upload workflow if you're not building anything > locally before pushing? > > By "works", I mean, how have you tested it will build and will pass all > the proper pre-upload tests? As I understand it, neither of above processes ensure that. More accurately, (1) in the first sequence is `dpkg-buildpackage -S` (which might be done as part of a larger process, not called as such, but the *functionality* narrowly relevant for the sequence is only that the human uses a tool to produce a _source_ package (not whatever other tasks the human may or may additionally do). > On my side, I tend to work on a Git tree and when I'm happy with it I > use sbuild to: > > 1. build the source and the binary packages (and thus run build tests) > 2. run Lintian > 3. run autopkgtests > > Only if all of these steps seem OK will I consider signing and uploading > the resulting source package (and yes, in reality what I actually intend > to sign is the Git tree I worked on). > > Implementation notwithstanding, I'd be more than happy to have a "git > $something" replace my use of debsign and dput, but I am genuinely > curious to know why we would make it easier to upload something that > hasn't passed what I believe are important QA steps before uploading? > > Andreas Tille already raised that point in another thread, but the > answer seems to have been that it's already possible. Incentivising such > a behavior doesn't sound positive to me. I rarely call `dpkg-buildpackage -S` directly. Instead I call `debuild`, or some wrapper around that. If tag2upload becomes part of Debian, I would expect debuild and/or some of its wrappers to suppor hooking into tag2upload, for a single command to do both test-building and signing off. In summary, I don't see how this is any different from what we have today. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Eternally paradigmatic Debian discussions...
Quoting Gunnar Wolf (2024-06-15 07:44:04) > It seems Sean's GR (pre-)proposal perfectly fits the bill for most > paradigmatic Debian discussions. From (half-)following the discussion, > (must confess I have >80 pending messages I haven't read, so there > might be some reality check I haven't yet applied), I can say that: > > 1. Nobody really opposes what is being proposed. > >(which makes sense, as tag2upload is barely controversial: What is >being requested is for the project to ask ftp-masters to trust an >automatically-signing key as a valid originator for source >packages. Of course, this key is to be controlled by an auditable >source base, controlled 100% by members of our project) > >(Important mentioning: Nobody is to be forced to use >tag2upload... at least not for the forseeable future) > > 2. Many people interpret that _others_ oppose this proposal because it >opens the door for endangering different workflows or pieces of >infrastructure. > >(But everybody so far says "I'm not saying I want to kill $thing!" >or "It is not me who opposes the idea!") > > 3. While a listmaster has already called for civility, at least once, >this thread "beautifully" shows how we are capable of treating each >other without much civility, but "decorating" our speech in a way >not to make it obvious we belittle and attack others. > >And I think (no evidence!) most of the bad interactions in this >thread come from prior frictions. There is a lot of >finger-pointing, but all people pointed at answer by claiming to be >innocent of the nefarious accusations... > > 4. I understand Sean (and Ian, I pressume) are pushing this GR to >solve a stalemate while negotiating with ftp-masters regarding >implementation details, or something like that. In such case, I >would have expected an ftp-master to explain what is so difficult >in accepting the new proposed tool/workflow. > >In other words: Is there and underlying controversy? Or is it just >we enjoy poking each other? > >In any case... I understand you want to give some "discussion time" >before pushing the process. But, is there something in particular >you are waiting from this discussion? > > This is one of the mails that actually point nowhere, and I fear are > not as constructive... I sat a bit with it half-written, pondering > whether to send it or to delete it. I am deciding to send it because > the interaction patterns we are seeing are quite pathological. I'm > sending this mail as a call, not only not to tell the other party to > fsck off some filesystems, but to stop finger-pointing and > second-guessing. I find your post very helpful, and appreciate your posting it. For example, I recognize my own finger being too pointy - i.e. that I clearly was not clearly on topic, but derailed the conversation somewhat, through my personal, too stubborn views. Thanks a lot for your sprinkling the atmosphere of this mailinglist "room" with a bit of caring-mindset-fairydust. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 23:36:53) > On Wed, 12 Jun 2024 at 22:26, Jonas Smedegaard wrote: > > My point above, reframed to your new context, is that regardless of > > how overwhelmingly large the attack surface of GCC+linux is, the > > attack surface of GCC+linux+Gitlab is much larger, while that of > > GCC+linux+tag2upload is little larger. > > The attack surface of GCC+linux+tag2upload is orders of magnitude > larger than that of TCC+hurd+tag2upload. Are you going to advocate for > that switch to happen? If not, why? Why do you think it's worth to > deprecate Salsa because of its much larger attack surface, but it's > not worth deprecating Linux and GCC for their demonstrably much larger > attack surfaces? Could it be, maybe, perhaps, that a superficial > comparison of perceived attack surfaces alone is not really a good > metric to make a decision? You keep repeating the unsubstantiated accusation that I want Salsa dead. I do not want to kill Salsa. It is not my intention with this conversation to get rid of Salsa. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 22:00:04) > On Wed, 12 Jun 2024 at 15:20, Jonas Smedegaard wrote: > > > > Quoting Luca Boccassi (2024-06-12 15:27:36) > > > On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard wrote: > > > > You apparently find it equally sensible, specifically as a security > > > > measure, a) apply ACLs on an otherwise massively multi-user-write-access > > > > host and b) use a separate far-less-featured host. > > > > > > > > You claim that both setups have equal vulnerabilities. > > > > > > No, I claim they have different sets of vulnerabilities, disadvantages > > > and advantages, and that both can provide the required feature: > > > disallow force pushes/deleting tags. The hardest thing with security > > > is that it requires a constant, ongoing effort, that will never end, > > > and will only get harder. A widely used software like Gitlab is better > > > for this, as is a widely used kernel like Linux. Or are you suggesting > > > such a server should run on Hurd, given it's far-less-featured and > > > thus has a much smaller attack surface than Linux? > > > > No, I am not suggesting the use of the Hurd here, and I am having a hard > > time assuming good faith with the potential undertones of that question. > > > > To answer your convoluted question, I am suggesting that Salsa and > > tag2upload has very different needs (multi-user write versus multi-user > > append-only, drastically simplified), and consequently to not argue that > > reuse of Salsa for hosting tag2upload is a security benefit. > > The argument is about attack surface, number of features, size of code > base, auditability, etc. If you make that argument about the git stack > running on a server, then the same argument applies for every other > component in the same server that interact in any way with the > payload(s) - kernel, libc, compilers, etc. Otherwise you are just > cherrypicking what is convenient, and ignoring what is not. If Gitlab > can't be used in a security-relevant component because it's too big to > audit, then so are the Linux kernel and GCC. My point above, reframed to your new context, is that regardless of how overwhelmingly large the attack surface of GCC+linux is, the attack surface of GCC+linux+Gitlab is much larger, while that of GCC+linux+tag2upload is little larger. > My argument is that having a single system is beneficial for > maintenance costs (fewer platforms, fewer moving parts), for security > (components in widespread usage with heavy commercial backing spending > the big to ensure it's not completely borken), and for > rationalizing and avoiding duplication. Ok, if your argument is no longer that "the same setup can be achieved with repository ACLs, and it would have the same vulnerability" but that security+economy+maintenance combined makes your previous security-only point less relevant to discuss, then I have nothing sensible to contribute to this new path of yours. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 15:27:36) > On Wed, 12 Jun 2024 at 14:15, Jonas Smedegaard wrote: > > You apparently find it equally sensible, specifically as a security > > measure, a) apply ACLs on an otherwise massively multi-user-write-access > > host and b) use a separate far-less-featured host. > > > > You claim that both setups have equal vulnerabilities. > > No, I claim they have different sets of vulnerabilities, disadvantages > and advantages, and that both can provide the required feature: > disallow force pushes/deleting tags. The hardest thing with security > is that it requires a constant, ongoing effort, that will never end, > and will only get harder. A widely used software like Gitlab is better > for this, as is a widely used kernel like Linux. Or are you suggesting > such a server should run on Hurd, given it's far-less-featured and > thus has a much smaller attack surface than Linux? No, I am not suggesting the use of the Hurd here, and I am having a hard time assuming good faith with the potential undertones of that question. To answer your convoluted question, I am suggesting that Salsa and tag2upload has very different needs (multi-user write versus multi-user append-only, drastically simplified), and consequently to not argue that reuse of Salsa for hosting tag2upload is a security benefit. > > I disagree. I think you are mistaken - and no, it is totally > > irrelevant for this accusation whether or not I am a fan of Salsa, > > and whether or not I represent a loud or silent minority or majority. > > This is not about me. > > And I think it is very much relevant, given the obvious end goal of > some individuals is to kill Salsa, which this proposal - as it stands > - would facilitate. Ok, since you insist that it is relevant: Please provide proof to support your claims that a) some "silent minority" exists in Debian aiming to "kill Salsa", and b) I belong to said group, and c) it is "very much relevant" here that I belong to that group. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 14:55:13)
> On Wed, 12 Jun 2024 at 13:47, Jonas Smedegaard wrote:
[...]
> > > > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy
> > > > tag2upload"):
> > > > > As far as I can tell, from what was shared in these documents, the
> > > > > security feature needed is an append-only repository, with safeguards
> > > > > that an individual developer cannot bypass. As far as I can tell, the
> > > > > same setup can be achieved with repository ACLs, and it would have the
> > > > > same vulnerability: an admin with full access to the server can bypass
> > > > > such measures, in either case. Is there something else I am missing?
[...]
> > I read the analysis more that two systems is better than one thousand
> > systems.
> >
> > I.e. centralizing (compared to building done on developers' systems)
> > to a system that can be analyzed (which Gitlab is quite a challenge
> > to do).
>
> "centralize the risk as much as possible" applies to both cases, as
> does the justification for it. And again, Salsa is already part of the
> solution, so this argument doesn't seem very strong to me.
No, not centralizing as much as possible, only as much as sensible.
You apparently find it equally sensible, specifically as a security
measure, a) apply ACLs on an otherwise massively multi-user-write-access
host and b) use a separate far-less-featured host.
You claim that both setups have equal vulnerabilities.
I disagree. I think you are mistaken - and no, it is totally irrelevant
for this accusation whether or not I am a fan of Salsa, and whether or
not I represent a loud or silent minority or majority. This is not about
me.
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 14:40:01)
> On Wed, 12 Jun 2024 at 12:52, Ian Jackson
> wrote:
> >
> > Luca Boccassi writes ("Re: [RFC] General Resolution to deploy tag2upload"):
> > > As far as I can tell, from what was shared in these documents, the
> > > security feature needed is an append-only repository, with safeguards
> > > that an individual developer cannot bypass. As far as I can tell, the
> > > same setup can be achieved with repository ACLs, and it would have the
> > > same vulnerability: an admin with full access to the server can bypass
> > > such measures, in either case. Is there something else I am missing?
> >
> > There is also an assurance question. Salsa is running gitlab, which
> > is an extremely complicated piece of software with very many features.
> > Any one of those features (which are constantly changing) offers an
> > opportunity for compromise of Salsa. Also, we don't have the
> > resources to audit all the code comeing from gitlab upstream.
> >
> > The attack surface of the dgit repos server is much smaller. Its
> > supply chain integrity is much better. So it is much less likely to
> > be compromised. (Also, diversity of implementation is helpful.)
>
> Given we had a very well done and professional security review (thanks
> Russ!), I think we should defer to that and take it into serious
> consideration, and its conclusion seems quite clear to me in this
> regard:
>
> "My security recommendation in this case is therefore to centralize
> the risk as much as possible, moving it off of individual uploader
> systems with unknown security profiles and onto a central system that
> can be analyzed and iteratively improved."
>
> So I don't think this is a good argument. One system is better than
> two. And we need to secure all of it anyway, as Salsa is a component
> of the solution anyway.
I read the analysis more that two systems is better than one thousand
systems.
I.e. centralizing (compared to building done on developers' systems) to a
system that can be analyzed (which Gitlab is quite a challenge to do).
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 13:15:47) > On Wed, 12 Jun 2024 at 12:03, Jonas Smedegaard wrote: > > > > Quoting Luca Boccassi (2024-06-12 12:28:21) > > > On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard wrote: > > > > > > > > Quoting Luca Boccassi (2024-06-12 10:21:40) > > > > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > > > > > > > > > > > Luca Boccassi writes: > > > > > > > > > > > > > And on the implementation details, I really do not like the idea > > > > > > > of > > > > > > > having a competing git forge with Salsa. This dgit server seems > > > > > > > to just > > > > > > > be a ye olde git-web interface. > > > > > > > > > > > > Does it support gitweb? I thought it only supported regular Git > > > > > > operations, but I could be mistaken. > > > > > > > > > > I might be wrong, but this is what this looks like to me (it was > > > > > linked to me on IRC yesterday, wasn't aware of it before): > > > > > > > > > > https://browse.dgit.debian.org/ > > > > > > > > > > > > If this goes forward, in my opinion it should exclusively use > > > > > > > Salsa > > > > > > > as the git server, to avoid duplicating infrastructure. > > > > > > > > > > > > I think you want the Git archive to be entirely separate from Salsa > > > > > > so that it's a reliable source of tracing information. You don't > > > > > > want to support force pushes, for example; the whole point is that > > > > > > it > > > > > > should be append-only, which would be a controversial choice for > > > > > > Salsa but which is fine for the archives of the uploaded packages. > > > > > > I > > > > > > would also want a much smaller attack surface for that type of > > > > > > record > > > > > > than than GitLab. GitLab is designed as a place to do interactive > > > > > > work, not to keep a reliable permanent record. > > > > > > > > > > The git repositories, sure. The git forge? I don't see why. You can > > > > > have these repositories in a separate namespace, which sets strong > > > > > branch and tag protection rules to achieve what you describe. As far > > > > > as I am aware, this is possible to do in Salsa already, it doesn't > > > > > have to be a per-forge rule, it can be per-namespace, I think this is > > > > > possible to achieve in Gitlab. I have not used tag protection rules > > > > > (on gitlab, I used them on github though), but I do regularly use > > > > > branch protection rules on my Salsa repositories. > > > > > > > > > > To be clear, I am exclusively talking about the git forge, as in > > > > > salsa.debian.org, not the git repositories as they might exist on > > > > > Salsa under the debian/ namespace or any other namespace. > > > > > > > > > > Having a separate namespace with strong ACLs seems exactly what you > > > > > want, even if it duplicates the individual repositories (the backend > > > > > git store deduplicates it anyway, so in practice it should be quite > > > > > cheap). Having an entire separate git forge that competes with Salsa > > > > > seems orthogonal to this, and counterproductive for the project. > > > > > > > > I fail to recognize how strong ACLs achieves exactly the same separate > > > > storage on a separate host. Especially when the purpose is to minimize > > > > attack vectors. > > > > > > As per the security review just shared, admin access to Salsa allows > > > to push commits anyway which would get uploaded just the same, and > > > again as per security review, this case benefits from centralizing: > > > one host to maintain, and one set of admins to trust, is better than > > > two. Especially as Salsa is Gitlab, which is maintained upstream and > > > benefits from the many-eyes-and-many-users situation, while a > > > completely custom local git forge reimplementation, other than > > > inevitably suffering from bitrot at some point in the future, like all > > > custom infrastructure, will have the disadva
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 12:28:21) > On Wed, 12 Jun 2024 at 09:35, Jonas Smedegaard wrote: > > > > Quoting Luca Boccassi (2024-06-12 10:21:40) > > > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > > > > > > > Luca Boccassi writes: > > > > > > > > > And on the implementation details, I really do not like the idea of > > > > > having a competing git forge with Salsa. This dgit server seems to > > > > > just > > > > > be a ye olde git-web interface. > > > > > > > > Does it support gitweb? I thought it only supported regular Git > > > > operations, but I could be mistaken. > > > > > > I might be wrong, but this is what this looks like to me (it was > > > linked to me on IRC yesterday, wasn't aware of it before): > > > > > > https://browse.dgit.debian.org/ > > > > > > > > If this goes forward, in my opinion it should exclusively use Salsa > > > > > as the git server, to avoid duplicating infrastructure. > > > > > > > > I think you want the Git archive to be entirely separate from Salsa > > > > so that it's a reliable source of tracing information. You don't > > > > want to support force pushes, for example; the whole point is that it > > > > should be append-only, which would be a controversial choice for > > > > Salsa but which is fine for the archives of the uploaded packages. I > > > > would also want a much smaller attack surface for that type of record > > > > than than GitLab. GitLab is designed as a place to do interactive > > > > work, not to keep a reliable permanent record. > > > > > > The git repositories, sure. The git forge? I don't see why. You can > > > have these repositories in a separate namespace, which sets strong > > > branch and tag protection rules to achieve what you describe. As far > > > as I am aware, this is possible to do in Salsa already, it doesn't > > > have to be a per-forge rule, it can be per-namespace, I think this is > > > possible to achieve in Gitlab. I have not used tag protection rules > > > (on gitlab, I used them on github though), but I do regularly use > > > branch protection rules on my Salsa repositories. > > > > > > To be clear, I am exclusively talking about the git forge, as in > > > salsa.debian.org, not the git repositories as they might exist on > > > Salsa under the debian/ namespace or any other namespace. > > > > > > Having a separate namespace with strong ACLs seems exactly what you > > > want, even if it duplicates the individual repositories (the backend > > > git store deduplicates it anyway, so in practice it should be quite > > > cheap). Having an entire separate git forge that competes with Salsa > > > seems orthogonal to this, and counterproductive for the project. > > > > I fail to recognize how strong ACLs achieves exactly the same separate > > storage on a separate host. Especially when the purpose is to minimize > > attack vectors. > > As per the security review just shared, admin access to Salsa allows > to push commits anyway which would get uploaded just the same, and > again as per security review, this case benefits from centralizing: > one host to maintain, and one set of admins to trust, is better than > two. Especially as Salsa is Gitlab, which is maintained upstream and > benefits from the many-eyes-and-many-users situation, while a > completely custom local git forge reimplementation, other than > inevitably suffering from bitrot at some point in the future, like all > custom infrastructure, will have the disadvantage that nobody else > uses it. This is the reason Alioth is gone, and it's a very good > reason. So your argument is that that strong ACLs achieve exactly the same as separate storage on a separate host, because separate storage on a separate host inevitably leads to bitrot and lack of eyeballs. I rest my case. > > > > That Git archive is not parallel to or competitive with Salsa and > > > > doesn't > > > > provide most of the functionality that Salsa does. It has a different > > > > purpose. > > > > > > I disagree strongly. As we have seen in the recent Salsa thread on > > > d-private, there are a few but very strongly opinionated people who > > > are vehemently against Salsa and would like to see it gone. Having a > > > parallel and competing git forge I fear would give them very strong >
Re: [RFC] General Resolution to deploy tag2upload
Quoting Luca Boccassi (2024-06-12 10:21:40) > On Wed, 12 Jun 2024 at 02:31, Russ Allbery wrote: > > > > Luca Boccassi writes: > > > > > And on the implementation details, I really do not like the idea of > > > having a competing git forge with Salsa. This dgit server seems to just > > > be a ye olde git-web interface. > > > > Does it support gitweb? I thought it only supported regular Git > > operations, but I could be mistaken. > > I might be wrong, but this is what this looks like to me (it was > linked to me on IRC yesterday, wasn't aware of it before): > > https://browse.dgit.debian.org/ > > > > If this goes forward, in my opinion it should exclusively use Salsa > > > as the git server, to avoid duplicating infrastructure. > > > > I think you want the Git archive to be entirely separate from Salsa > > so that it's a reliable source of tracing information. You don't > > want to support force pushes, for example; the whole point is that it > > should be append-only, which would be a controversial choice for > > Salsa but which is fine for the archives of the uploaded packages. I > > would also want a much smaller attack surface for that type of record > > than than GitLab. GitLab is designed as a place to do interactive > > work, not to keep a reliable permanent record. > > The git repositories, sure. The git forge? I don't see why. You can > have these repositories in a separate namespace, which sets strong > branch and tag protection rules to achieve what you describe. As far > as I am aware, this is possible to do in Salsa already, it doesn't > have to be a per-forge rule, it can be per-namespace, I think this is > possible to achieve in Gitlab. I have not used tag protection rules > (on gitlab, I used them on github though), but I do regularly use > branch protection rules on my Salsa repositories. > > To be clear, I am exclusively talking about the git forge, as in > salsa.debian.org, not the git repositories as they might exist on > Salsa under the debian/ namespace or any other namespace. > > Having a separate namespace with strong ACLs seems exactly what you > want, even if it duplicates the individual repositories (the backend > git store deduplicates it anyway, so in practice it should be quite > cheap). Having an entire separate git forge that competes with Salsa > seems orthogonal to this, and counterproductive for the project. I fail to recognize how strong ACLs achieves exactly the same separate storage on a separate host. Especially when the purpose is to minimize attack vectors. > > That Git archive is not parallel to or competitive with Salsa and doesn't > > provide most of the functionality that Salsa does. It has a different > > purpose. > > I disagree strongly. As we have seen in the recent Salsa thread on > d-private, there are a few but very strongly opinionated people who > are vehemently against Salsa and would like to see it gone. Having a > parallel and competing git forge I fear would give them very strong > ammunition to do so: "if the real uploads and the real repositories > are on a separate and independent git forge, why have Salsa at all? > Get rid of it and use the other forge exclusively." I don't follow d-private, but sounds to me like that argument goes both ways - i.e. also "if the real uploads and the real repositories are on (some specially locked down section of) same git forge, why not embrace additional features offered from same vendor of said forge?" - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: recent changes to the CRA address FLOSS community concerns?
Quoting Jonas Smedegaard (2023-12-09 09:53:37) > Quoting Paul Wise (2023-12-09 04:07:45) > > On IRC it was mentioned that there are updates to the CRA that may > > address the concerns of the FLOSS community. > > > > These blogs have updates at the top: > > > > https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ > > > >🥳 > >update, december 2023: The concerns expressed in this blog have been > >heard and are being addressed in the final text. If you read on, do > >so because you are interested in historical context, not because > >you seek an understanding of how the CRA will apply in practice. > > > > https://berthub.eu/articles/posts/eu-cra-best-open-source-security/ > > > >UPDATE: On December 1st the EU agreed on a version of the Cyber > >Resilience Act that appears to have substantially addressed the > >concerns in the post below. Further analysis awaits, but do know > >that the text that follows is now mostly of historical interest! > > > > Does anyone have any more info about the changes? > > As I understand it, a good source for this is EDRi, but apparently they > have no news yet about the December 1st decision - I would expect news > about that to appear here: > https://edri.org/our-work/the-cyber-resilience-act-how-to-make-europe-more-digitally-resilient/ ...or here: https://edri.org/our-work/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: recent changes to the CRA address FLOSS community concerns?
Quoting Paul Wise (2023-12-09 04:07:45) > On IRC it was mentioned that there are updates to the CRA that may > address the concerns of the FLOSS community. > > These blogs have updates at the top: > > https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/ > >🥳 >update, december 2023: The concerns expressed in this blog have been >heard and are being addressed in the final text. If you read on, do >so because you are interested in historical context, not because >you seek an understanding of how the CRA will apply in practice. > > https://berthub.eu/articles/posts/eu-cra-best-open-source-security/ > >UPDATE: On December 1st the EU agreed on a version of the Cyber >Resilience Act that appears to have substantially addressed the >concerns in the post below. Further analysis awaits, but do know >that the text that follows is now mostly of historical interest! > > Does anyone have any more info about the changes? As I understand it, a good source for this is EDRi, but apparently they have no news yet about the December 1st decision - I would expect news about that to appear here: https://edri.org/our-work/the-cyber-resilience-act-how-to-make-europe-more-digitally-resilient/ - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Possible draft non-free firmware option with SC change
Quoting Simon Josefsson (2022-09-08 11:29:07) > Russ Allbery writes: > > > Possible wording, which includes the existing option A verbatim: > > Thanks, I prefer this approach over Steve's initial proposal: it solves > the problem that we would override a foundational document with a GR > without the required 3:1 majority. > > I'm worried that if we publish only non-free installers, people will > rightly be quite confused what the Debian project thinks about the > meaning of the DSC/DFSG. I would personally believe that publishing > non-free content as part of the Debian system will violate DSC/DFSG even > if Steve's GR passed and were implemented: a 1:1 GR should not be > sufficient to override the meaning of a foundational document. > > > We will publish these images as official Debian media, replacing the > > current media sets that do not include non-free firmware packages. > > Like Steve's variant triggered Gunnar's modification to allow for both > free and non-free installers to be published concurrently, what do you > think about: > > 1) Having two variants of your text -- one that replaces the free > installer with a new non-free installer, and one that says we will > publish both free and non-free installers? > > 2) Remove the paragraph, effectively making your proposal orthogonal > to the decision which images are published? This could be up to the > individual developers to decide. Some people may want to work on a > free installer, and some people may want to work on a non-free > installer, and there doesn't necessarily have to be a conflict between > those two interests. > > I believe the Debian project is permitted to publish non-free installers > under the current DSC/DFSG (which it actually is doing today; just > hidden), but according to the DSC it is not part of the Debian system. > > /Simon FWIW, I fully agree with Simon Josefsson on the above. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-09-07 20:31:34) > On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote: > > I think the problem is with "non-free section". I think Steve looks at > > that like the non-free-firmware section is now allowed. I suggest you > s/now/not/ > > just rewrite it as: "containing non-free software from the Debian > > archive". > > Hi Kurt, > > Yes, let's do that, thanks. So here is the adapted proposal C: > > = > > The Debian project is permitted to make distribution media (installer images > and live images) containing non-free software from the Debian archive > available > for download alongside with the free media in a way that the user is informed > before downloading which media are the free ones. > > = > > The modification: > Old: containing packages from the non-free section of the Debian archive > New: containing non-free software from the Debian archive > > The old phrase was misunderstood as if this proposal would be opposing the > addition of a new section named non-free-firmware. The new phrase better > reflects that software in section non-free-firmware is also covered. > > Then why not simply mention section non-free-firmware? Well, this proposal is > meant to be more future proof. This proposal is applicable to an installer > using the non-free-firmware section, and also to the existing non-free > installer. And to any future designs of non-free installers. > > My subjective comparison of the available proposals so far: > > - Proposal A replaces the free installer by one containing non-free firmware. > - Proposal B gives the free installer less visibility than the non-free one. > - Proposal C keeps the free installer and no longer hides the non-free ones. > - Proposal D would be equivalent to NOTA in my understanding. > > Proposal C could use some more seconding. If you find that proposal C is a > valid option on the ballot (regardless of what you'll later vote for), then > you're most welcome to add your seconding. Seconded. Thanks! -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-09-07 00:27:40) > On Tue, Sep 06, 2022 at 11:00:25PM +0200, Kurt Roeckx wrote: > > On Tue, Sep 06, 2022 at 08:33:51PM +0200, Bart Martens wrote: > > > On Tue, Sep 06, 2022 at 05:26:10PM +0100, Steve McIntyre wrote: > > > > On Tue, Sep 06, 2022 at 06:15:21PM +0200, Bart Martens wrote: > > > > >On Sun, Sep 04, 2022 at 03:43:36AM +0700, Judit Foglszinger wrote: > > > > >> > I hereby propose the following alternative text to Steve's > > > > >> > original proposal. > > > > >> > > > > > >> > = > > > > >> > > > > > >> > The Debian project is permitted to make distribution media > > > > >> > (installer images > > > > >> > and live images) containing packages from the non-free section of > > > > >> > the Debian > > > > >> > archive available for download alongside with the free media in a > > > > >> > way that the > > > > >> > user is informed before downloading which media are the free ones. > > > > >> > > > > > >> > = > > > > >> > > > > >> Wondering if this should be s/non-free section/non-free-firmware > > > > >> section/ > > > > > > > > > >Thanks for asking. The short answer is no. I kept my proposal very > > > > >short, > > > > >keeping the focus on the smallest possible action we can do for > > > > >helping those > > > > >users that need non-free firmware: allowing ourselves to advertise > > > > >non-free > > > > >installers just as visible as our free installer. Moving non-free > > > > >firmware to a > > > > >separate section might be useful, but it is in my view not part of that > > > > >smallest possible action. So what's my position on such new section? > > > > >Well, what > > > > >is not mentioned is not proposed and not opposed. That's all. - B. > > > > > > > > Argh. So this does *not* work with the plan that we have *already > > > > started*, where we're going to move firmware things to > > > > non-free-firmware instead. Please switch to "non-free and/or > > > > non-free-firmware sections" in your text. > > > > > > I'm surprised. Please read what is written. Proposal C leaves open > > > whether such > > > new section would be added in the future. So if proposal C would win, > > > then the > > > started work you describe can continue. Proposal C uses the term > > > "non-free" > > > because that is where all non-free packages are still residing today. > > > > I think the problem is with "non-free section". I think Steve looks at > > that like the non-free-firmware section is now allowed. > not > > He wants "non-free-firmware section" mentioned in proposal C, see above. > > > I suggest you > > just rewrite it as: "containing non-free software from the Debian > > archive". > > That would indeed leave out the existing section name. I'll consider it. If the purpose of this option is to not shift where the line is drawn regading Debian understanding of what is Free and what is not, then I suggest a "slightly" different wording of "containing software that is free according to The Debian Free Software Guidelines". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Kurt Roeckx (2022-09-03 20:28:35) > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: > > As far as I can tell, both Steve's and Gunnar's proposal would make > > Debian less of a free software operating system than it is today. That > > makes me sad. My preference for an outcome would be along the following > > lines. > > > > == > > > > We continue to stand by the spirit of the Debian Social Contract §1 > > which says: > > > >Debian will remain 100% free > > > >We provide the guidelines that we use to determine if a work is > >"free" in the document entitled "The Debian Free Software > >Guidelines". We promise that the Debian system and all its components > >will be free according to these guidelines. We will support people > >who create or use both free and non-free works on Debian. We will > >never make the system require the use of a non-free component. > > > > Therefor we will not include any non-free software in Debian, nor in the > > main archive or installer/live/cloud or other official images, and will > > not enable anything from non-free or contrib by default. > > I can interprete that as having non-free available and installed by default > is acceptable, as long as there is a way not to use the non-free part. > > > We also continue to stand by the spirit of the Debian Social Contract §5 > > which says: > > > >Works that do not meet our free software standards > > > >We acknowledge that some of our users require the use of works that > >do not conform to the Debian Free Software Guidelines. We have > >created "contrib" and "non-free" areas in our archive for these > >works. The packages in these areas are not part of the Debian system, > >although they have been configured for use with Debian. We encourage > >CD manufacturers to read the licenses of the packages in these areas > >and determine if they can distribute the packages on their CDs. Thus, > >although non-free works are not a part of Debian, we support their > >use and provide infrastructure for non-free packages (such as our bug > >tracking system and mailing lists). > > > > Thereby re-inforcing the interpretation that any installer or image with > > non-free software on it is not part of the Debian system, but that we > > support their use and welcome others to distribute such work. > > As you indicate yourself, this is an interpretation of the SC. I would > really prefer that such a question was not open to interpretation and > that the SC was changed to make it more clear what we mean. > > I don't actually understand what this part of your text is saying. Are > you saying that an image with non-free software on it is non-official > because it's not part of the Debian system? That is not something I read > in that text. I think the key to understanding that paragraph is an implied assumption that some installer *is* considered part of the Debian system - i.e. "a system of installer and installable packages" (which is different from "an operating system resulting from executing an installer"). I worry that the multiple meanings of "system" in ballot texts will lead to confusion/frustration over how to vote and how to interpret the result of the vote. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Holger Levsen (2022-09-01 18:40:30) > On Thu, Sep 01, 2022 at 06:02:38PM +0200, Simon Richter wrote: > > A large part of installations now run inside virtual machines and have no > > use for device firmware. > > yes. > > > Having a free-software-only installer is an easy > > way for image builders to ensure that anything they build will be > > redistributable. > > no. if you build images, you don't use d-i but fai, debuerreotype, mmedebstrap > debootstrap or your-custom-script-being-used-since-1997 or something else, but > hardly anyone uses d-i for this use-case. I suspect that the above response provides a clue to why some find it important to label an install image as "official" and others find that irrelevant: I am the developer of one such bootstrapping tool - boxer - but I consider my tool stable only when it can mimick the installation as done by debian-installer. My tool is far from that goal, but that goal nevertheless exists for my view on what is a canonical Debian system: A system spawned using official Debian install process. When you use debootstrap (which for *most* parts is the canonical tool) then you are left with a few files missing (at some point that included /etc/resolv.conf and /etc/apt/sources.list) and filing a bugreport that packages behave weirdly for a system with those core files missing will most likely lead to that bugreport being quickly closed as not-a-bug. Which is the reason that I consider debian-installer an important part of our main deliverable. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Russ Allbery (2022-08-31 18:27:07) > Stefano Rivera writes: > > > Reading this in LWN reminds me that I would don't agree with this > > interpretation. > > > I'd probably vote both the 3:1 option and the 1:1 above NOTA. This is > > because I believe that if enough of us agree, we should update the > > Social Contract to explain how our non-free-firmware section works, and > > what the images provide. > > My concern is that this in proposal A: > > We will publish these images as official Debian media, replacing the > current media sets that do not include non-free firmware packages. > > and this in the Social Contract: > > The packages in these areas are not part of the Debian system, > although they have been configured for use with Debian. > > fit together oddly. I think I can see the reasoning behind why folks > don't believe they conflict, but I must admit that my first reaction is > that they conflict. I think the implication of them not conflicting is > that our official installers are not part of the Debian system? Which > seems like an odd conclusion to me. > > I don't really want to be the proponent of an option here, but I'm a bit > worried about not addressing this head-on. So far, no one else who > supports including non-free firmware in the installer (as I do) has also > indicated that this bothers them, though, which to me argues against > adding yet another option for something that maybe only I care about. > > (Proposal B and proposal C both avoid this problem. I personally prefer > proposal A, though.) Can you elaborate on how you support including non-free firmware in the installer *and* find the quoted paragraphs in conflict? Because I _want_ to support an installer as proposed in option A *except* that very conflict. The only way I could see to solve that conflict (other than interpreting the official installer as not part of Debian) was to keep the free-only installer around for purity reason even though generally we would promote another unofficial installer (and here the word "official" refers to what is treated as formally our main project deliverable). I expect your elaborating would help me see more possibilities. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-08-26 18:03:30) > On Fri, Aug 26, 2022 at 04:18:19PM +0200, Jonas Smedegaard wrote: > > Quoting Bart Martens (2022-08-26 10:02:16) > > > On Fri, Aug 26, 2022 at 07:06:01AM +0200, Jonas Smedegaard wrote: > > > > [...] it lacks a detail I find crucial: > > > > Explicitly spelling out whether or not images containing non-free bits > > > > are official part of Debian or not. Personally I find it obvious that > > > > anything that would not be allowed into main also would not be treated > > > > as official part of Debian, > > > > > > I share the same concern as you: Steve's proposal would mean that > > > installers > > > containing non-free firmware become official part of Debian. My text does > > > not. > > > > > > > If Bart chose to extend the proposal to include that such media > > > > containing non-free bits (although permitted "alongside with the free > > > > media) would *not* be considered official part of Debian, then I would > > > > endorse the amended proposal. > > > > > > That would be repeating what's already true. My text includes only things > > > that > > > I propose to change. So what is off/unofficially today, remains that. > > > It's like > > > "the name of the project remains Debian". Why would I mention that. > > > > > > Does this cover your concern? > > > > It clarifies that my reading matches your intended reading. Thanks! > > Haa wonderful. > > > Unfortunately it does not cover my concern that the text is ambiguous - > > i.e. despite intent your choice of words can lead voters to vote for > > this text but with varying expectations, which is a very bad situation. > > What exactly in my text do you mean? The part you *didn't* include (so I cannot point at it or quote it) ;-) > > > > I still urge you to make explicit what will not change. Perhaps borrow > > from Simons text, if you (like me) like that? > > Simon Richter's text would permit the Debian project to replace the free > installer by a non-free one. My text clearly mentions that the free installer > is still there. Didn't you prefer the free installer to remain available? Ha! Indeed Simon Richter's text omit explicitly mentioning that a non-free installer is in _addition_ to the already free one - although that intent is clear from his more elaborate text before the concrete draft ballot text. ...or paraphrased in your style: His text doesn't say "replace". Perhaps you see now - through an example not your own - how being explicit helps avoid ambiguity? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Jonas Smedegaard (2022-08-26 16:18:19) > I still urge you to make explicit what will not change. Perhaps borrow > from Simons text, if you (like me) like that? ...Simon Richter! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-08-26 10:02:16) > On Fri, Aug 26, 2022 at 07:06:01AM +0200, Jonas Smedegaard wrote: > > [...] it lacks a detail I find crucial: > > Explicitly spelling out whether or not images containing non-free bits > > are official part of Debian or not. Personally I find it obvious that > > anything that would not be allowed into main also would not be treated > > as official part of Debian, > > I share the same concern as you: Steve's proposal would mean that installers > containing non-free firmware become official part of Debian. My text does not. > > > If Bart chose to extend the proposal to include that such media > > containing non-free bits (although permitted "alongside with the free > > media) would *not* be considered official part of Debian, then I would > > endorse the amended proposal. > > That would be repeating what's already true. My text includes only things that > I propose to change. So what is off/unofficially today, remains that. It's > like > "the name of the project remains Debian". Why would I mention that. > > Does this cover your concern? It clarifies that my reading matches your intended reading. Thanks! Unfortunately it does not cover my concern that the text is ambiguous - i.e. despite intent your choice of words can lead voters to vote for this text but with varying expectations, which is a very bad situation. I still urge you to make explicit what will not change. Perhaps borrow from Simons text, if you (like me) like that? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Simon Richter (2022-08-26 15:01:41) > IMO: Both installers should be on the same download page, with a brief > explanation on who should select which (like we used to have in package > descriptions), and possibly a longer page explaining this in more detail. [...] > Key design points: > > - two columns, side-by-side > - avoiding the word "official" completely > - the DFSG and DSC have a prominent place and are set in contrast with > the non-free images [...] > I'm not entirely sure what this would translate to in GR terms, probably > something along the lines of > > --- > Debian recognizes that some modern hardware requires firmware components > that do not fulfill the DFSG, and that these may be needed at > installation time. As our priorities are our users, and free software, > we provide an installer image that includes these components, and inform > users that these, like the "non-free" archive component, are not covered > by the Debian Social Contract and provided on a best-effort basis. > --- > > This, IMO, resolves the conflict with the DSC by clarifying that we are > making an exception here and why, and highlights that we still do not > believe our users' needs are or can be adequately met by non-free software. Thanks a lot, Simon. I would vote for a proposal like the above. What I mean by that is (not that I think we should all post "me too" posts here but) since I have strongly ben in favor of using "offficial" label to indicate what we as project can support, I agree that this is an approach that abandons such label yet ensures explicitly in the text we vote on that "non-free" will be clearly communicated to our users. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Steve McIntyre (2022-08-26 00:21:20) > On Wed, Aug 24, 2022 at 09:40:24AM +0800, Paul Wise wrote: > > > >The problem is that the vendors for most devices that include the Intel > >hardware require Intel signatures on the firmware binaries. > > > >Some devices (Intel based Chromebooks and UP boards) allow firmware > >binaries to be signed by a "community" private key that is public. > > > >In the future Intel may enable a scenario similar to Secure Boot's > >Machine Owner Key setup, where device owners can add new signing keys. > > > >https://github.com/thesofproject/sof/issues/5814 > > > >In that situation, Debian could sign the audio firmware binaries > >instead and allow users to sign their own modified firmware binaries. > > Yup, that would be a lovely big win! > > >> The free installer is ideal for virtualisation only because it's > >> sitting on top of a bunch of idealised hardware. > > > >It could also be useful for devices that run libre firmware, such as > >Raptor Computing's ppc64el devices, although Debian does not have > >packages of the libre firmware projects for these devices so in > >practice it isn't yet useful for those scenarios. > > Right. > > I'd prefer us not to get dragged down the "users just need to pick the > right hardware" path. That way potentially lies a (slightly snobbish?) > "you chose wrong, try harder" message that will just push users (and > eventually developers) to other distros. > > There are always going to be machines that we can't/won't be able to > support, but when the vast majority of current laptops don't function > sensibly without non-free firmware I think we have to adapt to reality > in supporting our users. I agree with the above. (I don't recognize anyone dragging us down said path in this thread, but I could perhaps be perceived like that, which is the reason I respond here) I see two ways that we can "adapt to reality", however: a) We point our users up front to non-free components they likely need b) We give users up front what they likely need Problem I see in the second approach is that we then effectively make it *harder* for those wanting to prioritize Free Software to do so, which in my opinion goes against a core principle of our community. Let's promote non-free installer more aggressively, but please let's explicitly label it as not part of the product we claim is 100% free. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Jonas Smedegaard (2022-08-24 19:14:26) > Quoting Bart Martens (2022-08-24 10:12:48) > > = > > > > The Debian project is permitted to make distribution media (installer images > > and live images) containing packages from the non-free section of the Debian > > archive available for download alongside with the free media in a way that > > the > > user is informed before downloading which media are the free ones. > > > > = > > Seconded. Thanks for proposing this alternative, Bart. I hereby withdraw my second for the above proposal. Reason is that I now realize that it lacks a detail I find crucial: Explicitly spelling out whether or not images containing non-free bits are official part of Debian or not. Personally I find it obvious that anything that would not be allowed into main also would not be treated as official part of Debian, but I have learned that others in the team find it equally natural to apply a different reasoning, and I find the distinction crucial. Sorry for my earlier sloppy endorsement. If Bart chose to extend the proposal to include that such media containing non-free bits (although permitted "alongside with the free media) would *not* be considered official part of Debian, then I would endorse the amended proposal. Oh, and since some has discussed abolishing the word "official", I am quite open to using a different word instead, that covers the same as I have meant all along in this thread: (not products released by others than the Debian organisation as happened decades ago, but) products released by the Debian organisation itself *and* considered part of our main product "Debian", i.e. in the spirit of our "main" archive section. I feel my abilities to express myself sharply is weak. That's the reason I don't put together a proposal on my own. I appreciate *all* proposals put forward - I recognize quite some work has been put into all of them - thanks to all contributors! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-08-24 23:08:12) > On Wed, Aug 24, 2022 at 07:14:26PM +0200, Jonas Smedegaard wrote: > > Quoting Bart Martens (2022-08-24 10:12:48) > > > = > > > > > > The Debian project is permitted to make distribution media (installer > > > images > > > and live images) containing packages from the non-free section of the > > > Debian > > > archive available for download alongside with the free media in a way > > > that the > > > user is informed before downloading which media are the free ones. > > > > > > = > > > > Seconded. Thanks for proposing this alternative, Bart. > > > > In my view, this alternative and the one proposed by Simon achieve > > technically the same > > Really? My text is meant to cover the concerns of both Simon and Steve. I > share Simon's concern on keeping free and non-free strictly separate, and I > also share Steve's concern on users needing non-free firmware for smoothly > installing Debian on their hardware. Perhaps I impose too much wishful thinking into these proposals, but as I read it, Simons "we will not include any non-free software in Debian" do not exclude making a [non-free] installer image available for download alongside free media [e.g. by linking prominently from our main page to a non-free archive section]. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Bart Martens (2022-08-24 10:12:48) > = > > The Debian project is permitted to make distribution media (installer images > and live images) containing packages from the non-free section of the Debian > archive available for download alongside with the free media in a way that the > user is informed before downloading which media are the free ones. > > = Seconded. Thanks for proposing this alternative, Bart. In my view, this alternative and the one proposed by Simon achieve technically the same but communicated vastly different - which to me is (unfortunately) a sensible reason to have them both on the ballot. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Gunnar Wolf (2022-08-23 19:06:50) > Debian should try to cater (more) for [less-technical] users, becauser > if we reject newbies, they will take the curiosity somewhere else I wholeheartedly agree. I don't think anyone here disagrees wuth that. What I disagree with is that we should move away from Debian Social Contract #1 by redefining the official installer as no longer a component of Debian. Yes, I dare say that that is redefining: why else have we avoided non-free bits in the installer till now, if not because we consider it part of Debian-the-thing-we-promised-to-stay-100%-free (as opposed to Debian-the-archive-that-has-had-non-free-bits-for-ages)? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Ansgar (2022-08-23 19:44:17) > > On 2022-08-23 18:50, Jonas Smedegaard wrote: > > > (I only see that being possible by treating the install image as not > > > part of Debian, which I consider an unacceptable interpretation). > > For me installation media are more or less just a glorified non-tarball > of archive contents. So I apply the same standards I would apply to a > tarball of the Debian archive (which would include non-free). So you do not consider installation media part of Debian? > Though I understand some people would like if non-free was removed from > the archive as well (possibly to a separate archive). I don't want non-free removed from the archive, and I would appreciate if we could avoid expanding the topic of this discussion. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Holger Levsen (2022-08-23 17:33:27) > On Tue, Aug 23, 2022 at 05:04:49PM +0200, Jonas Smedegaard wrote: > > I would find it problematic if the official way to install Debian > > *required* a non-DFSG image. > > would you also find it problematic if there were *two* official > images, a "free one" (as we know it) and a "free one plus firmwares"? As I laid out my reasoning (which you partly snipped), I see no way that could be achieved. Do you? I mean, DSC#1 says that "Debian will remain 100% free" - how is that possible if an official part of Debian is omitted? Or how is it possible for the firmware-containing image to be free? (I only see that being possible by treating the install image as not part of Debian, which I consider an unacceptable interpretation). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Philip Hands (2022-08-23 10:44:55) > Jonas Smedegaard writes: > > > Quoting Tobias Frost (2022-08-22 15:57:01) > >> On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote: > >> > Ansgar writes: > >> > > >> > > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: > >> > >> Do we need to update the Debian Social Contract for that? > >> > >> Specifically paragraph 1, which currently reads > >> > >> > >> > >> Debian will remain 100% free > >> > > > >> > > No. Just like we don't need to update the Debian Social Contract for > >> > > having https://deb.debian.org/debian/pool/non-free/: we just ship > >> > > additional files that might be useful for people having specific > >> > > hardware. > >> > > >> > I disagree -- what is being proposed here is to replace our current > >> > DSC-compatible free software installer images with non-free. That goes > >> > significantly further than what the spirit of DSC§5 suggests. > >> > >> It not being replaced; there are just additional bits in there which > >> help people to actually be able to install Debian on some modern machines. > >> > >> The guarantee in SC1 that we will never *require* those non-free bits, as > >> writen > >> out in "We will never make the system require the use of a non-free > >> component." > >> This GR does not violate this promise. > > > > I understand how we will not require non-free bits getting *installed*. > > > > The way I see it, with this change we will require non-free bits for > > *distribution* of our system, because our official installer will now > > include non-gree bits. > > Would those arguing for the availability of the 100%-free installer find > it acceptable if there was a way of cleansing the non-free bits from the > includes-nonfree-firmware installer images? > > I'd guess that one could put the non-free bits on the end of the image, > as an additional session, or perhaps just mark them in the image, and > then reasonably trivially trim them off, or blank them out. > > We could then generate the firmware-included images, but make the > cleansed ones available on-line by having a server-side script trim out > the non-free bits on the fly. > > If that still makes you feel dirty, because the free bits were once > next-door to some non-free bits, would it make any difference if the > resulting images could be built reproducibly without access to any of > the non-free components? > > I'm mostly asking this to find out where people's lines are, but also in > the hope that we could come up with a compromise that allows us to get > away from the enthusiasm sapping situation where the debian-cd team is > required to make images that they know are sub-optimal for many of our > users. Thanks, Phil, for "reaching out". I view the official Debian install image as a component of Debian, and consequently if the (only) official Debian install image were to contain non-free bits then we would violate DSC#1. It is my understanding that those viewing this move to include non-free bits in the official Debian install image consider the install image *not* one of "its components" as defined in DSC#1. I would find it problematic if the official way to install Debian *required* a non-DFSG image. To clarify: I would *not* find it problematic if an image containing non-free bits were produced and promoted more prominently by us, as long as it would remain *unofficial* - i.e. a DFSG-compliant image would continue to be provided and supported. As I understand it, your first suggestion above (building image with non-free bits but in a way that supports stripping again afterwards) would not address my concern, but the second one might (if actually done officially, but not if offered only as an unofficial option). I hope that my concern is clear, that you recognize it as real (not me being a lunatic), and that we can address the concern in a way that does not burden the debian-cd team. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Simon Josefsson (2022-08-23 10:39:57) > == > > We continue to stand by the spirit of the Debian Social Contract �1 > which says: > >Debian will remain 100% free > >We provide the guidelines that we use to determine if a work is >"free" in the document entitled "The Debian Free Software >Guidelines". We promise that the Debian system and all its components >will be free according to these guidelines. We will support people >who create or use both free and non-free works on Debian. We will >never make the system require the use of a non-free component. > > Therefor we will not include any non-free software in Debian, nor in the > main archive or installer/live/cloud or other official images, and will > not enable anything from non-free or contrib by default. > > We also continue to stand by the spirit of the Debian Social Contract �5 > which says: > >Works that do not meet our free software standards > >We acknowledge that some of our users require the use of works that >do not conform to the Debian Free Software Guidelines. We have >created "contrib" and "non-free" areas in our archive for these >works. The packages in these areas are not part of the Debian system, >although they have been configured for use with Debian. We encourage >CD manufacturers to read the licenses of the packages in these areas >and determine if they can distribute the packages on their CDs. Thus, >although non-free works are not a part of Debian, we support their >use and provide infrastructure for non-free packages (such as our bug >tracking system and mailing lists). > > Thereby re-inforcing the interpretation that any installer or image with > non-free software on it is not part of the Debian system, but that we > support their use and welcome others to distribute such work. > > == Seconded. I would like to add, that I really appreciate the efforts of Steve and think that I understand where he is coming from with his proposal - I just fails to see how those concerns can be addressed within the constraints that we have strongly defined as core scope for our system (because in my understanding "our system" includes our official install image for our system). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Changing how we handle non-free firmware
Quoting Tobias Frost (2022-08-22 15:57:01) > On Mon, Aug 22, 2022 at 07:39:21AM +0200, Simon Josefsson wrote: > > Ansgar writes: > > > > > On Fri, 2022-08-19 at 16:23 +0200, Simon Richter wrote: > > >> Do we need to update the Debian Social Contract for that? > > >> Specifically paragraph 1, which currently reads > > >> > > >> Debian will remain 100% free > > > > > > No. Just like we don't need to update the Debian Social Contract for > > > having https://deb.debian.org/debian/pool/non-free/: we just ship > > > additional files that might be useful for people having specific > > > hardware. > > > > I disagree -- what is being proposed here is to replace our current > > DSC-compatible free software installer images with non-free. That goes > > significantly further than what the spirit of DSC§5 suggests. > > It not being replaced; there are just additional bits in there which > help people to actually be able to install Debian on some modern machines. > > The guarantee in SC1 that we will never *require* those non-free bits, as > writen > out in "We will never make the system require the use of a non-free > component." > This GR does not violate this promise. I understand how we will not require non-free bits getting *installed*. The way I see it, with this change we will require non-free bits for *distribution* of our system, because our official installer will now include non-gree bits. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Liquidate donated assets as soon as possible
Quoting Louis-Philippe Véronneau (2022-06-19 17:25:42) > On 2022-06-19 03 h 18, Andrey Rahmatullin wrote: > > On Sat, Jun 18, 2022 at 11:14:31PM -0400, Louis-Philippe Véronneau wrote: > >>>> Someone pointed out "assets" is very broad, and that would include > >>>> things like hardware donations (something I don't think would be wise). > >>>> > >>>> I would hereby like to amend my proposal by replacing "assets" by > >>>> "financial assets": > >>>> > >>>> Text of GR > >>>> > >>>> Donations to the Debian project of *financial* assets other than the > >>>> TO's currency of choice should be liquidated as soon as possible. > >>>> > >>>> End Text of GR > >>> > >>> I'd suggest you also provide a definition. Do you intend to prevent a TO > >>> from accepting donated frequent flyer miles and keeping them long enough > >>> to provide an airplane ticket to someone who can't otherwise afford to go > >>> to Debconf? I'd say that the current text would require them to be > >>> converted to cash and I don't think that would be the best thing. > >> > >> The definition of "financial asset" on Wikipedia is: > >> > >> "A non-physical asset whose value is derived from a contractual claim, > >> such as bank deposits, bonds, and participations in companies' share > >> capital." > > So no cryptocurrency or other probably easily liquidated things? > > I'd argue cryptocurrency is a form of financial assets yes. This GR > would force TOs to liquidate donated cryptocurrency when they receive it > in the name of the Debian project. In Denmark, crypto currencies are explicitly not "financial assets" by the definition you quote: I am legally obligated to report both easily liquidable financial assets like bonds and more complicated ones only potentially later holding value (mentioning here to clarify that it is not a matter of needing to report only what is immediately taxed), but only when I "liquidate" crypto currencies is the resulting trade evaluated regarding taxes: My understanding is that he danish government do not currently want to collect taxes of "toy money" because that would also mean that they would need to accept tax *deductions* from loss of same "toy money". My point is *not* to invite a debate about how to interpret this, only to point out that your proposed GR is too vague. If obvious to you what you propose, then perhaps you need to expand with references to the definitions you find obvious - i.e. something more substantial than above quoted text if your intent is for the definition to unambiguously include crypto currencies! That said, you will not have my support for this bill - I agree with others suggesting we leave it to the appointed leader and delegated teams. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: Condemn Russian invasion of the Ukraine
Quoting Ansgar (2022-04-08 12:46:59) > On Fri, 2022-04-08 at 10:44 +0100, Jonathan Dowland wrote: > > On Thu, Mar 31, 2022 at 08:21:39PM +0300, Adrian Bunk wrote: > > > If a Debconf location is also considered a political statement as > > > you imply then we have to choose Debconf locations by means of GR, > > > starting with a GR right now whether Debian wants to consider > > > Kosovo a self-determined sovereign nation by holding Debconf 2022 > > > there. > > > > Correct me if I'm wrong, but Debconf is not formally a part of > > Debian, and so cannot be bound by the outcome of a GR anyway. > > Hmm, debconf.org says "Copyright Software in the Public Interest, > Inc", but there is no imprint or anything. DebConf as such is not > listed as a separate project on https://www.spi-inc.org/projects/; of > course it could still be part of systemd or another project. > > DebConf is also not listed on > https://www.debian.org/trademark#licenses, but uses Debian trademarks. > > So it pretty much looks like DebConf is part of Debian. Sorry, I don't follow. What you quoted above seems to indicate to me that Debconf _uses_ Debian, not that it is legally a part of Debian. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: Condemn Russian invasion of the Ukraine
Quoting Russ Allbery (2022-04-06 01:44:43) > Jonas Smedegaard writes: > > Quoting Steve Langasek (2022-04-05 22:36:02) > >> On Thu, Mar 31, 2022 at 02:39:31PM +0200, Jonas Smedegaard wrote: > > >>> No we don't - we care about our users, and our users include those > >>> who do evil. > > >> I think this thread has largely petered out, with many people > >> having laid out the reasons why Debian taking a public position on > >> this is not necessarily a good idea. > > >> But I don't think it should go unadddressed that it's quite a > >> bizarre twist to go from "our priorities are our users and Free > >> Software" to "we care about evil users". > > > Please note the word "include" in my sentence above. > > > Point is we do *not* care about our users doing evil. > > I think there's an unfortunate confusion here between "care," which is > a mental state or a moral position, and some form of action. Ah. I think you are right - and I can see now how my choice of words upset others. > I do, in fact, care about our users doing evil, so I'm apparently not > part of your "we." However, in most cases I don't think Debian should > *do* anything about our users doing evil, for a whole bunch of reasons > ranging from the tradeoffs inherent in free software principles to the > law of unintended consequences. There are unfortunately many > instances where something bad is happening in the world but a specific > person or organization is not in a position to do anything effective > about the bad thing without causing more problems. > > I suspect that you (Jonas) are largely arguing for the same thing, and > much of the disagreement is just over terminology. I think I do agree, yes. > > Debian rejects software licensed with the following clause: > > > "The Software shall be used for Good, not Evil" > > This is an excellent example of the tradeoffs of free software principles. > The problem with such a license, at least from my perspective (which, from > previous discussions on this exact topic, appears to be common) is not the > general idea that we would prefer people not do evil things with software. > It's the practical specifics, which include such things as the murkiness > of "evil" (including different and incompatible effective definitions for > every piece of software with such a license), the problems with enforcing > such a license in a legal system that exists in the real world, and the > lack of clarity and thus legal uncertainty for our users who may be doing > something that the author of the software may consider "evil" but that > many other people in the world would not. > > In other words, I don't think we rejected that license because we don't > care whether our users do evil. I think we rejected that license because > the harm is greater than the benefits. Right. I do not want anyone to do evil - be that our users or anyone else. It is just not so simple to define or agree on what is evil, so we provide Free Software for everyone - including evil war makers, and evil capitalists, and evil squirrel tamers, and evil fuel burners, etc. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: Condemn Russian invasion of the Ukraine
Quoting Steve Langasek (2022-04-05 22:36:02) > On Thu, Mar 31, 2022 at 02:39:31PM +0200, Jonas Smedegaard wrote: > > Quoting Julian Andres Klode (2022-03-31 12:31:18) > > > Under 4.1.5 of the Constitution, the developers by way of GR are > > > the body who has the power to issue nontechnical statements. > > > > This is a proposal for Debian to issue a statement on an issue of > > > the day as given as an example, the recent invasion of Ukraine. > > > > Text of GR > > > > The Debian project issues the following statement: > > > > The Debian project strongly condemns the invasion of Ukraine by > > > Russia. The Debian projects affirms that Ukrain is a souvereign > > > nation which includes the Donbas regions of Luhansk, as well as > > > Crimea, which has already been illegaly annexed by Russia. > > > No we don't - we care about our users, and our users include those > > who do evil. > > I think this thread has largely petered out, with many people having > laid out the reasons why Debian taking a public position on this is > not necessarily a good idea. > > But I don't think it should go unadddressed that it's quite a bizarre > twist to go from "our priorities are our users and Free Software" to > "we care about evil users". Please note the word "include" in my sentence above. Point is we do *not* care about our users doing evil. Which is same as we care *equally* about users doing good and users doing bad: It is not for us to judge our users' deeds. Debian rejects software licensed with the following clause: "The Software shall be used for Good, not Evil" > That is far different from "people who are doing evil are using > Debian, and therefore we should support them". Why do you write "therefore"? I talk about supporting our users _regardless_ of doing good or evil. [ further distortion snipped ] Please don't twist my words! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: Condemn Russian invasion of the Ukraine
Quoting Julian Andres Klode (2022-03-31 12:31:18) > Under 4.1.5 of the Constitution, the developers by way of GR are the > body who has the power to issue nontechnical statements. > > This is a proposal for Debian to issue a statement on an > issue of the day as given as an example, the recent invasion > of Ukraine. > > Text of GR > > The Debian project issues the following statement: > > The Debian project strongly condemns the invasion of Ukraine by > Russia. The Debian projects affirms that Ukrain is a souvereign > nation which includes the Donbas regions of Luhansk, as well as > Crimea, which has already been illegaly annexed by Russia. No we don't - we care about our users, and our users include those who do evil. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Questions about Debian derivatives
Quoting Paul Wise (2022-03-28 04:27:48) > On Sun, 2022-03-27 at 18:05 +0200, Jonathan Carter wrote: > > Last I spoke to you, I think you also said that you don't have much > > time to work on this anymore, and that the distro census is probably > > going to die down. Is this still the status? Do you think it can be > > saved? We probably have quite a wide audience here, do you think > > it's worth another shot to get people involved to work on it? > > The census has been turned off for years. It is too much work for one > person to do on their own. I don't have motivation or time or ability > to do it alone any more. I have tried to recruit other folks to work > on both the social and technical sides of it. I had an Outreachy > intern that did some great work. I had some interest in contributing > from both DDs and non-DDs but the interest didn't result in the sort > of ongoing contributions that are needed. I've had encouragement for > keeping the census around from a couple of folks though. I'm also not > sure the Debian community thinks the approach is correct or even > useful to Debian itself and also for derivatives themselves; the > mailing list and IRC channel are mostly silent for years. There are > also some solvable technical flaws that mean the census cron can't be > turned back on right now, and the motivation issues block fixing them. I guess that by "The census" you mean the code to compute the delta between Debian and each of its derivatives. I think the census is useful both to Debian itself and to derivatives. Sadly I suspect that too few are aware of it, despite your promotion, Paul. Help getting the census scripts back on track requires Python skills. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Waiting for the voting vote to finish... :-)
Quoting Jonathan Carter (2021-11-23 17:43:27) > On 2021/11/23 17:59, Steve McIntyre wrote: > >> would you be willing to let peb and I propose the secret ballots GR? > >> We were hoping we were in line behind Russ. > > > > Sure, no worries. > > Ah, I also had one, but can wait my turn. I considered starting a thread > in -project in the meantime, but I'm slightly concerned of information > overload between a large discussion on -project and a running vote. > > Not to complicate things further, but perhaps some additional > co-ordination of upcoming votes might help (assuming that's even possible)? Perhaps simply put an ordered list up somewhere at our wiki? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Renaming the FTP Masters
Daniel Kahn Gillmor wrote: On Sat 2021-11-06 11:32:35 +0100, Martin Steigerwald wrote: Pierre-Elliott Bécue - 06.11.21, 11:06:58 CET: That being said, the name is indeed outdated, and "Debian Archive Team" sounds quite nice. Agreed. I like this name. Yes, please. "Debian Archive Team" is fine. This is fair amount of work, but it will help make debian not seem quite as archaic as I'm sure it seems to new prospective users or developers. Thus it is valuable work. But a GR does not seem necessary. Thank you dkg for writing this mail. Full acknowledgement. Cheers jonas The way to do this is to consult with the people already on the team and the DPL. Select a new name, figure out what work needs to be done to make the change. Make a plan, have someone to drive it, and persist. It will probably take at least a full debian release cycle. Changing names is hard, even if you don't have reactionary pushback. Many things might be touched by this: e-mail addresses; mailing lists; text in debian policy or the developer's reference; DNS labels; OpenPGP certificates; SSH host information; wiki entries; software like dupload; etc (fortunately, the archaic team name doesn't appear in the Constitution or the DFSG). Consider upgrade paths and how to deprecate the old name safely: when updating e-mail addresses, can you create an alias from the old label to the new address? How about DNS records? How should we handle mailing list archives? When/how should you send a deprecation warning when people use the old label? Have a timeline that acknowledges the work involved, and plans when to take each step. For example, changing DNS records, e-mail addresses, and cryptographic associations will probably be slower/more cumbersome than changing human-readable labels. Be prepared to revise the workplan when someone discovers some other place that the old name is embedded. You need to find someone or someone(s) who have the capacity and the skills to actually carry out the right work -- or who at least can keep track of the work and encourage/support the folks who have the permissions to do it to get it done. No one should object to this work if it's done with this kind of thoughtfulness, care, and attention to detail. Helping the project through this transition would be a great contribution to Debian, because it fixes a silly stumbling block that existing developers have already learned how to ignore, but that does actually hold the project back from welcoming new members who might have never heard of FTP (or of using the term "master" to mean administrator for a machine) before. This work is *not* the kind of contribution that maps cleanly to a facility at packaging free software for redistribution. This is a great example of why we need more than just package-maintainers as debian developers. There are probably many other parts of the project that need this kind of attention and effort, and we should absolutely *not* scare people off who want to help fix things. But let's not make it harder to fix than it already needs to be by dragging a GR into the mix as well. --dkg PS For people who are concerned that a retreat from the term "master" is somehow the language police run dangerously amok, it's worth asking why you feel so committed to the term "master" that you would fight to keep the project we all work on using terminology we all can acknowledge is confused and outdated. If someone is excited to improve the project, even if you don't have the capacity to help them do it, at least *let* them do it!
Re: Question Re: Advertising in Packages
Hi Antonio, Quoting Antonio Russo (2021-08-16 03:04:33) >"Can one advertise non-free services in a Debian package? > Is doing so a violation of some Debian policy? > > I apologize if this is the wrong venue to ask this question (and, if > so, could someone please direct me to the proper venue to ask this > kind of question). The better place to ask is debian-le...@lists.debian.org As I undertand it, it is legally ok to advertise for non-free services in a Debian package - but it is socially awkward, and Debian may choose to not distribute a package for other reasons than it being illegal. ...But you really should ask the proper place where those interested and skilled in those matters are subscribed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Quoting Barak A. Pearlmutter (2021-04-20 16:12:16) > Maybe looking at options 7/8 wasn't the best example, both because of > perceived differences and because FD plays a special role. > But with all the ballots we can find a bunch of votes that do seem to > not use the full power of the ballot in ways that do seem a bit > counterintuitive. > Have a look for yourself, it's a fun exercise. > A large number of voters stop ranking when they get to FD. I'm not > sure why, but in many cases this renders their ballot pretty much > powerless because options with a chance of winning are not ranked. > > The details are very interesting, but any discussion of the actual > options leads back to discussing the topic of the GR proper, so I > really don't want to go there. I appreciate this topic being brought up - it has affected my voting style: Previously I thought that my voting powers stopped at FD. I don't think it makes sense to change the system to mandate use of all voting power. Maybe it makes sense to e.g. add a friendly notice in the voting confirmation email when not all voting power is used. But there is already a lot of text surrounding a vote, so such noticemight commonly be missed. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Quoting Bernd Zeimetz (2021-04-20 15:26:06) > On 2021-04-20 12:50, Jonas Smedegaard wrote: > > > > I genuinely think that more time preparing the ballot would have led > > to fewer more well-written options on the ballot, and consequently a > > higher likelihood that Debian would have decided to make a (more > > well-written) statement instead of the current outcome of not making > > a statement. > > On th other hand this leads to even more discussion, more flame-wars > and maybe some other ballots that come in in a short time before the > voting peropd starts - which might have the same issues you've just > described. But without a defined time on when a vote starts, the > discussion will never end. > > No idea on how to fix that, though. Personally I think having fixed > and known dates is still the best option. I think a sensible step in the direction towards fixing the issue you describe is to not assume that "more discussion" necessarily leads to "the discussion will never end". ;-) For my own part, by "more time preparing" I did only imply "the ordinary 2 weeks", not "all the time in the World". - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)
Quoting Philip Hands (2021-04-20 11:57:58) > Adrian Bunk writes: > > > On Mon, Apr 19, 2021 at 01:04:21PM -0700, Russ Allbery wrote: > >>... > >> * The length of the discussion period is ill-defined in multiple ways, > >> which has repeatedly caused conflicts. It only resets on accepted > >> amendments but not new ballot options, which makes little logical sense > >> and constantly confuses people. There's no maximum discussion period > >> defined, which means fixes for that risk introducing a filibuster. > >> > >> * Calling for votes is defined as a separate action from the end of the > >> discussion period, but in practice the constitution allows any developer > >> to call for a GR vote via an abuse of process that probably wasn't > >> intended, and even apart from that, the set of people who can call for a > >> vote is strange and not very defensible. > >>... > > > > The process to shorten the discussion period is also suboptimal. > > > > In the latest GR the way the discussion period was shortened was > > perceived by many as an anti-democratic attempt to suppress discussions > > about the contents and alternative ballot options. > > > > And there was plenty left to discuss (including wording of ballot > > options and secrecy of the vote) when the minimum discussion period > > ended and the vote was called. > > > > I would suggest to replace the option of shortening the discussion > > period with the possibility of early calling for a vote after a week > > that can be vetoed by any developer within 24 hours. This would ensure > > that shorter discussion periods would only happen when there is > > consensus that nothing is left to be discussed. > > Would you expect a different result if that had been done in this case? I genuinely think that more time preparing the ballot would have led to fewer more well-written options on the ballot, and consequently a higher likelihood that Debian would have decided to make a (more well-written) statement instead of the current outcome of not making a statement. I know that my own contribution in the process felt rushed, and that I thought at the time I seconded options 2 and 3 and 4 that I would have much preferred to instead have the time to discuss eventual merger of them instead of worrying that all of those views were presented at all on the ballot. Flaws of ambiguity in at least one of the texts were pointed out without having time to address it. For the record I don't say this as someone grumpy over the actual result in this vote: On the contrary the winning option was my first choice. Also, I *do* understand that for this specific vote there was a sense of urgency (especially for those introducing the vote). My point here is not that the concrete vote by all means should have not been rushed, but that I do believe that taking the current vote as a concrete example the time to prepare the ballot had a real effect on the outcome. > I don't think that one can automatically assume that more discussion > is better. I agree. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Quoting Felix Lechner (2021-04-20 00:55:19) > On Mon, Apr 19, 2021 at 2:40 PM Pierre-Elliott Bécue > wrote: > > > > I don't understand how you semantically see 7 and 8 as comparable. > > Aside from Bdale's reason for ranking unwanted options below FD—which > were motivated by the voting system—I do: GRs do not decide a matter > with prejudice, even though the weight to bring them again may be > substantial. Therefore, doing nothing is very similar to doing nothing > but talking more. > > As we all heal from this divisive issue, I furthermore find it > meaningful that proponents of a shortened discussion, who were at > times accused of pushing the resolution, were actually aligned with > voters: By a narrow margin, people did not want to discuss the matter > at all. I am one of those feeling the process happened too fast, and at the same time I voted 7 as my first choice. I disagree with your conclusion. Seems it is directly tied to your interpretation that 7 somewhat equals 8, which I also don't share: I can only read 7 as "We shall not formally act as organisation on this topic, only defer action to individuals", and 8 as "We shall do something else than presented on this ballot". I. e. to me 7 and 8 are quite different: Only 7 is a closure, and only 8 is an indication of "we ned more time". Or rephrased: Wanting more time to prepare ballot options is to me quite different from rejecting all closure options presented on the ballot by voting for the non-closure option. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
Quoting Don Armstrong (2021-04-19 00:39:12) > On Sun, 18 Apr 2021, Barak A. Pearlmutter wrote: > > If we look at the actual ballots, it's really interesting. Options 7 > > and 8 were semantically pretty much equivalent. It's hard to see any > > reason for someone to rank them very differently. > > 7 was a decision to not issue a statement ["There's no statement on > this issue that I want Debian to issue"]. 8 was a decision for further > discussion ["There may be statement on this issue that I'd want Debian > to issue, but it's not here."] > > When there isn't an explicit "no decision" option on the ballot, > further discussion encompass both, but that is not the case here. > > > It's very difficult to imagine someone who actually preferred option > > 7 being equally satisfied with any of options 1-6 and 8. > > Here's an example thought process that works: "I want Debian to stop > discussing this issue and anything more that Debian does on this issue > is equally bad." > > Or another one: "I know that I prefer this option, but I'm not > comfortable with the rest of the options to decide what the project > should do, so I'll defer to the project's judgement." > > Not to say that there aren't voters who are confused, but you should > contact them to figure out why they voted the way they did before > assuming that they didn't know what they were doing. In case anyone wants to pick a live brain on this, I volunteer: At first I voted 7-8: I explicitly preferred Debian to *not* issue a statement. Then, after reading the discussion on this list about the concern over people leaving options below FD "blank", I changed my vote to wade through all those options I did *not* want Debian to make and try rank the severity of their badness - while being worried that my vote is public so I expose my priority of evil thoughts to the World. - Jonas P.S. This is *not* an invitation to rehash a debate over which ballot options are or are not sane. My offer is that if you have trouble understanding why someone deliberately choose to vote by the two _patterns_ described above then I am willing to reflect on that. Perhaps you even manage to point out to me that I am a fool and did what I did for the wrong reasons. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Ways forward regarding the RMS GR
Hi Jonathan, Quoting Jonathan Carter (2021-04-12 12:12:23) > Over the course of the last few days, I've received many mails > regarding the RMS GR, both on this list, on debian-private and in > private. These mails contain a wide spectrum of concerns and even > ideas on how to improve our situation, each of which come with their > own set of upsides and downsides. Amazingly unbiased summary of events, and sensible reasoning on how to deal with the current complexities. Thank you very much, Jonathan! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
Quoting Adam Borowski (2021-04-03 18:21:54) > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > TEXT OF OPTION 5 > > > > > > Debian refuses to participate in and denounces the witch-hunt against > > Richard > > Stallman, the Free Software Foundation, and the members of the board of the > > Free Software Foundation. > > > > > > Seconded. > > I'd prefer a more positive wording, such as "Debian re-affirms the > Diversity Statement as written, and thus denounces ...", but your version is > good enough. Seconded. I really dislike this communication style, seemingly a direct consequence of the choice to shorten the discussion time. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
Quoting Craig Sanders (2021-04-03 01:56:45) > Short and simple: > > TEXT OF OPTION 5 > > > Debian refuses to participate in and denounces the witch-hunt against Richard > Stallman, the Free Software Foundation, and the members of the board of the > Free Software Foundation. > > > Seconded. I would have preferred more time to discuss wording, but that was not sadly provided. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
Quoting Micha Lenk (2021-04-03 13:08:50) > Am 03.04.21 um 10:25 schrieb Adrian Bunk: > > Craig, if you make this a new separate GR I will be glad to sponsor > > it. > > Do you (or anybody actually) have a idea how to deal best with the old > RMS GR if this one is formally accepted? If this one is accepted then I can only interpret the old one as missing this option and if this option had been included then it would have won over the other options. Can anyone imagine voting in favor of this one with a different intent? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
Quoting Holger Levsen (2021-04-03 11:14:53) > On Sat, Apr 03, 2021 at 10:56:45AM +1100, Craig Sanders wrote: > > TEXT OF OPTION 5 > > > > Debian refuses to participate in and denounces the witch-hunt against > > Richard > > Stallman, the Free Software Foundation, and the members of the board of the > > Free Software Foundation. > > > > I'd sponsor this if this were actually neutrally worded like "Debian refuses > to participate in the discussion of Richard Stallman, the Free Software > Foundation, > and the members of the board of the Free Software Foundation." > > Though even that is a statement. I'd sponsor this if a) neutrally worded and b) initiated before the current GR as completed - i.e. driven by the lack of adequate time for preparing the current GR instead of the outcome of it. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Nuance Regarding RMS
Quoting Barak A. Pearlmutter (2021-04-01 12:51:59) > I can personally vouch for the fact that RMS can be very difficult. He > takes social awkwardness to new heights. He’s remarkably stubborn in > technical matters even when outside his domain of expertise and > completely wrong. He is not a fun house guest. His manners as a dinner > guest are atrocious. He was by far the most logistically problematic > seminar speaker I have ever hosted. He takes umbrage at quite > innocuous colloquial phrasing, and is obstinate about his own > idiosyncratic interpretation of English semantics. He overshares, and > has great difficulty reading others' emotions. > > But he's not transphobic. That accusation is basically scurrilous. At > https://libreboot.org/news/rms.html is an impassioned but well > reasoned (at least in this regard) defense of RMS from a trans woman > he had a big public fight with. “If you actually tell Richard your > preferred pronouns, he’ll use them with you without hesitation. > Several of my friends are trans and also speak to Richard, mostly via > email. He respects their pronouns also.” > > Calling him ablist is similarly unfair. He was defending women’s right > to terminate pregnancies when the fetus has a condition like trisomy > 21. Whatever your views are on the underlying political question, to > twist that as ablist is quite a stretch. > > RMS is not violent. > > He's weird with everyone, which do I think has, in general, a > disproportionate effect on women. As does his poor personal hygiene. > He had a mattress in his office at MIT because he was basically living > there. That might give lots of people squicky feelings, but would have > a disproportionate effect on women. He makes unwelcome sexual > overtures to women, but backs off when turned down (with perhaps > isolated exceptions decades ago). That's totally inappropriate > behaviour. He seems unable to sense when someone finds him repellent. > > Basically, he’s super creepy and unpleasant. He picks his feet and > eats it while delivering seminars. > > Nina Paley hosted him in her apartment in New York on a number of > occasions, and had a similar read. > > I'm not sure he'd be an ideal board member, but that’s a practical > rather than ethical consideration, and surely best left to the > judgement of the individual organization. > > What’s problematic to me about this whole “Cancel RMS” business is the > lack of nuance. He’s clearly not neurotypical in a way that makes him > very difficult to deal with. He doesn’t make appropriate eye contact. > He’s strange in ways that I think, on average, affects women more than > men. But should we bully or ostracise him for that? I think we should > try to develop coping strategies for both him and people who want or > need to deal with him. That’s actually supporting and accommodating > diversity. And it’s hard! We should seek ways to leverage his > strengths, which are considerable. Of course, that assumes lack of > malice, which I think is the case with RMS. He’s not malicious. He > really wants to connect, but he’s utterly unable to. He’s weird and > clueless. And he’s obsessed with software freedom. Thank you, Barak. I agree with your observations, and find them an important contribution in this complex matter (and have tried several times but given up on trying to phrase something similar myself). Question is, this being a process to compose a ballot for a vote: How to transform those observations into a text for the ballot? Or if that is absurd, how else to proceed (other than shrug and let the boting process continue disregarding those observations? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Amendment to RMS/FSF GR: Option 4, assert the need to learn and grow from recent events
Quoting Jonathan Wiltshire (2021-03-31 00:28:47) > This is a late amendment proposal which I hope seconders will feel able to > support in time for it to make the ballot paper. It is late because I feel > strongly that events in the past few days [1] [2] [3] [4] risk overtaking > this GR; Debian already has enough criticism for being slow to respond, and > I want to head off anything which might reinforce that view. > > 1: https://www.fsf.org/news/preliminary-board-statement-on-fsf-governance > 2: https://www.fsf.org/news/update-on-work-to-improve-governance-at-the-fsf > 3: > https://www.fsf.org/news/welcoming-ian-kelling-to-staff-seat-on-fsfs-board-of-directors > 4: > https://www.fsf.org/news/statement-from-the-fsf-board-of-directors-meeting-on-march-29-2021 > > I acknowledge that this text is not worded so strongly as many people would > like it to be. However, I don't believe in fueling fires and I would like > to see Debian calling for overhaul of FSF governance without joining any > lynch mobs. There are competing extreme opinions at the moment, and I'm > hoping this is a text on which we can have broader agreement. > > CHOICE TEXT FOLLOWS: > > This is a position statement of the Debian Developers in accordance with > our constitution, section 4.1.5. > > The Developers firmly believe that leaders in any prominent organisation > are, and should be, held to the highest standards of accountability. > > We are disappointed that issues of transparency and accountability in the > governance of the Free Software Foundation have led to unresolved and > serious complaints of impropriety by its founder Richard Stallman over a > number of years whilst in the position of president and as a member of the > board. In particular, we are deeply concerned that the board saw fit to > reinstate him without properly considering the effect of its actions on > those complainants. > > The Developers acknowledge that people make mistakes but believe that where > those people are in leadership positions, they must be held accountable for > their mistakes. We believe that the most important part of making mistakes > is learning from them and changing behaviour. We are most concerned that > Richard and the board have not sufficiently acknowledged or learned from > issues which have affected a large number of people and that Richard > remains a significant influence on both the FSF board and the GNU project. > > We call upon the Free Software Foundation to further steps it has taken in > March 2021 to overhaul governance of the organisation, and to work > tirelessly to ensure its aim is fulfilled. We believe that only through > properly accountable governance can members of an organisation ensure their > voice is heard. The Free Software Foundation must do everything in its > power to protect its staff and members, and the wider community, including > a robust and transparent process for dealing with complaints. > > We urge Richard Stallman and the remaining members of the board which > reinstated him, to consider their positions. > > The Developers are proud that contributors to free software come from all > walks of life and that our diverse experience and opinions are a strength > of software freedom. But we must never cease in our efforts to ensure that > all contributors are treated with respect, and that they feel safe and > secure in our communities - including when we meet in person. > > END CHOICE TEXT Seconded. This text adresses the concerns I have raised on this list (as far I I have so far been able to understand it - and due to the shortened processing time I hope that anyone spotting issues in it does so in time...). Thanks, Jonathan! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: opinion on Choice 1
Hi, Quoting Ulrike Uhlig (2021-03-29 10:58:13) > Sorry for my ignorance, but who are you? I cannot find your name in the > Debian contributor list. Sorry for my ignorance, but who are you to ask that? I cannot your name in the Debian mailinglist inquisitor list. Best Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Amendement to GR Statement regarding Stallman's readmission to the FSF board
Quoting Santiago R.R. (2021-03-29 14:51:59) > === Begin text === > > Under section 4.1.5 of the constitution, the Developers make the following > statement: > > Debian’s statement on Richard Stallman rejoining the FSF board > > We at Debian are profoundly disappointed to hear of the re-election of Richard > Stallman to a leadership position at the Free Software Foundation, after a > series of serious accusations of misconduct led to his resignation as > president and board member of the FSF in 2019. > > One crucial factor in making our community more inclusive is to recognise and > reflect when other people are harmed by our actions and consider this feedback > in future actions. Unfortunately, the way Richard Stallman announced his > return to the board lacks any acknowledgement of this kind of thought process. > We are deeply disappointed that the FSF board elected him as a board member > again, despite no discernible steps were taken by him to be accountable for, > much less make amends for, his past actions or those who have been harmed by > them. Finally, we are also disturbed by the secretive process of his > re-election, and how it was belatedly conveyed [0] to FSF’s staff and > supporters. > > We believe this step and how it was communicated sends a wrong and hurtful > message and harms the future of the Free Software movement. The goal of the > software freedom movement is to empower all people to control technology and > thereby create a better society for everyone. Free Software is meant to serve > everyone regardless of their age, ability or disability, gender identity, sex, > ethnicity, nationality, religion or sexual orientation. This requires an > inclusive and diverse environment that welcomes all contributors equally. > Debian realises that we and the Free Software movement still have to work hard > to be in that place where everyone feels safe and respected to participate in > it in order to fulfil the movement's mission. > > Therefore, in the current situation, the Debian Project is unable to > collaborate both with the FSF and any other organisation in which Richard > Stallman has a leading position. Instead, we will continue to work with groups > and individuals who foster diversity and equality in the Free Software > movement in order to achieve our joint goal of empowering all users to control > technology. > > [0] https://status.fsf.org/notice/3796703 > > === End text === Seconded. Thanks, Santiago! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Hi Sam, Quoting Sam Hartman (2021-03-28 23:55:42) > >>>>> "Jonas" == Jonas Smedegaard writes: > There were a lot of messages here, and I may have missed some. Sorry for my part of that: I wish I were able to express my opinions more compactly. > When I last paid attention to this, you were concerned about whether > the letter was an attempt at public shaming. > As a personal choice, I reject shaming fairly strongly. > But now somehow the discussion has moved on to whether the accusation > in the letter is necessary and whether Debian risks legal issues by > signing on. To me it is one and the same issue: I do not want to take part in bullying/shaming/libel/throwing mud/making accusations and therefore I don't want Debian to do so either. That it poses a legal risk is for me an indication of the underlying issue for me: That it is wrong to do so. > The legal question is not interesting to me; I think the risk to > Debian is one I'm quite willing to accept. > > But the shaming question is interesting to me (at least under my > fairly narrow definition of shaming). > I'd like to see if I'm understanding your argument. > > Are you saying that by making an unnecessary accusation we would be > shaming? > And so you'd like to understand whether the accusation is necessary to > understand whether we are shaming? Yes to both questions. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Quoting Pierre-Elliott Bécue (2021-03-28 20:31:01) > Le dimanche 28 mars 2021 � 14:04:48+0200, Jonas Smedegaard a �crit�: > > My involvement in this subthread was when Molly arguing that the > > accusation was not harmful (using other words, yes, and we can > > nitpick that if really necessary). You (and others, privately) > > agree that the accusations are deliberately harmful but that the > > harm cannot backfire on Debian. I have raised my concerns - I rest > > my case. > > Accusations are generally harmful, and as accusations are always > delibeately made, they indeed tend to be deliberately harmful. > > That does not mean they are not warranted. And I think it is that > point that could/should be discussed. Text #1 oncludes an accusation. Other proposed texts does not. I think the relevant thing to discuss is not if the accusation embedded in text #1 is warranted, but instead if that accusation is necessary. Is the accusation needed for that proposal? It seems to me that the message would be the same with that accusation omitted, but maybe I am missing something. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Quoting Wouter Verhelst (2021-03-28 08:17:32) > On Sat, Mar 27, 2021 at 11:46:03PM +0100, Jonas Smedegaard wrote: > > Quoting Wouter Verhelst (2021-03-27 18:19:57) > > > On Sat, Mar 27, 2021 at 10:41:57AM +0100, Jonas Smedegaard wrote: > > > > Thanks for your judgements(!), Luke and Enrico. > > > > > > > > For the record, I do not defend actions of RMS. I defend his > > > > right to a fair trial. > > > > > > Nobody is claiming Richard doesn't have the right for a fair > > > trial. He is still a human being, and every human being has such a > > > right. > > > > > > However, there is no trial here. > > > > We agree that there is no trial here. > > > > My point is however tied to that of cancel culture a.k.a. group > > shaming - specifically that the initial text on the ballot use > > judgemental language that I can only read as intended to condemn the > > person that we want to distance outselves from. Maybe I use the > > words wrongly or sloppily - what I mean is the difference between > > saying "that person allegedly made a crime" and "that person has > > made a crime", where the former is an accusation. > > The word "allegedly" is used by the press when reporting on a case, as > a shorthand for "we don't want to take a position either way, but this > is what the one party in the case is saying". > > Since we *do* want to take a position here, using "allegedly" is not > appropriate. > > Having said that, the language of the letter does not say that RMS > *is* mysoginistic, transphobic, or ableist; it states that "he has > shown himself to be" all these things. The difference here is subtle, > but it is a difference of exactly the type you are arguing for. That (your very last sentence above) helps address my concern. > > Seems my concern is what in english is called "libel": > > https://en.wikipedia.org/wiki/Defamation#Libel > > According to that very page, for a statement to be considered libel, > it has to be false. Quote: > >Defamation (also known as calumny, vilification, libel, slander or >traducement) is the oral or written communication of a *false* >statement about another that *unjustly* harms their reputation and >usually constitutes a tort or crime > > (emphasis mine) > > Do you have reason to believe these statements are false, and/or that > they "unjustly" harm RMS' reputation? Yes - that is the reason I have invested time on this subthread. I do not, however, have reason to believe that the statements are expressed "with reckless disregard for the truth", which seems an important distinction. > > > There is just the statement that RMS > > > has been a very annoying person for the past several decades, and that > > > having him in a position of leadership, in the opinion of those people > > > that signed the letter, causes more harm than good. > > > > > > *That is not a trial*. That is an opinion on the effects another > > > person's behavior has to a community. > > > > You talk about the part of Debian distancing itself from RMS. > > > > I talk about the part of Debian making accusations against RMS. > > > > Imagine someone in Debian blogged about skin colors, super annoyingly > > and persistently for many years but always "just talking about stuff" > > maybe walking close to but never crossing the line of racism, > > Do you believe that to be the case here? Do you think RMs has "walked > close but never crossed the line" of the things he's being accused of? Yes - that is the reason I have invested time on this subthread. > If you do, then... well, we'll have to discuss that. If you mean we have to discuss what RMS has or has not done, then I disagree that we have to discuss that. I believe that we have to discuss if we want on our ballot a text which potentially is libel. My concrete proposal is to remove that one sentence which I can only read as a direct accusation. > For the record, I don't believe so. I do believe he is all the things > he is being accused of in that letter. Right: Your opinion - and I assume the opinion of the proposers of the text as well - is that it has (deliberate harmful intent, but) no risk of libel in keeping it as-is. I am open to discuss further but don't know how it at all we can continue such discussion. > > Unless or until a fair trial has ruled that he is guilty of those > > horrible crimes, in which case in becomes f
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Hi Wouter, Quoting Wouter Verhelst (2021-03-27 18:19:57) > On Sat, Mar 27, 2021 at 10:41:57AM +0100, Jonas Smedegaard wrote: > > Thanks for your judgements(!), Luke and Enrico. > > > > For the record, I do not defend actions of RMS. I defend his right > > to a fair trial. > > Nobody is claiming Richard doesn't have the right for a fair trial. He > is still a human being, and every human being has such a right. > > However, there is no trial here. We agree that there is no trial here. My point is however tied to that of cancel culture a.k.a. group shaming - specifically that the initial text on the ballot use judgemental language that I can only read as intended to condemn the person that we want to distance outselves from. Maybe I use the words wrongly or sloppily - what I mean is the difference between saying "that person allegedly made a crime" and "that person has made a crime", where the former is an accusation. Seems my concern is what in english is called "libel": https://en.wikipedia.org/wiki/Defamation#Libel > There is just the statement that RMS > has been a very annoying person for the past several decades, and that > having him in a position of leadership, in the opinion of those people > that signed the letter, causes more harm than good. > > *That is not a trial*. That is an opinion on the effects another > person's behavior has to a community. You talk about the part of Debian distancing itself from RMS. I talk about the part of Debian making accusations against RMS. Imagine someone in Debian blogged about skin colors, super annoyingly and persistently for many years but always "just talking about stuff" maybe walking close to but never crossing the line of racism, and Debian at some point had enough and decided to issue a public statement saying that this person had shown himself to be a racist. My worry is that Debian had then comitted a crime of libel, whereas you seem to describe that as Debian simply sharing its opinion about this person in a community. Apparently (from skimming above Wikipedia article) the US treats celebrities special regarding libel, unlike e.g. Denmark. Perhaps that explains why I worry more than others in this conversation. > Debian stating to the FSF that we would prefer not to have to deal > with RMS is not a punishment for RMS. Yes, I agree. But again that is not the group shaming part which I was talking about. Stating that RMS "has shown himself to be misogynist, ableist, and transphobic" is not simply expressing "that we would prefer not to have to deal with RMS" - it is a strong accusation. Not a wild out-of-the-blue accusation, but still an accusation. Unless or until a fair trial has ruled that he is guilty of those horrible crimes, in which case in becomes facts. > XKCD 1357 applies here, with s/free speech rights/rights to a fair > trial/. Fun. But besides my point. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Hi Martin, Quoting Martin Steigerwald (2021-03-27 11:13:52) > On addition: In a sense, Jonas, you said what I wrote below, I think. > You warned about group shaming. And I may have misread your mail. Cause > now I am not sure that you actually called him a monster. You wrote that > users have accused him of being one. So in case I misunderstood that, > please accept my apology. My differentiation to focus on behavior and not > the person regarding a public statement may still be helpful to bring > some clarity. > > > Dear Jonas, dear Debian community, > > Jonas Smedegaard - 27.03.21, 10:41:57 CET: > > I need no further testimonies or evicence that RMS is a monster. For the record: I am guilty of introducing the word "monster", but did *not* mean to imply that anyone in particular would label RMS as such - not me and not Luke and not Enrico. I accused Like and Enrico for _judging_ but not for labelling. > I never experienced Richard Stallman in real life so far. Is it relevant to study RMS to decide texts for the ballot? Some with one opinion has proposed the initial text for the ballot. Other with different opinions have proposed other texts for the ballot. We should make sure that the ballot represents the opinions of those opinions backed by adequate seconders, and we should try to make sure that the ballot has no unintended side effects - e.g. conflicts with other things in Debian, or violate laws of society surrounding Debian. We should not on this mailinglist try to judge RMS, however. What is the purpose *for* *preparing* *a* *ballot* of reflecting on the personality of RMS or examine presented evidence or collecting additional evidence? My point here is that it is *irrelevant* if he is a monster of not - for *this* conversation. It may or may not be super relevant for Debian what kind of person RMS is, and the _outcome_ of this vote seeks to aid in resolving that. We *cannot* resolve that in the design of the ballot, however! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
Quoting Timo Weingärtner (2021-03-27 11:51:40) > 26.03.21 20:42 Jonas Smedegaard: > > Quoting Calum McConnell (2021-03-26 20:14:50) > > > > Any individual (including Debian members) wishing to (co-)sign > > > > any of the open letters in question is invited to do this in > > > > person. > > > > > > "In person" is a bit unclear, given our times: can I sign it > > > online? How about just adding my name? [...] > > Replacing "invited to do this in person" with "strongly encouraged > > to do so" would in my opinion radically change the message from an > > unbiased "Debian does not recommend if you should personally support > > a petition or not" to a biased "Debian recommends that you > > personally support a petition". I would *not* second such changed > > proposal. > > I took "in a personal capacity" from Gunnar. Rule #9: Given a choice between Jonas and Gunnar, pick Gunnar :-) > > Replacing "in question" with "on this subject" seems to me to not > > change to meaning of the message. I would second a proposed text > > with that change. > > That's better actually, because it is not restricted to statements > mentioned in the vote. > > Updated text: > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) wishing to (co-)sign any of the > open > letters on this subject is invited to do this in a personal capacity. > ---8<---8<---8<--- Seconded! > An alternative would be removing the last sentence all together, how > do you think about that? Such change might be (mis)read as bias against (not only organisational, but also) personal engagement in petitions. I find it a feature of this text that it explicitly clarifies that Debian has no opinion on personal engagement in petitions. I.e. praphrased: "Debian says no to partitions, but (just in case of doubt) has no say on what members of Debian do individually". If instead you consider it that a flaw, and instead intended the message to be that Debian is more generally against those petitions, then I think it would be better to express that explicitly, e.g. by explicitly discouraging Debian members to sign those petitions even in a personal capacity. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Quoting Enrico Zini (2021-03-27 10:08:06) > On Fri, Mar 26, 2021 at 02:31:28PM -0700, Luke W Faraone wrote: > > > Myself, I signed this letter based on both public information and > > the numerous times I've heard, unprompted, stories from women and > > female-presenting people who have had uncomfortable / creepy > > experiences with Stallman, in the Debian / free software community, > > the MIT community, and elsewhere. > > > > I have heard first-hand stories from women who were new to the Free > > Software movement and, at a conference, were excited to meet its > > leader -- only to be hit on by Richard and invited back to continue > > the conversation at a residence. These people did not stay in the > > Free Software movement, and our community is poorer for it. > > > > None of those incidents would have turned into a police report, and > > I'm not demanding that you rely on it. But it comes up so frequently > > at conferences, student clubs, and bar chats from so many different > > people that I have little reason to doubt its veracity. > > > > It's also interesting to note that over 12 former FSF staff, who > > worked directly with Richard, also saw it fit to sign the letter. > > This! Thank you! > > I have regularly been among people sharing horror stories of what > happened when they hosted RMS at some event or another. > > In my experience there is an unwritten, alternative "RMS Rider", that > you should know before hosting/handling him, with things like "don't > you *ever* leave RMS alone with a woman!", "avoid mentioning this list > of words", "a number of basic expectations of human decency don't > apply, and you should be prepared for that". > > As long as he was in a somewhat official position of guru/leadership, > I was part of a community that tried its best to *handle* him, and to > *minimize his damage*. I understand that many people close to him > tried to talk to him, and that Stallman is about as famous for > speaking as for not listening. I believe that all this has held Free > Software back significantly. > > We had finally moved on from having a significant amount of the > community energy spent on *handling Stallman*. And now he's supposed > to be back "and I'm not planning to resign a second time"? > > Stallman can certainly *speak* about Free Software. Stallman cannot > *lead* the Free Software movement, or any influential part of it. We > had moved on, and we had mostly gotten away with it[1]. I don't want > to go back. Thanks for your judgements(!), Luke and Enrico. For the record, I do not defend actions of RMS. I defend his right to a fair trial. This mailinglist is for dicussing what to put on a ballot. I need no further testimonies or evicence that RMS is a monster. Regardless of the amount and type of proof, Debian should in my opinion *not* take part in group shaming. And *that* is relevant to discuss on this mailinglist: What to put on the ballot for the Debian vote. The originally proposed text says that RMS has demonstrated that he is what he is being accused of being. That is a way of turning allegations into facts - i.e. *judging* - and I worry for Debian officially stating that the allegations are facts is going too far, and that it is unneded if what we want is to distance ourselves from a monster. Only if we want to punish the monster is it relevant to explicitly judge the monster. It is my understanding that it is illegal for organisations to make such explicit judgements, which is a reason for us to avoid explicit judgement, even if that is in fact what we want to do. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
Quoting Calum McConnell (2021-03-26 20:14:50) > > Any individual (including Debian members) wishing to (co-)sign any > > of the open letters in question is invited to do this in person. > > "In person" is a bit unclear, given our times: can I sign it online? > How about just adding my name? > > I propose switching it to: > > > Any individual (including Debian members) wishing to (co-)sign any > > of the open letters on this subject is strongly encouraged to do so. > > It also handles the fact that the open letters aren't really 'in > question', since there aren't any accepted amendments that mention > them. I also switched out "invite", because I feel that 'invite' > implies the ability to UN-invite (ie, block from signing), which is > not one that we possess. I was assuming that "in person" meant "individually", but I can see how it can instead mean "by showing up physically" which makes little sense in the context. Replacing "in person" with either "personally" or "individually" or "on their own" would in my opinion convey the same intended message as is my understanding (as a non-native english speaker) is the message now, and I would second proposal with such change. Removing "in person" would however loose what in my understanding is the central point of the message and making the central point implicit, causing it to risk becoming ambiguous (although I cannot think up right now how any examples of how other meanings could be read into it). I would hesitate seconding a proposal with the phrase removed. Replacing "invited to do this in person" with "strongly encouraged to do so" would in my opinion radically change the message from an unbiased "Debian does not recommend if you should personally support a petition or not" to a biased "Debian recommends that you personally support a petition". I would *not* second such changed proposal. Replacing "in question" with "on this subject" seems to me to not change to meaning of the message. I would second a proposed text with that change. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Amendment to GR on RMS rejoining FSF
Quoting Sruthi Chandran (2021-03-26 19:47:58) > > On 26/03/21 10:45 pm, Sruthi Chandran wrote: > > > > > Dear fellow DDs, > > > > Second the amendment text if acceptable to you :) > > > Re-sending with fixed signature and replacing twitter link with > gnusocial link. > > > > Begin text > > > > Under section 4.1.5 of the constitution, the Developers make the > > following statement: > > > > *Debian’s statement on Richard Stallman rejoining the FSF board* > > > > We at Debian are profoundly disappointed to hear of the re-election of > > Richard Stallman to a leadership position at the Free Software > > Foundation, after a series of serious accusations of misconduct led to > > his resignation as president and board member of the FSF in 2019. > > > > One crucial factor in making our community more inclusive is to > > recognise and reflect when other people are harmed by our > > own actions and consider this feedback in future actions. The way > > Richard Stallman announced his return to the board unfortunately lacks > > any acknowledgement of this kind of thought process. We are deeply > > disappointed that the FSF board elected him a board member again despite > > no discernible steps were taken > > by him to be accountable for, much less make amends for, his past > > actions or those who have been harmed by them. Finally, we are also > > disturbed by the secretive process of his re-election, and how it was > > belately conveyed [0] to FSF’s staff and supporters. > > > > > > We believe this step and how it was communicated sends wrong and hurtful > > message and harms the future of the Free Software movement. The goal of > > the software freedom movement is to empower all people to control > > technology and thereby create a better society for everyone. Free > > Software is meant to serve everyone regardless of their age, ability or > > disability, gender identity, sex, ethnicity, nationality, religion or > > sexual orientation. This requires an inclusive and diverse environment > > that welcomes all contributors equally. Debian realises that we > > ourselves and the Free Software movement still have to work hard to be > > in that place where everyone feels safe and respected to participate in > > it in order to fulfil the movement's mission. > > > > > > That is why, we call for his resignation from all FSF bodies. The FSF > > needs to seriously reflect on this decision as well as their > > decision-making process to prevent similar issues from happening again. > > Therefore, in the current situation we see ourselves unable to > > collaborate both with the FSF and any other organisation in which > > Richard Stallman has a leading position. Instead, we will continue to > > work with groups and individuals who foster diversity and equality in > > the Free Software movement in order to achieve our joint goal of > > empowering all users to control technology. > > > [0] https://status.fsf.org/notice/3796703 > > > > Heavily based on: > > > > [1] https://fsfe.org/news/2021/news-20210324-01.html > > > > [2] > > https://www.eff.org/deeplinks/2021/03/statement-re-election-richard-stallman-fsf-board > > > > End of text Seconded. Thanks, Sruthi, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
Quoting Timo Weingärtner (2021-03-26 14:36:40) > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) wishing to (co-)sign any of the > open > letters in question is invited to do this in person. > ---8<---8<---8<--- Seconded. People - offended or not by RMS ans FSF - who find it wrong of Debian as an organisation to make a public statement about the affairs of FSF, and also do not want any "further discussion", may find this agreeable to vote for. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Richard Stallman's readmission to the FSF board
Quoting Dominik George (2021-03-26 15:07:36) > > If you want the project to issue a statement, the exact statement > > should be in the GR, so that people that vote know what they are > > voting for. > > The statement I described is one that says "we will stand behind > anyone who was harmed during their contribution to the project", not a > request to harm anyone else like the original GR. > > This is something that the Debian Code of Conduct already guarantees, > and really something that, if they contradict that, would make anyone > unfit as a Debian Project member because contradicting that would > violate the agreements that we made. > > Therefore, I consider the Press team to have enough power to issue > such a statement even without anyone else asking for it, so they can > be requested to write something up themselves. Whoops, I missed this detail - thanks, Marga! I hereby retract my seconding of the text as it is currently presented: I cannot second a text which makes promises on behalf of others. > If a fully fledged out statement is a requirement to get this choice > into the GR, I will write one. Please do - I will reconsider my support based on what that turns out to be (and really I hesitate: As already mentioned this text seem overlapping with another smaller proposed text). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General Resolution: Richard Stallman's readmission to the FSF board
Quoting Dominik George (2021-03-26 13:26:09) > On Fri, Mar 26, 2021 at 11:50:31AM +0100, Jonas Smedegaard wrote: > > [replying only to -vote - please avoid cross-posting!] > > OK, but you actually replied only to -devel instead of -vote. Arrgh. > > Quoting Dominik George (2021-03-26 11:05:26) > 8><-- > Choice 2 > > > The Debian Project does not co-sign the statement regarding Richard > Stallman's readmission to the FSF board seen at > https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md > > In its role as an important body in the free software world, the > Project has made its members aware of the situation, and respects the > opinion of all of its members. In doing so, every member is free to > sign the statement, or to not do so. > > The Debian Project make an official statement, along the lines of: > > * We have learnt about rms being readmitted to the FSF board > * We are aware of critical voices regarding the person known as rms, > and we take every single report very serously > * Everyone who, related to contributions to Debian, is affected by > any action, opinion or statement of rms can ask the Debian Anti > Harassment team for support, and the Anti Harassment team will > support them in communicating with the FSF and ensure their concerns > are addressed > * The Debian Project will cooperate with an investigation committee > regarding all accusations against rms if the FSF board decides to > instate such a committee, which the Debian Project endorses > ------><8 Seconded (also if "Choice 2" is omitted or renumbered or rephrased) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Hi Anarcat, Quoting Antoine Beaupré (2021-03-25 20:11:45) > Hey what's up doc, > > On 2021-03-25 00:41:41, Jonas Smedegaard wrote: > > Quoting M dB (2021-03-24 23:55:23) > >> A few thoughts: > >> > >> - I don't like the term "cancel" because I think it doesn't mean > >> much anymore and is too loaded. > > > > Means too little and too much at the same time?!? > > > > https://www.dictionary.com/e/pop-culture/cancel-culture/ describes > > it as a form of boycott, calling out, and group shaming. > > > > Wikipedia seems to share that view - what am I missing? Am I in some > > bubble confirming my views, and other bubbles tell radically > > different storis about the meaning of the term? > > > > > >> Are we discussing a handful of people leaving volunteer positions? > >> Yes. Are we discussing ruining their lives? No. > > > > Are we disccussing public boycott and shaming? Yes. > > > > Do public boycott and shaming ruin lives? Hopefully not, but I > > wonder how you can so confidently dismiss both the term as being > > meaningless and the action as being harmless. Shame on you for not > > taking responsibility for your action. > > Did you just "shame" someone because they supposedly call on "shaming" > someone else? Isn't that a contradiction? No. I shame someone for reframing an act of group shaming as harmless. > > I get a strong impression that this RMS felow is far from a saint, > > and encourage that he be properly tried for his alleged wrongdoings. > > So basically, what you are proposing is that, instead of suggesting > RMS simply be expelled from a non-profit, all the witnesses and > victims of his crimes should collectively organise for him to be > criminally prosecuted in a court of law in the United States? > > How would that not be public shaming? Regardless of the shame involved in prosecution in a US court system, that does not legimitize group shaming. I find it reasonable for Debian to distance itself from questionable activities in related organisations, but not to get involved in group shaming. I find it distasteful for Debian to *judge* activities in related organisations. Stating that "[RMS] has shown himself to be misogynist, ableist, and transphobic" is treating allegations (arguably very strong allegations but still not proven in a court of law) as it it was facts. > Anyways, I think the point here is to get seconders, maybe we should > keep those arguments to the vote and move on. I hope I won't regret > outlining the contradictions here. I think the point here is to discuss what should be on the ballot. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
Quoting Antoine Beaupré (2021-03-25 20:13:42) > On 2021-03-25 19:13:09, Jonas Smedegaard wrote: > > I dislike the conclusive judgemental framing of the previously > > referenced open letter, and consider it wrong for Debian as an > > organisation to make direct demands on how other organisations > > should conduct its business. I certainly would find it > > inappropriate for FSF to make direct demands on how Debian operates. > > Yeah, the FSF or RMS would *never* make direct demands onto how > another organization operates, right? Your point being what exactly? My point is that (indeed FSF makes demands on Debian, and) FSF making direct demands on how Debian should operate is something I find inappropriate (and it triggers other emotions in me as well), and I don't want Debian to treat FSF in that same way. Sorry if I was unclear earlier... - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
Quoting Mathias Behrle (2021-03-26 10:40:55) > * Timo Weingärtner: " Re: "rms-open-letter" choice 3: do not, as the project > itself, sign any letter regarding rms" (Fri, 26 Mar 2021 09:19:44 +0100): > > > Hallo Martin Michlmayr, > > > > 26.03.21 09:15 Martin Michlmayr: > > > * Timo Weingärtner [2021-03-26 09:12]: > > > > The Debian Project will issue a public statement on whether Richard > > > > Stallman > > > ^^ > > > I think you forgot the word "not" here. > > > > Of course, thanks. > > > > Updated text: > > ---8<---8<---8<--- > > The Debian Project will not issue a public statement on whether Richard > > Stallman should be removed from leadership positions or not. > > > > Any individual (including Debian members) is free to issue such statements > > or > > (co-)sign any open letter. > > As a matter of course each individual is/shall be free to do so, we don't have > to debate this right at all or in a GR. Furthermore I would like to have the > wording restricted to the current document in question. > > Could this be changed to something along the lines: > > """ > Any individual (including Debian members) wishing to (co-)sign the open letter > in question is invited to do this in person. > """ Seconded - on the condition that Timo Weingärtner replaces his previous proposal with one one including above edit. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Amendment to rms-open-letter GR
Quoting Sean Whitton (2021-03-25 21:17:34) > ===BEGIN > > Replace the entire text with: > > Under section 4.1.5 of the constitution, the Developers make the > following statement: > > The Debian Project echoes and supports recent calls to remove Richard > M. Stallman from positions of leadership within free software, for which > we believe him to be inappropriate. > > We are disappointed by the actions of those responsible for restoring > him to the Free Software Foundation's Board of Directors, and urge that > that decision be reversed. > > ===END Seconded. People who... a) agree that Richard M. Stallman is unsuitable as leader of free software organisations, and b) find it appropriate for Debian to take an official stand on that issue, but c) disagree with the explicitly enumerated labels attributed to his actions in the initially proposed text, may find this agreeable to vote for. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: "rms-open-letter" choice 3: do not, as the project itself, sign any letter regarding rms
Quoting Timo Weingärtner (2021-03-26 09:19:44) > Hallo Martin Michlmayr, > > 26.03.21 09:15 Martin Michlmayr: > > * Timo Weingärtner [2021-03-26 09:12]: > > > The Debian Project will issue a public statement on whether Richard > > > Stallman > > ^^ > > I think you forgot the word "not" here. > > Of course, thanks. > > Updated text: > ---8<---8<---8<--- > The Debian Project will not issue a public statement on whether Richard > Stallman should be removed from leadership positions or not. > > Any individual (including Debian members) is free to issue such statements or > (co-)sign any open letter. > ---8<---8<---8<--- Seconded (for the record, I would also second a proposed text in the style of FSF Europe, so please don't take this as discouragement for draftiing such other text) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Willingness to share a position statement?
Quoting Gard Spreemann (2021-03-25 19:21:36) > > Margarita Manterola writes: > > > On Thu, Mar 25, 2021 at 6:59 PM Roberto C. Sánchez > > wrote: > > > >> Essentially, voting in this GR is implicitly > >> compulsory and there is only one correct way to vote. > > > > > > Also not true. The GR is to vote whether Debian issues a statement about > > this or not. If you think Debian shouldn't issue a statement about this, > > that's a totally valid opinion. The point of the GR is to gauge whether the > > majority of DDs think that the project should or should not issue a > > statement. We won't know until the voting is over whether that's the > > case. > > I'm very sorry if I misunderstood something (this is the first GR to > come up since I joined the project, please excuse the > handholding/noise), but isn't this a GR over whether or not Debian > issues a *specific* statement about the matter? > > It puts those of us who may wish for Debian to make *a* statement, but > dislike the broadness of the open letter that is under consideration for > ratification, in a difficult spot. If you think that an alternative statement should be made instead, then propose that alternative and if enough others support that (the process of "seconding") then it will appear as another option on the voting ballot. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
Quoting Sruthi Chandran (2021-03-25 18:29:32) > > > On March 25, 2021 2:24:16 AM GMT+05:30, Steve Langasek > wrote: > >Under 4.1.5 of the Constitution, the developers by way of GR are the > >body who has the power to issue nontechnical statements. > > > >https://github.com/rms-open-letter/rms-open-letter.github.io/blob/main/index.md > > > >is a statement which I believe Debian as a project, and not just > >individual Debian developers, should consider signing on to. > > > >This is a proposal for Debian to sign on to the statement, by > >adopting the text from that open letter via GR. > > > I have an alternate suggestion. Instead of signing the said letter, > Debian can issue a position statement similar to the one released by > FSF Europe. [1] > > Will share the amended text if this idea has supporters. > > [1] https://fsfe.org/news/2021/news-20210324-01.html I would support a position letter similar to that of FSF Europe, and appreciate if you could draft that, Sruthi. I dislike the conclusive judgemental framing of the previously referenced open letter, and consider it wrong for Debian as an organisation to make direct demands on how other organisations should conduct its business. I certainly would find it inappropriate for FSF to make direct demands on how Debian operates. I like the different tone of the letter by FSF Europe, not demanding but instead distancing itself and making clear why (without using specific labels as if some court ruling had already taken place, which is not the case). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
Quoting M dB (2021-03-24 23:55:23) > A few thoughts: > > - I don't like the term "cancel" because I think it doesn't mean much > anymore and is too loaded. Means too little and too much at the same time?!? https://www.dictionary.com/e/pop-culture/cancel-culture/ describes it as a form of boycott, calling out, and group shaming. Wikipedia seems to share that view - what am I missing? Am I in some bubble confirming my views, and other bubbles tell radically different storis about the meaning of the term? > Are we discussing a handful of people leaving volunteer positions? > Yes. Are we discussing ruining their lives? No. Are we disccussing public boycott and shaming? Yes. Do public boycott and shaming ruin lives? Hopefully not, but I wonder how you can so confidently dismiss both the term as being meaningless and the action as being harmless. Shame on you for not taking responsibility for your action. I get a strong impression that this RMS felow is far from a saint, and encourage that he be properly tried for his alleged wrongdoings. Public boycott and shaming is something else than a that, however. Something that _does_ means much, and has a bitter taste in my mouth. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Willingness to share a position statement?
Quoting Gerardo Ballabio (2021-03-24 12:32:31) > Matthias Klumpp wrote: > > Inclusivity and tolerance does not mean we have to accept every opinion as > > equally valid. > > Equally valid -- no. > Legitimate to express -- yes. > > I am really worried about the increasing trend (not specific to > Debian) towards demanding that people who hold "dissenting" opinions > be removed from their positions, excluded from the public debate, and > even fired from their jobs, which if universally applied would make > them unable to earn a living. That is what dictatorial regimes do -- > often while maintaining a facade of freedom: "Nobody is being > prevented from speaking, we're just making their life miserable > because we don't like what they're saying". That's exactly what's > happening with the current political correctness storm. Say one bad > word and your life might be ruined. > > Just yesterday I happened to read this quotation (on a Debian mailing > list!). I believe it is very much to the point: > "Those who begin coercive elimination of dissent soon find themselves > exterminating dissenters. Compulsory unification of opinion achieves > only the unanimity of the graveyard. -- Justice Roberts in 319 U.S. > 624 (1943)" > > What happened to "I don't agree with what you're saying, but I'll give > my life to defend your right to say it"? Very well said, Gerardo - but there is a piece missing: Question is not if legitimate for RMS to have and share opinions. Question instead is if RMS mixes personal opinions with official roles. I sometimes sneeze. If I worked at a restaurant, then I served a role as a servant where it is absolutely unacceptable to sneeze. If I failed at understanding that sneezing while acting in my role as servant was unacceptable, then it would be reasonable that management fired me. And it would be sensible to sign a petition to have the board of the restaurant step down if they failed to fire me. Now imagine that I blogged about my sneezing, shared videos of sneezes in slow-motion, and argued in talk shows that my sneezing was special and could cure COVID-19, not spread it. The restaurant managers fired me, but later changed their mind and hired me back again. Should I be fired again, or the management be shamed? Depends on whether I sneezed at work, not if it was public knowledge that I was a sneezer and clueless about how viruses spread - those features have *nothing* to do with my ability to serve food at a restaurant (regardless of my very presence in the restaurant might make sone guests vomit because they remembered some slow-motion video they once saw, produced by me). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: How to leverage money to accomplish high impact Debian projects
Quoting Gard Spreemann (2021-03-23 16:40:32) > > Jonas Smedegaard writes: > > > Quoting Gard Spreemann (2021-03-23 16:18:10) > >> Is there a fundamental difference between paying someone to do > >> "non-fun administrative tasks" like accounting, and paying someone > >> to help out with orphaned/RFA'd packages (cf. Christian Kastner's > >> recent "How to motivate contributors to work on QA" question)? > >> > >> It seems to me, to some extent, that a package that is orphaned or > >> RFA'd is per definition "not fun enough" for a volunteer to work > >> on. > > > > Accounting is a mandatory activity regardless of its fun-factor. > > > > Seems backwards to to me to pay for keeping packages alive that we > > have lost interest in. > > That's a good point, I agree. What about packages that we have lost > interest in, but that our users very much have not? Admittedly, I have > no idea of what the cardinality of that intersection is. > > Or alternatively: are there hard-to-maintain packages that are highly > useful to users, but where there just isn't enough interest to > overcome a very high maintenance burden? Could paid work help offload > the maintainer of such packages (leaving them with more of the fun > parts and less of the non-fun ones)? Yes, paid work helps some maintainers - but that's the wrong question! The right question is if paid work helps Debian *and* does not at the same time disturb (other parts of) Debian too much. Next question is then how much is "too much" - I have no answer for that. If Debian paid for working on orphaned packages, then I would probably orphan some of the packages I now maintain as a volunteer, to then work on those same packages for pay. I would not consider that cheating: Some of "my" packages are genuinely less fun to maintain, and would certainly be *lesser* fun if knew that others were paid for doing similar tasks. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: How to leverage money to accomplish high impact Debian projects
Quoting Gard Spreemann (2021-03-23 16:18:10) > > Louis-Philippe Véronneau writes: > > > On 2021-03-22 16 h 43, Didier 'OdyX' Raboud wrote: > >> Le vendredi, 19 mars 2021, 17.49:54 h CET Louis-Philippe Véronneau > >> a écrit : > >>> On 2021-03-19 08 h 02, Raphael Hertzog wrote: > >>>>> I've been telling a few people last month that I would really > >>>>> liked to have an Enterprise Edition Online MiniDebConf, > >>>>> unfortunately I don't have any time/energy to instigate that > >>>>> currently. > >>>> > >>>> Something for a Debian fellow that we could hire ;-) > >>> > >>> I for one would be less motivated to help with videoteam tasks if > >>> I knew someone was paid to organise a miniconf. > >> > >> Would your motivation also be affected if an individual was paid > >> only for a specific task that noone in the team found particularily > >> interesting to do? > >> > >> (I don't know much about how the videoteam works, so I don't know > >> if that's a good example, but let's see…) For example, what if > >> someone (paid) handled the storage and timely shipping of all the > >> hardware, as well as the actual ordering of new hardware, leaving > >> the (what I assume is the more interesting part) configuring, > >> design and conception of the system to volunteers? > > > > I'm not opposed to paid labor per-say. I think the previous examples > > of Debian paying TOs to do accounting is a good one. > > > > So to answer your question, I wouldn't be opposed if we contracted > > an enterprise to handle our gear for us. > > > > I don't think it's something particularly fun to do and I see that > > more as an administrative task, akin to accounting. > > > > "Organising a miniconf" isn't though. > > Is there a fundamental difference between paying someone to do > "non-fun administrative tasks" like accounting, and paying someone to > help out with orphaned/RFA'd packages (cf. Christian Kastner's recent > "How to motivate contributors to work on QA" question)? > > It seems to me, to some extent, that a package that is orphaned or > RFA'd is per definition "not fun enough" for a volunteer to work on. Accounting is a mandatory activity regardless of its fun-factor. Seems backwards to to me to pay for keeping packages alive that we have lost interest in. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: How can we make Debian packaging more standardised?
Hello, Jonathan Carter wrote: One of the reasons I like team-maintained packages is teams often have a single packaging standard. Sadly, each team has their own way of doing things and working in multiple teams means working with multiple "standards". If you were elected as DPL, what would you do about this? Sam Hartman tried to lead discussions on using git, but sadly it seems it didn't yield anything tangible. I consider this an item still on the collective project's todo list to figure out. I've received plenty of e-mails to the DPL alias regarding git workflows, but there has just been too many high priority things to take care of this term and sadly this just hasn't made the cut in terms of my DPL load. This is one of those issues which could be delegated but then again, it's also a discussion that's already open for anyone to drive, so that would be kind of redundant? I have a followup question mainly to Jonathan, but would love to hear Sruthi's perspective as well: I can imagine that the day-to-day tasks in a DPL term already mean a huge workload. Still, I have to admit that (as someone who follows the major Debian lists) I got the impression that you weren't particularely "visible" in the project during the last year. In particular, I missed the regular "Bits of the DPL" updates, which in the past helped a lot to get a better understanding of what a DPL does under the hood. I really wonder whether better distribution of the DPL tasks - e.g. with the help of a DPL team or delegated board - would help to get more "visible" tasks done. Given that you already denied such an idea in another thread on this list, I wonder if there's not a contradiction: One one hand you admit that important tasks don't get done due to lack of time, on the other hand you don't want to distribute the workload. Pollo's example is a good one: a standardised/recommended way of Debian packaging would definitely be a huge win for the project and significantly lower the entry barrier for newcomers. The past has shown that this discussion requires someone to lead it and Sam drove if forward significantly during his term. So why not find people who would help you with getting this task done? Why not have an officially delegated Debian Project Board that meets once a week (or every two weeks) and discusses and tackles painpoints in the project at large? Kind regards jonas OpenPGP_signature Description: OpenPGP digital signature
Re: Q to all candidates: NEW queue
Quoting Xavier (2020-03-27 09:38:54) > Le 27/03/2020 à 09:22, Ulrike Uhlig a écrit : > > Hi! > > > > On 26.03.20 15:05, Lucas Nussbaum wrote: > >> On 26/03/20 at 14:42 +0100, Jonas Smedegaard wrote: For the avoidance of doubt, I wrote none of below quoted text. > >> A/ > >> - package is uploaded > >> - package waits in NEW > >> - package gets reviewed, gets accepted in unstable with a bug filed > >> - bug gets fixed > >> > >> B/ > >> - package is uploaded > >> - package gets accepted in unstable > >> - package gets reviewed, a bug is filed > >> - bug gets fixed > >> > >> Except that with (B), we avoid the wait in NEW. > > > > In scenario B, the wait is shorter, but there is no guarantee that the > > bug gets fixed in an appropriate time frame. > > > >> One important question is: how often does the FTP team run into a > >> package that is so problematic that accepting it in Debian with an RC > >> bug is not an option? > > > > Another question is: what other things are reviewed by the FTP team? > > Like, is there some sort of basic security review, are there packages > > that are not appropriate to be uploaded to the archive for some reason > > or another? And then this would not just result in an RC bug, I guess? > > > > Ulrike > > Hi > > And what about creating "pre-ftp-master" in teams ? They could fix team > policy and do a technical review. This will avoid common errors and may > decrease ftp-master work. > > This proposition is based on JS-Team experience: some people pushed JS > packages without knowing JS tools and practices. These packages often > contains pre-build objects and a few other common errors. Sadly some DD > push such packages with JS-Team as maintainer without being member of > this team, neither asking for help/review from JS team! > > Then scenario C: > - package is uploaded > - ftp-master redirects package to pre-ftp-master(s) [using BTS?] who >are concerned > - package gets pre-ftp-master(s) review [BTS(s) closed] > - package gets ftp-master's review > - package is released Sorry, maybe just me, but is above a question to DPL candidates? I mean, teams certainly do not need DPL to permit them to packaging prepare packages before bothering ftp-master with them, or...? - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Q to all candidates: NEW queue
Quoting Ulrike Uhlig (2020-03-27 09:22:46) > Another question is: what other things are reviewed by the FTP team? > Like, is there some sort of basic security review, are there packages > that are not appropriate to be uploaded to the archive for some reason > or another? And then this would not just result in an RC bug, I guess? See https://ftp-master.debian.org/REJECT-FAQ.html - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Q to all candidates: NEW queue
Quoting Roberto C. Sánchez (2020-03-26 14:28:47) > That said, I have never had a package rejected for reasons that would > outright keep it from entering Debian. Each package I have had > rejected could have as easily been accepted into unstable and then > fixed after the fact to address whatever the problem was. For > instance, omitting a particular file with a distinct (but compatible) > license from listing in the copyright file or some similar minor > license-related matter. None of those things seem like reasons to > hold up a package entering Debian for months to nearly a year. > Though, I may be mistaken in that and biased based on my own > experience. Or you might be describing a procedure that has since been improved. When sharing example cases, it helps if you also mention how long ago it happened (I sometimes get surprised how much time has passed when checking such facts). For future cases, I suggest to always file an ITP bugreport before pushing a new package, to help encourage ftp team to use that bugreport to store responses/remarks from them - and when that happens we can in future reference the bugreport when sharing example cases :-) - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Option G update [signed] (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
Quoting Kurt Roeckx (2019-12-06 23:06:28) > On Fri, Dec 06, 2019 at 10:50:32PM +0100, Kurt Roeckx wrote: > > > > That's 5, I'll update everything. > > The website should be updated very soon. Thanks a lot, Kurt! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Option G update (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)
[ dropping all recipients except debian-vote@l.d.o ] Quoting Guillem Jover (2019-12-06 21:04:39) > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > Principles > ~~ > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight trade-offs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > > Guidance > > > In the same way Debian maintainers are somewhat constrained by the > decisions and direction emerging from their respective upstreams, > the Debian distribution is also somewhat constrained by its volunteer > based nature, which has as another of its core defining traits, not > willing to impose work obligations to its members, while at the same > time being limited by its members bounded interests, motivation, energy > and time. > > Because of these previous constraints, trying to provide guidance in > a very detailed way to apply the aforementioned principles, is never > going to be satisfactory, as it will end up being inexorably a rigid > and non-exhaustive list of directives that cannot possibly ever cover > most scenarios, which can perpetuate possible current tensions. > > These will always keep involving case by case trade-offs between what > changes or requests upstreams might or might not accept, or the upkeep > on the imposed deltas or implementations the Debian members might need > to carry on. Which can never be quantified and listed in a generic and > universal way. > > We will also keep in mind that what might be considered important for > someone, might at the same time be considered niche or an uninteresting > diversion of time for someone else, but that we might end up being on > either side of the fence when sending or receiving these requests. > > We will be guided, as we have been in many other Debian contexts in the > past, by taking all the above into account, and discussing and evaluating > each situation, and respecting and valuing that we all have different > interests and motivations. That is in our general interest to try to > work things out with others, to compromise, to reach solutions or find > alternatives that might be satisfactory enough for the various parties > involved, to create an environment where we will collectively try to > reciprocate. And in the end and in most cases it's perhaps a matter of > just being willing to try. > X< Seconded - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Last minute cominbations G+D and/or G+E
gnise that some maintainers find init scripts a burden and >we hope that the community is able to find ways to make it easier >to add support for non-default init systems. Discussions about the >design of such systems should be friendly and cooperative, and if >suitable arrangements are developed they should be supported in the >usual ways within Debian. > > CONTRIBUTIONS OF NON-SYSTEMD SUPPORT WILL BE ACCEPTED > > 7. Failing to support non-systemd systems when such support is >available, or offered in the form of patches (or packages), >*should* be treated as a release critical bug. For example: init >scripts *must not* be deleted merely because a systemd unit is >provided instead; patches which contribute support for other init >systems (with no substantial effect on systemd installations) >should be filed as bugs with severity `serious'. > >This is intended to provide a lightweight but effective path to >ensuring that reasonable support can be provided to Debian users, >even where the maintainer's priorities lie elsewhere. (Invoking >the Technical Committee about individual patches is not sensible.) > >If the patches are themselves RC-buggy (in the opinion of, >initially, the maintainer, and ultimately the Release Team) then of >course the bug report should be downgraded or closed. > > 8. Maintainers of systemd components, or other gatekeepers (including >other maintainers and the release team) sometimes have to evaluate >technical contributions intended to support non-systemd users. The >acceptability to users of non-default init systems, of quality >risks of such contributions, is a matter for the maintainers of >non-default init systems and the surrounding community. But such >contributions should not impose nontrivial risks on users of the >default configuration (systemd with Recommends installed). > > NON-INIT-RELATED DECLARATIVE SYSTEMD FACILITIES > > 9. systemd provides a variety of facilities besides daemon startup. >For example, creating system users or temporary directories. >Current Debian approaches are often based on debhelper scripts. > >In general more declarative approaches are better. Where > - systemd provides such facility > - a specification of the facility (or suitable subset) exists > - the facility is better than the other approaches available >in Debian, for example by being more declarative > - it is reasonable to expect developers of non-systemd >systems including non-Linux systems to implement it > - including consideration of the amount of work involved >the facility should be documented in Debian Policy (by textual >incorporation, not by reference to an external document). The >transition should be smooth for all users. The non-systemd >community should be given at least 6 months, preferably at least 12 >months, to develop their implementation. (The same goes for any >future enhancements.) > >If policy consensus cannot be reached on such a facility, the >Technical Committee should decide based on the project's wishes as >expressed in this GR. > > BEING EXCELLENT TO EACH OTHER > > 10. In general, maintainers of competing software, including >maintainers of the various competing init systems, should be >accomodating to each others' needs. This includes the needs and >convenience of users of reasonable non-default configurations. > > 11. Negative general comments about software and their communities, >including both about systemd itself and about non-systemd init >systems, are strongly discouraged. Neither messages expressing >general dislike of systemd, nor predictions of the demise of >non-systemd systems, are appropriate for Debian communication fora; >likewise references to bugs which are not relevant to the topic at >hand. > >Communications on Debian fora on these matters should all be >encouraging and pleasant, even when discussing technical problems. >We ask that communication fora owners strictly enforce this. > > 12. We respectfully ask all Debian contributors including maintainers, >Policy Editors, the Release Team, the Technical Committee, and the >Project Leader, to pursue these goals and principles in their work, >and embed them into documents etc. as appropriate. >(This resolution is a position statement under s4.1(5).) Seconded. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Proposal to overturn init systems premature GR
Quoting Russ Allbery (2019-12-03 19:19:50) > Does anyone truly believe that another round of wordsmithing or > changes to statements of principles will change a lot of opinions or > votes this deep into this discussion? Evidently someone truly believes there is need for another round. Since you asked, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Proposal: Reaffirm our commitment to support portability and multiple implementations
Quoting Guillem Jover (2019-11-30 18:46:27) > I'm thus proposing the following: > > X< > Title: Reaffirm our commitment to support portability and multiple > implementations > > The Debian project reaffirms its commitment to be the glue that binds > and integrates different software that provides similar or equivalent > functionality, with their various users, be them humans or other software, > which is one of the core defining traits of a distribution. > > We consider portability to different hardware platforms and software > stacks an important aspect of the work we do as a distribution, which > makes software architecturally better, more robust and more future-proof. > > We acknowledge that different upstream projects have different views on > software development, use cases, portability and technology in general. > And that users of these projects weight tradeoffs differently, and have > at the same time different and valid requirements and/or needs fulfilled > by these diverse views. > > Following our historic tradition, we will welcome the integration of > these diverse technologies which might sometimes have conflicting > world-views, to allow them to coexist in harmony within our distribution, > by reconciling these conflicts via technical means, as long as there > are people willing to put in the effort. > > This enables us to keep serving a wide range of usages of our distribution > (some of which might be even unforeseen by us). From servers, to desktops > or deeply embedded; from general purpose to very specifically tailored > usages. Be those projects hardware related or software based, libraries, > daemons, entire desktop environments, or other parts of the software > stack. > X< Seconded - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Bikeshedding
Raphael Hertzog: > Hi, > > On Mon, 01 Apr 2019, Louis-Philippe Véronneau wrote: >>> So if i had to decide how to implement this technique, i think the >>> simplest thing would be to move every >>> https://salsa.debian.org/foo-team/libfoo to >>> https://salsa.debian.org/debian/libfoo and let the debian/ grouping >>> handle the permissions. >>> >>> That still leaves all the rest of salsa for user-specific projects, >>> upstream projects, etc., which might have different permissions. >>> >>> Is there some reason that wouldn't address the concern you're raising? >> >> It does sound like a good solution to me :D > > Unfortunately, it also means that it's much harder grant access > to all repositories of a team to a non-DD since you have to add > the non-DD to all individual repositories instead of adding him to > the group. > > Because obviously we don't want to add non-DD to the Debian group. > > And while team-wide membership might be reviewed from time to time, I > doubt that package-specific membership will ever be reviewed by anyone. Gitlab subgroups would solve this problem: Move every Debian package into the 'debian' group, but allow subgroups in there: https://salsa.debian.org/debian/foo-team/libfoo Cheers jonas signature.asc Description: OpenPGP digital signature
Re: Debian presence on newer platforms
Hi Alex, Alexander Wirt: >>> And I tested hyperkitty some time ago with our archive and it was >>> unusable slow. >> >> Interesting. I wonder how Fedora deals with this. I haven't used their >> archives extensively, but from quick tests it appeared to be quite >> responsive. > > One question that came into mind: which problems with our lists do you think > mailman would solve? > > If its list archives: provide (or let someone do so) a hyperkitty plugin for > reading our mboxes (bonus points if its able to also remove mails from it > afterwards (gpdr, spam). Yeah, it's mainly the archive. I agree that a modern archiver that has forum-like capabilities to participate in a discussion would lower the barrier for contributors who're more into web applications that into mail clients. Which - like it or not - seems to be the case even for developers and techies in younger generations. Besides, a huge advantage of mailman3 in my eyes is that it has a proper user management. After registering *once* in Postorius (the mailman3 web interface), you can manage *all* your mailing list subscriptions on that mailman3 instance with one account. That's very convenient and something I miss on lists.debian.org. Cheers jonas signature.asc Description: OpenPGP digital signature
Q to all candidates: mutual communcation and decision-making tools
Hey all, Do you have concrete plans to improve the mutual/two-way communication between the DPL and the rest of the project? Monthly bits from the DPL are already helpful, but they're mostly a one-way communication so far. I don't mean private communication between the DPL and particular teams/developers, but public discussion. I wonder whether the DPL could do more to improve mutual communication (besides participating in mailinglist threads), maybe even by inventing new tools? My gut feeling is that most Debian members don't have the time to follow d-devel, d-project and d-private all the time, so I wonder whether we could make use of additional decision-making tools that lower the barrier to participate. One idea that came into my mind lately: we could do regular polls about the most pressing problems/projects/changes among all project members (after they got raised and discussed on the mailinglists) and the DPL could delegate temporary teams to solve/implement the ones that got the most votes. (I really like the idea of temporary task forces or "fixer teams" that Jonathan Carter brought up in msgid:51b4d63d-1af1-e0ca-6621-a131b7ec3...@debian.org[1].) E.g. that could be done bimontly and the bits from the DPL mails could be used to announce the polls and the resulting delegations. What do the candidates think about these ideas? Cheers, jonas [1] https://lists.debian.org/debian-vote/2019/03/msg00101.html signature.asc Description: OpenPGP digital signature
Re: Debian presence on newer platforms
Hi Alex, Alexander Wirt: > On Tue, 26 Mar 2019, Jonas Meurer wrote: >> Alexander Wirt: >>> In my experience as a former mailman admin and listadmin mailman is a >>> no-go. >>> Getting our feature set even nearly into mailman is impossible, takes years >>> and will just get us an unmaintainable thing. I don't want to ever run a >>> bigger mailman setup again. >> >> Can you give an example, what from "our feature set" is missing in >> mailman? Also, you probably mean mailman2, right? Have you taken a look >> at mailman3 recently? > > Sure, just a few coming into mind: > > All those gpg related features we use, our spam removal tools, our special > archiving hacks, we way we support blacklist through several lists, our > second line of spamfiltering, crossassassin, the way we can do management on > several lists and probably a lot more I forgot. It may take man years to do a > migration (in fact we talked about that a few days ago in our internal IRC > channel and this is more or less consense about the needed effort). Thanks for elaborating on that. At least some of them might be interesting to submit as mailman3 feature requests as they probably would be of help for other projects that use mailman3 as well. I fully understand that you as the listmasters don't consider to switch right now though. > And I tested hyperkitty some time ago with our archive and it was > unusable slow. Interesting. I wonder how Fedora deals with this. I haven't used their archives extensively, but from quick tests it appeared to be quite responsive. Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: Debian presence on newer platforms
Hi Alex, Alexander Wirt: >> While I agree that some "more modern" going way would be nice for lists, >> I don't think that is an easy task. Nor one where DPL can do much >> (unless listmasters need some resources that DPL can approve for such a >> change). Its up to the listmasters, though as far as i know, our current >> setup is anything but easily converted. >> In my experience as a former mailman admin and listadmin mailman is a no-go. > Getting our feature set even nearly into mailman is impossible, takes years > and will just get us an unmaintainable thing. I don't want to ever run a > bigger mailman setup again. Can you give an example, what from "our feature set" is missing in mailman? Also, you probably mean mailman2, right? Have you taken a look at mailman3 recently? Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: Debian presence on newer platforms
Quoting Jonathan Carter (2019-03-25 20:20:11) > Hi Martin > > On 2019/03/25 21:16, martin f krafft wrote: > > And while surely not representative: 11 out of 12 teams I personally > > know who looked at Matrix and Mattermost a couple of years back and > > went with Mattermost then are now migrating to Matrix, which has the > > following benefits: [...] > > - real-time voice/video conferencing [...] > (I didn't know it had real-time voice/video conferencing... that's > also pretty cool, might be nice for DebConf remote attendees if it > becomes more of a formal part of Debian) Matrix doesn't really do realtime A/V conferencing. The Matrix client "Riot Web" (and probably "Riot Desktop" as well, but not "Riot Android" or "Riot iOS" afaik) - offers a plugin to load Jitsi Meet in rooms. This means constraints like concurrent users and bandwidth load and reliability are same as when using https://meet.jit.si/ - benefit is convenience of all Riot users in a Matrix room being auto-registered for the Jitsi Meet room as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: cdbs vs dh vs ...
Quoting Andreas Tille (2019-03-21 09:31:09) > On Thu, Mar 21, 2019 at 09:14:09AM +0100, Lucas Nussbaum wrote: > > On 21/03/19 at 08:38 +0100, Andreas Tille wrote: > > > > > > I do not want to turn this into a cdbs to dh flamewar. > > May be I failed despite (or because??) I stated it explicitly? > > I've set "Reply-To" to debian-devel and please if this should be > really discussed lets move it there. > > I'm adding Jonas Smedegaard (as far as I know the only active > developer - Jonas please correct me if I'm wrong but Git commits are > basically from you) to comment on this topic. Jonas, I remember on > one of the DebConfs in the last three years (forgot which one) you > told me about your plan about cdbs. May be that's the right moment to > comment here. Yes, I indeed made many git commits related to cdbs. No, I decline fuelling this non-cdbs-flamewar - here or on d-devel. Sorry to everyone else for the noise. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Q to both candidates: preventing burnout by other contributors
Quoting Russ Allbery (2017-03-29 18:33:59) > In Debian, we have very few tools short of outright explusion from the > project, which obviously everyone is very reluctant to use, and > everyone knows that. Thankfully we have not yet expluded anyone. Sorry, couldn't resist. Thanks for the your intelligent input, Russ - as always! - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]
Quoting Josh Triplett (2014-10-30 15:04:04) > Aigars Mahinovs wrote: >> Fedora actually is not that decisive, as far as I read here - >> https://fedorahosted.org/fpc/ticket/243 > > That ticket turned down the suggested policy of "packages MUST NOT > support sysvinit". That doesn't mean "packages MUST support > sysvinit", or "packages MUST NOT depend on systemd". > > The Fedora policy: "Packages may also provide a SysV initscript file, > but are not required to do so." That does not sound to me as Fedora _only_ supporting systemd, or am I missing something? As a reminder, here's what I believe we are talking about here: Quoting Aigars Mahinovs (2014-10-30 11:06:47) > Have other distros switched to _only_ supporting systemd? Changing the > default is not the same. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
