Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)
Hi again, I've just created a preliminary Sprint page[2]. At the top I've added a table to summarise first responses of participants about the date. Seems we have a vague preference for the date 2022-02-18 - 2021-02-20. I'd be really happy if more interested people would show up and add the prefered date to get a final decision about the sprint date. Newcomers to the team are always welcome. I plan to do some packaging introduction for those who might need this to get a kick-start. People who are undecided might like to show up in our video conference today[3] See you in virtual space Andreas. [2] https://salsa.debian.org/med-team/community/sprints/-/wikis/202202_debian-med_sprint_online [3] https://lists.debian.org/debian-med/2022/02/msg00011.html Am Mon, Jan 24, 2022 at 04:09:02PM +0100 schrieb Andreas Tille: > Hi folks, > > on Mon, 21 Jan 2002 11:59:11 +0100 the first mail to this list was > sent[1]. So somehow we can celebrate some anniversary. :-) > > Since 11 years we are doing team sprints - preferably face to face > but last year it was not possible and thus we did it online. Same > seems to be true for this year. I'd suggest a three days meeting > either from > > Friday 11.2. - Sunday 13.2. or > Friday 18.2. - Sunday 20.2. > > We can use > > https://app.element.io/#/room/#_oftc_#debian-ftp:matrix.org > > as meeting space and can do Jitsi meetings every second hour as > we did last year. > > I'd be happy if people who intend to join would confirm joining > the sprint and what date might be prefered. > > Kind regards > > Andreas. > > [1] https://lists.debian.org/debian-med/2002/01/msg0.html > > -- > http://fam-tille.de > > -- http://fam-tille.de
Bug#1004846: ITP: libauthen-webauthn-perl -- Perl module to add Web Authentication support to server applications
Package: wnpp Severity: wishlist Owner: Yadd X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libauthen-webauthn-perl Version : 0.0.1 Upstream Author : Lemonldap::NG Team * URL : https://metacpan.org/release/Authen-WebAuthn * License : GPL-2+ Programming Lang: Perl Description : Perl module to add Web Authentication support to server applications The goal of WebAuthn is to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. Authen::WebAuthn is a port of it for Perl based applications. It is a dependency of next version of lemonldap-ng (2.0.14). package will be maintained under Perl team Umbrella.
Re: Legal advice regarding the NEW queue
Hi Wookey, Am Tue, Feb 01, 2022 at 02:07:21PM + schrieb Wookey: > Has anyone on the actual FTP team responded to this thread yet? (sorry, I > can't remember who that is currently) > > Either on Andreas's original simple question: 'Do we still _have_ to keep the > binary-NEW thing?' > Or this more complex question: Is NEW really giving us a pain:risk ratio that > is appropriate? > > Andreas tried hard to get someone to just stick to the first matter > and answer that. I don't recall seeing an answer from FTP-master yet? Me neither. In my eyes its a problem that it is hard to comminicate with ftpmaster team. I tried on IRC as well but I prefer mailing list since this is recorded online. Thank you for this question Andreas. -- http://fam-tille.de
Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)
Andreas Tille writes: > Hi again, > > I've just created a preliminary Sprint page[2]. At the top I've added a > table to summarise first responses of participants about the date. > Seems we have a vague preference for the date 2022-02-18 - 2021-02-20. > > I'd be really happy if more interested people would show up and add > the prefered date to get a final decision about the sprint date. I don't have push access to the repo, but feel free to add that I can probably join on the 18th and on the 20th of February, if you end up picking 18-20. -- Gard signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
On Wed, 2022-02-02 at 13:44 +0100, Andreas Tille wrote: > Hi Wookey, > > Am Tue, Feb 01, 2022 at 02:07:21PM + schrieb Wookey: > > Has anyone on the actual FTP team responded to this thread yet? > > (sorry, I can't remember who that is currently) > > > > Either on Andreas's original simple question: 'Do we still _have_ > > to keep the binary-NEW thing?' > > Or this more complex question: Is NEW really giving us a pain:risk > > ratio that is appropriate? > > > > Andreas tried hard to get someone to just stick to the first matter > > and answer that. I don't recall seeing an answer from FTP-master > > yet? > > Me neither. In my eyes its a problem that it is hard to comminicate > with ftpmaster team. I tried on IRC as well but I prefer mailing > list > since this is recorded online. > Without answer from FTP team, it's hard to reach anywhere constructive with respect to this problem. They have the most accurate understanding on what part needs to be improved or revised. Of course I can propose ideas based on my shallow experience and speculation, but ideas in this thread will largely going to sink unless there is any effective way to make real progress on it.
Re: Legal advice regarding the NEW queue
On Tue, Feb 01 2022, Russ Allbery wrote: > I would hate to entirely lose the quality review that we get via NEW, but > I wonder if we could regain many those benefits by setting up some sort of > peer review system for new packages that is less formal and less > bottlenecked on a single team than the current NEW processing setup. This is a fantastic idea. In fact, it wouldn't have to bottleneck packages at all. I mean, if a quality issue is found in NEW, wouldn't the same be an RC bug preventing a transition to testing? - John
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote: On Tue, Feb 01 2022, Russ Allbery wrote: I would hate to entirely lose the quality review that we get via NEW, but I wonder if we could regain many those benefits by setting up some sort of peer review system for new packages that is less formal and less bottlenecked on a single team than the current NEW processing setup. This is a fantastic idea. In fact, it wouldn't have to bottleneck packages at all. I mean, if a quality issue is found in NEW, wouldn't the same be an RC bug preventing a transition to testing? I'm not sure "nobody ever looked at this" is a suitable criteria for inclusion in a stable release. We sort of have that problem now in crusty corners of the archive if someone uploads a bad change, but at least there's been one review at some point in the package's lifetime.
Re: Legal advice regarding the NEW queue
On 2022-02-02 at 11:21, Michael Stone wrote: > On Wed, Feb 02, 2022 at 09:39:02AM -0600, John Goerzen wrote: > >> On Tue, Feb 01 2022, Russ Allbery wrote: >> >>> I would hate to entirely lose the quality review that we get via >>> NEW, but I wonder if we could regain many those benefits by >>> setting up some sort of peer review system for new packages that >>> is less formal and less bottlenecked on a single team than the >>> current NEW processing setup. >> >> This is a fantastic idea. >> >> In fact, it wouldn't have to bottleneck packages at all. I mean, >> if a quality issue is found in NEW, wouldn't the same be an RC bug >> preventing a transition to testing? > > I'm not sure "nobody ever looked at this" is a suitable criteria for > inclusion in a stable release. We sort of have that problem now in > crusty corners of the archive if someone uploads a bad change, but at > least there's been one review at some point in the package's > lifetime. Doesn't that, then, lead to the suggestion that any package entering unstable without having undergone NEW review (which, in the revised model, might be every new package) should automatically have a bug filed against it requesting suitable review, and that bug should be treated as a blocker for entering testing? That wouldn't help the "someone uploads a bad change" problem for already-accepted packages, but it would seem to avoid the "nobody ever looked at this" situation. It would also increase the number of automatically-filed bugs by quite a lot, I suspect, which would itself be some degree of downside... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > >>> I would hate to entirely lose the quality review that we get via > >>> NEW, but I wonder if we could regain many those benefits by > >>> setting up some sort of peer review system for new packages that > >>> is less formal and less bottlenecked on a single team than the > >>> current NEW processing setup. > >> > >> This is a fantastic idea. > >> > >> In fact, it wouldn't have to bottleneck packages at all. I mean, > >> if a quality issue is found in NEW, wouldn't the same be an RC bug > >> preventing a transition to testing? > > > > I'm not sure "nobody ever looked at this" is a suitable criteria for > > inclusion in a stable release. We sort of have that problem now in > > crusty corners of the archive if someone uploads a bad change, but at > > least there's been one review at some point in the package's > > lifetime. > > Doesn't that, then, lead to the suggestion that any package entering > unstable without having undergone NEW review (which, in the revised > model, might be every new package) should automatically have a bug filed > against it requesting suitable review, and that bug should be treated as > a blocker for entering testing? > > That wouldn't help the "someone uploads a bad change" problem for > already-accepted packages, but it would seem to avoid the "nobody ever > looked at this" situation. > > It would also increase the number of automatically-filed bugs by quite a > lot, I suspect, which would itself be some degree of downside... This will also decrease the number of new packages in testing, which can be considered an upside too... -- WBR, wRAR signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: Doesn't that, then, lead to the suggestion that any package entering unstable without having undergone NEW review (which, in the revised model, might be every new package) should automatically have a bug filed against it requesting suitable review, and that bug should be treated as a blocker for entering testing? Not really, since anyone in the world could close said bug (including the uploader).
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote: > On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > > Doesn't that, then, lead to the suggestion that any package entering > > unstable without having undergone NEW review (which, in the revised > > model, might be every new package) should automatically have a bug filed > > against it requesting suitable review, and that bug should be treated as > > a blocker for entering testing? > > Not really, since anyone in the world could close said bug (including the > uploader). This applies to any RC bug. -- WBR, wRAR signature.asc Description: PGP signature
Re: Legal advice regarding the NEW queue
On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote: On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote: On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > Doesn't that, then, lead to the suggestion that any package entering > unstable without having undergone NEW review (which, in the revised > model, might be every new package) should automatically have a bug filed > against it requesting suitable review, and that bug should be treated as > a blocker for entering testing? Not really, since anyone in the world could close said bug (including the uploader). This applies to any RC bug. Yes, but in this case it means that we wouldn't have that minimal standard of at least one person other than the uploader having ever reviewed the package--which I think is a fairly low bar that we should meet. (It would be even better if we could add reviews for changes, but at any rate I don't think we should go backward here.)
Re: Legal advice regarding the NEW queue
Dear list, On 02/02/2022 18:46, Michael Stone wrote: On Wed, Feb 02, 2022 at 10:16:36PM +0500, Andrey Rahmatullin wrote: On Wed, Feb 02, 2022 at 12:12:30PM -0500, Michael Stone wrote: On Wed, Feb 02, 2022 at 11:39:11AM -0500, The Wanderer wrote: > Doesn't that, then, lead to the suggestion that any package entering > unstable without having undergone NEW review (which, in the revised > model, might be every new package) should automatically have a bug filed > against it requesting suitable review, and that bug should be treated as > a blocker for entering testing? Not really, since anyone in the world could close said bug (including the uploader). This applies to any RC bug. Yes, but in this case it means that we wouldn't have that minimal standard of at least one person other than the uploader having ever reviewed the package--which I think is a fairly low bar that we should meet. (It would be even better if we could add reviews for changes, but at any rate I don't think we should go backward here.) This is basically a question of social contracts and tooling. It can IMHO certainly be done. But isn't this discussion on details moot until we clear out the fundamentals such as the legal risk/cost analysis of dropping the NEW queue in its current form i. e., the topic for this thread? And not least, some input from the ftp-masters team -- this discussion is about a huge change in a process they currently manage. Cheers, --alec
Re: Legal advice regarding the NEW queue
John Goerzen writes: > On Tue, Feb 01 2022, Russ Allbery wrote: > >> I would hate to entirely lose the quality review that we get via NEW, but >> I wonder if we could regain many those benefits by setting up some sort of >> peer review system for new packages that is less formal and less >> bottlenecked on a single team than the current NEW processing setup. > > This is a fantastic idea. > > In fact, it wouldn't have to bottleneck packages at all. I mean, if a > quality issue is found in NEW, wouldn't the same be an RC bug preventing > a transition to testing? Looking at https://ftp-master.debian.org/REJECT-FAQ.html it looks like one could assemble many of these potential issues into a checklist that ought to be easily within the abilities of any DD to apply. If that assumption is true, we could require that one performs some number of such reviews on packages already in NEW before gaining the right to add another one of your own. Of course, we'd need some way of allocating packages to reviewers, and some way for reviewers to submit their reviews, which would need writing, but once that was done this should ensure that the effort required to do initial checks on packages was spread out more, enabling team members to concentrate on the more skilled bits of the process. It might also act as a recruiting ground for people to get more heavily involved in the FTP team. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg,GERMANY signature.asc Description: PGP signature
Bug#1004878: ITP: golang-github-google-gousb -- provides low-level interface for accessing USB devices
Package: wnpp Severity: wishlist Owner: Francisco Vilmar Cardoso Ruviaro X-Debbugs-Cc: debian-devel@lists.debian.org, debian...@lists.debian.org, francisco.ruvi...@riseup.net, math...@calenhad.com * Package name: golang-github-google-gousb Version : 1.1.1 Upstream Author : Google * URL : https://github.com/google/gousb * License : Apache-2.0 Programming Lang: Go Description : provides low-level interface for accessing USB devices gousb is an attempt at wrapping the libusb library into a Go-like binding. . gousb provides low-level interface for accessing USB devices. . The gousb project provides a simple but useful example: lsusb. lsusb will list the USB devices connected to your system and various interesting tidbits about them, their configurations, endpoints, etc. Reason for packaging: This package is one of the dependencies for bettercap (https://github.com/bettercap/bettercap)
Re: Please participate in Debian Med sprint (Was: 20 years of Debian Med list :-) and suggested sprint date)
Hi Gard, Am Wed, Feb 02, 2022 at 02:29:44PM +0100 schrieb Gard Spreemann: > I don't have push access to the repo, but feel free to add that I can > probably join on the 18th and on the 20th of February, if you end up > picking 18-20. You can push now and we are happy that you intend to join Andreas. -- http://fam-tille.de
