Re: Is there room for improvement in our collaboration model?
On April 15, 2022 2:24:33 PM GMT+02:00, Luca Boccassi wrote: >On Fri, 2022-04-15 at 00:17 -0400, M. Zhou wrote: >> Hi, >> >> I just noted this problem recently. Our model for team collaboration >> (specifically for >> package maintenance) is somewhat primitive. >> >> We are volunteers. Nobody can continuously maintain a package for decades >> like a machine. >> Currently our practice for accepting other people's help involves: >> (1) low-threshold NMU. This is not quite easy to lookup (only shows on >> tracker.d.o, etc) >> (2) VAC note in debian-private channel. Who remembers you said the others >> can help you >> upload a package? And when does that temporary permission expire? What >> tracks that? >> (3) salsa permission. Yes, after joining the salsa team, others can commit >> code as they like. >> However, when it needs to be uploaded, the others still have to write mail >> to the maintainer >> for an ack. Whether multiple peoples should commit at the same time is >> coordinated through >> emails in order to avoid duplicated work. >> (4) last-minute NMU/delayed. When the others cannot bear an RC bug anymore, >> they may >> want to nmu upload to the delayed queue. >> (5) intend to salvage. When the others cannot hear from me for very long >> time, this >> is the only formal way to take over maintanence (afaik). >> >> The problems are: >> (1) whether multiple people should work on the same package at the same time >> is >> based on human communication. Namely, acquiring lock and releasing lock on a >> package >> is done through human communication. This is clearly something could be >> improved. >> It should be some program to acquire and release the lock. >> (2) different packages are clearly regarded differently by people. >> I'm actually very open to the other people hijacking some of my selected >> packages >> and fix these packages as they like. Namely, I think there should be a >> system where >> we can optionally tag our packages as: >> >> A. The other DDs can do whatever they like to this package and upload >> directly >> without asking me in a hijacking way. >> B. May git commit but should ask before upload. >> C. Must ask before any action. >> D. ... >> >> You know that in parallel programming, optimizing IPC (in this context it >> would be >> inter-DD communication) and optimizing the locking mechanism could help. >> >> My motivation for pointing these stems from some uncomfortable feelings when >> it's hard to get response from busy maintainers. If I understand correctly, >> technically DDs have enough permission to hijack any package and do the >> upload. >> People are polite and conservative to not abuse that power. But ... in order >> to >> improve contributor experience in terms of collaboration ... maybe we can >> use that tagging mechanism to formally allow a little bit of upload >> permission abuse. >> >> I think this will also improve newcomer's contributing experience. >> This proposal is also filed at >> https://salsa.debian.org/debian/grow-your-ideas/-/issues/34 > >What about doing something even simpler - rather than having additional >generic/core tags/teams/groups, for packages where one wants to say >"please help yourself/ourselves", simply set the Maintainer field to >debian-devel@lists.debian.org, have the Salsa repository in the debian/ >namespace, and that's it? From thereon, anyone can do team-uploads by >pushing to salsa and uploading directly, no need for >acks/delays/permissions/requests. > This is something I have been thinking about for a while, but didn't took the time to propose. But rather using a specific mailing list (e.g. debian-cooperative@somewhere). I'd be happy to put grep and bzip2 under such Maintainer:, if other co maintainers do not object. -- Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.
Solokeys (was: Nitrokey for DDs)
El 09/09/20 a las 21:32, Jonas Smedegaard escribió: > Quoting Zlatan Todorić (2020-09-09 20:21:18) > > On 9/9/20 7:48 PM, jathan wrote: … > So for folks as weakly skilled as myself in the art of Open Source > Hardware, a shortcut is to try lookup the product at > https://certification.oshwa.org/list.html > > Currenly that database lists 6 nitrokey products as being Open Source > Hardware Alliance certified. … Solokeys are other security key option listed in the above database: https://solokeys.com Somu, the tiny version, "hides" nicely in an USB-A port: https://solokeys.com/products/somu-tiny-security-key-two-factor-authentication-u2f-and-fido2-usb-a (similar to one of the yubikey versions) However, AFAIKS, OpenPGP support is still on development. Cheers, -- Santiago signature.asc Description: PGP signature
Re: Music player & privacy (was: ITP: elisa)
El 10/04/18 a las 10:50, W. Martin Borgert escribió: > Quoting Paul Wise : > > I think we need a privacy team. Such a team could verify the privacy > > status of packages and record that information centrally. > > I agree. And volunteer. > > (Messages with the word "volunteer" in the body are never signed.) Instead of a new team… I wonder if the pkg-privacy-team could be interested in addressing this task/idea. signature.asc Description: PGP signature
Re: Alioth: the future of mailing lists
El 19/09/17 a las 15:16, Wouter Verhelst escribió: > On Mon, Sep 18, 2017 at 02:55:26PM +0200, Raphael Hertzog wrote: > > Hello Axel, > > > > On Mon, 18 Sep 2017, Axel Beckert wrote: > > > Alexander Wirt wrote: > > > > - Distribution lists for use in the Maintainer: field. We suggest > > > > that, with maybe some extra code, this use-case could be well served > > > > by the tracker.debian.org service for almost all purposes. > > > > > > Reading https://tracker.debian.org/docs/about.html#email-interface it > > > seems that the e-mail address @tracker.debian.org is usable > > > not only for tracker-generated mails. > > > > Hum, that documentation is a bit outdated. What you have to use is > > actually dispatch+@tracker.debian.org. But I would not want > > people to use this email address in Maintainer fields. > > > > Instead we should use @packages.debian.org. But for this we > > need a lintian upload and a lintian backport to be installed on > > ftp-master: > > Er, that would create a mail loop. @packages.debian.org > redirects to the data of the maintainer field. If you put that address > in the maintainer field, it redirects to itself, again and again and > again and again and... > > Not a good idea. And what about something like (different to dispatch+): Maintainer: +pack...@tracker.debian.org Uploaders: Actual people and their mail addresses This +package would redirect to the Uploaders and subscribers and not to itself. cheers, -- Santiago
Bug#880974: ITP: lua-ljsyscall -- Unix system calls for LuaJIT
Package: wnpp Severity: wishlist Owner: "Santiago R.R." * Package name: lua-ljsyscall Version : 0.12 Upstream Author : Justin Cormack * URL : http://myriabit.com/ljsyscall/ * License : MIT/X Programming Lang: Lua Description : Unix system calls for LuaJIT A foreign function interface (FFI) implementation of the Linux, NetBSD, FreeBSD and OSX kernel ABIs for LuaJIT. This means you will be able to program all the functionality the Unix kernel provides to userspace directly in Lua. You can view it as a high level language equivalent of the Busybox project in a way, although the functionality it provides is somewhat different, and the interface very different. This is a dependency for https://github.com/vavrusa/ljdns Comaintaining it with the help of Lua packaging team would be great.
Bug#880975: ITP: lua-ljdns -- DNS library for LuaJIT
Package: wnpp Severity: wishlist Owner: "Santiago R.R." * Package name: lua-ljdns Version : 2.4 Upstream Author : Marek Vavruša * URL : https://github.com/vavrusa/ljdns * License : BSD-2-clause Programming Lang: Lua Description : DNS library for LuaJIT A contemporary DNS library using LuaJIT FFI focused on performance, and a lightning-fast zone file parser. It supports all widely used DNS records (DNSSEC included) with a lean and mean API, including DNS primitives, messages and asynchronous I/O (including coroutines, TCP Fast Open and SO_REUSEPORT), and DNS over TLS. Co-maintaining it with the Lua packaging team would be great
Re: ISO download difficult
El 05/12/17 a las 10:19, Thibaut Paumard escribió: > Dear Sean, > > Le 04/12/2017 à 21:47, Sean Whitton a écrit : > > Hello, > > > > On Mon, Dec 04 2017, Thibaut Paumard wrote: > > > > > I vote for: > > > 1- putting the non-free firmware on all our images, > > > > This seems more controversial than it needs to be, and misses an > > opportunity for us to express our values. > > > > Why are you against maintaining the fullly free images alongside those > > with non-free firmware? The issue is that the latter are hidden, not > > that there's anything much wrong with the former. > > > > Mostly because we should keep it (or rather make it) as simple as possible > to install Debian. > > I also believe this should be less controversial. I don't see any problem > with shipping non-free firmware on our main installation media as long as > they are redistributable, because I don't consider them part of the OS. The > user has this hardware, to use it she needs the OS to upload that third-pary > blob to her device, let's allow her to do that easily. > > Having the two download links side by side on the front page would already > be a major improvement, but it would still be very confusing for our users. > That's why I would prefer to put the "beware of the leopard" sign inside the > install medium, and provide only one medium that would work for both kinds > of users. … It's surely not the perfect approach, but I think this would be the best option if Debian wants to attract new non-expert users. -- Santiago signature.asc Description: PGP signature
