Bug#1103576: ITP: sphinx-needs -- Brings Engineering-as-Code to the Sphinx framework

/sphinx- needs/graphs/contributors * License : (MIT) Programming Lang: (Python, javascript) Description : Brings Engineering-as-Code to the Sphinx framework Combine Docs-as-Code with Application Lifecycle Management, to track requirements, specifications, test cases, and other engineering

Bug#1101373: ITP: python-pytest-shell-utilities -- fixtures and code to help with running shell commands on tests

://github.com/saltstack/pytest-shell-utilities * License : Apache-2 Programming Lang: Python Description : fixtures and code to help with running shell commands on tests This pytest plugin provides a basic fixture shell which uses subprocess.Popen to run commands against the running

Bug#1099652: ITP: bacon -- background code checker

: Rust Description : background code checker bacon is a code checker designed to run in the background, alongside your editor, with minimal interaction, notifying you of warnings, errors or test failures. It was originally developed for Rust/cargo, but recently gained support ("analyzers&q

Bug#1099538: ITP: rust-axum-server -- hyper server implementation used with axum - Rust source code

: MIT/Expat Programming Lang: Rust Description : hyper server implementation used with axum - Rust source code -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature

Bug#1098309: ITP: qrca -- QR code scanner

* License : GPL3 Programming Lang: c++ Description : QR code scanner This is a qr code scanner. Seems to work. It's unreleased but already works. I plan to maintain this within the qt-kde team

Bug#1096132: ITP: golang-github-code-hex-go-generics-cache -- Key:value store/cache library written in Go generics

Package: wnpp Severity: wishlist Owner: Martina Ferrari * Package name: golang-github-code-hex-go-generics-cache Version : 1.5.1-1 Upstream Author : Kei Kamikawa * URL : https://github.com/Code-Hex/go-generics-cache * License : Expat Programming Lang: Go

Re: Reminder: Call for Debian projects and mentors in Google Summer of Code 2025

Just as a PSA... Abhijith PA dijo [Mon, Feb 10, 2025 at 07:56:39PM +0530]: > Hi, > > This is a *reminder* call to submit Debian projects for GSoC25. The > deadline for the same is Feb 11 1800 UTC. (roughly ~27 hours) > > == Proposing a Project == > > Add your project idea to the GSoC'25 Debian

Bug#1095079: ITP: golang-github-maxmind-geoipupdate -- GeoIP update client code

: GeoIP update client code (lib only) Needed to package a newer version of Syncthing -- Félix signature.asc Description: PGP signature

Bug#1094810: ITP: golang-go4-unsafe-assume-no-moving-gc -- declare Go code that play unsafe GC games

://github.com/go4org/unsafe-assume-no-moving-gc * License : BSD-3-clause Programming Lang: Go Description : declare Go code that play unsafe GC games go4.org/unsafe/assume-no-moving-gc . If your Go package wants to declare that it plays unsafe games that only work if the Go

Re: Let's make 2025 a year when code reviews became common in Debian

can look up the bug report in the BTS. On Fri Jan 24, 2025 at 12:32 AM GMT, Otto Kekäläinen wrote: Yes, for bugs that makes sense. Please note however that Merge Requests is more than just patches/bug fixes. It is a general mechanism to facilitate code reviews. It does not necessarily make sense t

Re: Let's make 2025 a year when code reviews became common in Debian

On Fri Jan 24, 2025 at 11:22 AM GMT, Johannes Schauer Marin Rodrigues wrote: I'm likely in lack of understanding here but I have not yet understood the utility of merge commits. You say that they could be useful to attach git notes to it. But can these notes not also attached to regular commits

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Andreas Tille (2025-01-29 15:06:15) > Am Sun, Jan 26, 2025 at 01:06:00AM +0100 schrieb gregor herrmann: > > The alternative -- and that's what we did in pkg-perl -- is to have > > the Janitor just commit to our repos instead of filing merge > > requests: > > https://salsa.debian.org/janitor

Re: Let's make 2025 a year when code reviews became common in Debian

Am Sun, Jan 26, 2025 at 01:06:00AM +0100 schrieb gregor herrmann: > The alternative -- and that's what we did in pkg-perl -- is to have > the Janitor just commit to our repos instead of filing merge > requests: > https://salsa.debian.org/janitor-team/janitor.debian.net/-/blob/master/k8s/policy.conf

Re: Let's make 2025 a year when code reviews became common in Debian

On Wed, 15 Jan 2025 08:43:21 +0100, Andreas Tille wrote: > However, in all teams I'm deeply involved we asked Jelmer to not run > Janitor automatically on the Git repositories. The rationale is, that > if a package is not uploaded commits by the Janitor might become > outdated - well, finally wha

Re: Let's make 2025 a year when code reviews became common in Debian

Le 2025-01-25 19:22, Julien Plissonneau Duquène a écrit : Wayback Machine FTR this project [1], according to this interview [2] (transcript [3] search for "discussions") now aims to also archive the discussions happening on merge requests and issues. So there is some hope for future-proof ar

Re: Let's make 2025 a year when code reviews became common in Debian

Le 2025-01-25 19:02, Simon McVittie a écrit : (I assume the Salsa admins do have a way to permanently redact a discussion thread that contains something illegal or abusive, if it becomes necessary.) It is also possible for the creator of a merge request (and probably for the repository owners

Re: Let's make 2025 a year when code reviews became common in Debian

Le 2025-01-25 17:04, Richard Lewis a écrit : I think that sounds like a lot of work in order to duplicate a subset of the existing functionality -- is another bespoke system what debian needs? A more affordable option could be to implement some of the features in the salsa CLI from `devscri

Re: Let's make 2025 a year when code reviews became common in Debian

On Sat, 25 Jan 2025 at 17:40:26 +0100, Jonas Smedegaard wrote: > When I post to a discussion at Salsa, then for how long is my post > publicly available? In general: until the project containing the discussion is deleted. A "project" in Gitlab jargon is the thing that wraps a git repository; more

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Philipp Kern (2025-01-25 16:05:25) > On 1/23/25 8:46 PM, Simon Josefsson wrote: > > Jonas Smedegaard writes: > >> Are discussions at Salsa preserved years down the line? > > That is a good point. Are there any mirrors of Salsa at all? Having > > continous replication to a couple of addit

Re: Let's make 2025 a year when code reviews became common in Debian

Julien Plissonneau Duquène writes: > Le 2025-01-24 13:00, Andrea Pappacoda a écrit : >> Same for me. In addition, on the topic of making things easier for >> new >> contributors, when I first started using Salsa I felt lost in the >> myriad >> of features and options enabled by default. Not only

Re: Let's make 2025 a year when code reviews became common in Debian

On Fri Jan 24, 2025 at 4:49 PM GMT, Fabio Fantoni wrote: I recently saw this project that seems good to slightly improve some things, for example: https://fabre.debian.net/ This looks interesting! The BTS has (or had) a SOAP(!) API. 17 years ago I tried writing a desktop tool to try and mak

Re: Let's make 2025 a year when code reviews became common in Debian

On 1/23/25 8:46 PM, Simon Josefsson wrote: Jonas Smedegaard writes: Are discussions at Salsa preserved years down the line? That is a good point. Are there any mirrors of Salsa at all? Having continous replication to a couple of additional read-only instance would be useful, in case Salsa bu

Re: Let's make 2025 a year when code reviews became common in Debian

On Fri, 2025-01-24 at 17:49 +0100, Fabio Fantoni wrote: > > If we want to continue to use mainly BTS I think you should have an > integration with something that allows you to do more things from the > web interface, in a simple and fast way. > > I recently saw this project that seems good to s

Re: Let's make 2025 a year when code reviews became common in Debian

ernal dependency on Salsa/GitLab. Spending time writing the code that automates that is a much better investment compared to copying stuff back and forth between BTS/Salsa/mailing lists. > But why a merge commit? I usually configure my salsa repos to *not* create merge commits but instead rebase the M

Re: Let's make 2025 a year when code reviews became common in Debian

Hi Colin, Colin Watson writes: > On Thu, Jan 23, 2025 at 10:57:56PM -0800, Xiyue Deng wrote: >> Actually there may be another reason to turn off MR feature: some >> packaging workflows don't preserve a linear Git history and hence may >> not work well with merging from MR on Salsa. For example,

Re: Let's make 2025 a year when code reviews became common in Debian

only recently contacted the welcome team and have been following the mailing lists while waiting for my salsa account approval. From what I've seen so far, Debian's development process can be quite challenging to understand as a newcomer. In my opinion, having a more intuitive web interface

Bug#1094025: ITP: cxxbridge-cmd -- C++ code generator for integrating `cxx`

* URL : https://github.com/dtolnay/cxx/blob/master/gen/cmd/ * License : MIT or Apache 2.0 Description : C++ code generator for integrating `cxx` crate into a non-Cargo build This package is a binary-only rust program that serves as bridge between the rust-cxx library

Re: Let's make 2025 a year when code reviews became common in Debian

ome new contributors, or in general work in a > > > collaborative way towards ending single-maintainer packages, reviewing > > > MRs posted by others a great way to help out. > > > > That reads very strange to me: > > > > * If I want Debian to grow, the

Re: Let's make 2025 a year when code reviews became common in Debian

> Is there some way to drill down into groups and then set preferences on > an individual repo that's not in one's own namespace? Yes - you can for example open https://salsa.debian.org/debian/openqa and in the top right corner click on the bell icon, and select "Watch". That will make you get not

Re: Let's make 2025 a year when code reviews became common in Debian

Le 2025-01-24 13:00, Andrea Pappacoda a écrit : Same for me. In addition, on the topic of making things easier for new contributors, when I first started using Salsa I felt lost in the myriad of features and options enabled by default. Not only 99% of projects hosted on Salsa don't need featur

Re: Let's make 2025 a year when code reviews became common in Debian

ending single-maintainer packages, reviewing > > MRs posted by others a great way to help out. > > That reads very strange to me: > > * If I want Debian to grow, then I want Salsa code reviews. > * If I want to welcome new contributors, then I want Salsa code reviews. > *

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Christoph J. Scherr (2025-01-24 15:26:39) > Writing a Pro/Con list might be a good idea, but I am not proficient > enough in both the BTS and GitLab to do so. That sounds like an excellent approach to me. I will leave that for others, as I have lost my bearing on what is on topic for this

Re: Let's make 2025 a year when code reviews became common in Debian

> "Gioele" == Gioele Barabucci writes: Gioele> On 24/01/25 13:18, Colin Watson wrote: >> I agree with this. From Otto in another thread: >> >> "It is sad to see that in Debian usage of git is stifled by >> simple things like people not agreeing to use a common branch

Re: Let's make 2025 a year when code reviews became common in Debian

as a > > newcomer. > > > > In my opinion, having a more intuitive web interface through a code forge > > like > > GitLab would lower the barrier to entry for potential contributors. I > > believe > > that normalizing merge requests would particularly benefi

Re: Let's make 2025 a year when code reviews became common in Debian

gt; preserved and the Git repo will contain the whole development history, > > freeing Debian from an eternal dependency on Salsa/GitLab. > > In real life nobody does that. Among other issues, the discussion may > continue long after the commits are merged. Or the commits may end up

Re: Let's make 2025 a year when code reviews became common in Debian

On 24/01/25 13:18, Colin Watson wrote: I agree with this. From Otto in another thread: "It is sad to see that in Debian usage of git is stifled by simple things like people not agreeing to use a common branch naming scheme despite there being a proposal for 10+ years now." I use git e

Re: Let's make 2025 a year when code reviews became common in Debian

gt; > > That reads very strange to me: > > > > * If I want Debian to grow, then I want Salsa code reviews. > > * If I want to welcome new contributors, then I want Salsa code reviews. > > * If I want to work collaboratively, then I want Salsa code reviews. > > >

Re: Let's make 2025 a year when code reviews became common in Debian

On Thu, Jan 23, 2025 at 07:35:23PM -0700, Sam Hartman wrote: > > "Otto" == Otto Kekäläinen writes: > > Otto> Could you give it a try please? Salsa isn't that bad :) > > Can you please respect people who have different positions than you? > I'm this close to turning off MRs for all my pac

+1 (Re: Let's make 2025 a year when code reviews became common in Debian)

On Fri, Jan 24, 2025 at 12:18:18PM +, Colin Watson wrote: > > Otto> Could you give it a try please? Salsa isn't that bad :) > > Can you please respect people who have different positions than you? > > I'm this close to turning off MRs for all my packages and promising to > > be the last per

Re: Let's make 2025 a year when code reviews became common in Debian

On Thu, Jan 23, 2025 at 10:57:56PM -0800, Xiyue Deng wrote: > Actually there may be another reason to turn off MR feature: some > packaging workflows don't preserve a linear Git history and hence may > not work well with merging from MR on Salsa. For example, the "git-dpm" > and "git-debrebase" wo

Re: Let's make 2025 a year when code reviews became common in Debian

Hi all, On Fri Jan 24, 2025 at 10:50 AM CET, Jonas Smedegaard wrote: Quoting Chris Hofstaedtler (2025-01-24 01:51:27) BTW, a lot of other gitlab features should probably be off for most packaging repositories. Currently, when I create a new project at Salsa, I do the following: 1. Among the

Re: Let's make 2025 a year when code reviews became common in Debian

t; grow and you want to welcome new contributors, or in general work in a > > collaborative way towards ending single-maintainer packages, reviewing > > MRs posted by others a great way to help out. > > That reads very strange to me: > > * If I want Debian to grow, then

Re: Let's make 2025 a year when code reviews became common in Debian

ut. > > > > That reads very strange to me: > > > > * If I want Debian to grow, then I want Salsa code reviews. > > * If I want to welcome new contributors, then I want Salsa code reviews. > > * If I want to work collaboratively, then I want Salsa code reviews. &g

Re: Let's make 2025 a year when code reviews became common in Debian

n from an eternal dependency on Salsa/GitLab. > > Spending time writing the code that automates that is a much better > investment compared to copying stuff back and forth between BTS/Salsa/mailing > lists. this is the first time I hear about "git notes". I skimmed its man page.

Re: Let's make 2025 a year when code reviews became common in Debian

row and you want to welcome new contributors, or in general work in a > > collaborative way towards ending single-maintainer packages, reviewing > > MRs posted by others a great way to help out. > > That reads very strange to me: > > * If I want Debian to grow, then I want Salsa

Re: Let's make 2025 a year when code reviews became common in Debian

ive way towards ending single-maintainer packages, reviewing > MRs posted by others a great way to help out. That reads very strange to me: * If I want Debian to grow, then I want Salsa code reviews. * If I want to welcome new contributors, then I want Salsa code reviews. * If I want to wor

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Chris Hofstaedtler (2025-01-24 01:51:27) > * Sam Hartman [250123 23:47]: > > > ... > > >> > Numerous people are posting Merge Requests on Salsa. Please > > >> help review them! > > > > I think it would improve collaboration a lot if we could make an effort > > to get salsa project

Re: Let's make 2025 a year when code reviews became common in Debian

Otto Kekäläinen writes: > Hi! > >> I think it would improve collaboration a lot if we could make an effort >> to get salsa projects into one of two states: >> >> * Merge requests are disabled for that project >> >> * Merge requests are actively watched at least as closely as the BTS > > We should

Re: Let's make 2025 a year when code reviews became common in Debian

endency on Salsa/GitLab. In real life nobody does that. Among other issues, the discussion may continue long after the commits are merged. Or the commits may end up never be merged. Spending time writing the code that automates that is a much better investment compared to copying stuff back

Re: Let's make 2025 a year when code reviews became common in Debian

epo will contain the whole development history, freeing Debian from an eternal dependency on Salsa/GitLab. Spending time writing the code that automates that is a much better investment compared to copying stuff back and forth between BTS/Salsa/mailing lists. Regards, -- Gioele Barabucci

Re: Let's make 2025 a year when code reviews became common in Debian

and accurate code review and efficient feedback among multiple participants, and efficient publication and re-review of code. All permanent documentation should to in inline comments, in READMEs in the repository or when explaining specifically *why* a change was made, it should be in the git commit

Re: Let's make 2025 a year when code reviews became common in Debian

Hi Otto, First I want to thank you for your work on Salsa. I find it pleasant to use and the Salsa CI has also helped catch many lurking bugs for me. Otto Kekäläinen writes: > ... > > I understand that some people like to turn of the MR feature > completely on their repositories, but I would a

Re: Let's make 2025 a year when code reviews became common in Debian

> "Otto" == Otto Kekäläinen writes: Otto> Hi, Otto> On Thu, 23 Jan 2025 at 17:52, Wookey wrote: Otto> .. >> Right. I look at bug reports for my packages (eventually). I have >> never looked at a Salsa merge request in my life. That's just >> /dev/null for my packages.

Re: Let's make 2025 a year when code reviews became common in Debian

On 2025-01-23 18:09 -0800, Otto Kekäläinen wrote: > Hi, > > On Thu, 23 Jan 2025 at 17:52, Wookey wrote: > .. > > Right. I look at bug reports for my packages (eventually). I have > > never looked at a Salsa merge request in my life. That's just > > /dev/null for my packages. That could change one

Re: Let's make 2025 a year when code reviews became common in Debian

be a place of permanent documentation. Okay, but I want code reviews to be a place of permanent documentation. I've had to do enough archaeology into why software decisions were made over the years that I believe permanent documentation is critical in a transparent project for anything along

Re: Let's make 2025 a year when code reviews became common in Debian

Hi, On Thu, 23 Jan 2025 at 17:52, Wookey wrote: .. > Right. I look at bug reports for my packages (eventually). I have > never looked at a Salsa merge request in my life. That's just > /dev/null for my packages. That could change one day, but I don't know when. Could you give it a try please? Sa

Re: Let's make 2025 a year when code reviews became common in Debian

On 2025-01-23 16:36 -0800, Otto Kekäläinen wrote: > I understand that some people like to turn of the MR feature > completely on their repositories, but I would advise against that, as > it is a major killer to collaboration. Not only does it signal to > contributors to the existing package that th

Re: Let's make 2025 a year when code reviews became common in Debian

On 2025-01-23 17:11 +, Colin Watson wrote: > On Thu, Jan 23, 2025 at 03:56:24PM +0100, Gioele Barabucci wrote: > > Or forget about the BTS and accept Salsa as the main place where > > improvements are discussed? > > As long as it's very commonly the case that nobody is actually > subscribed to

Re: Let's make 2025 a year when code reviews became common in Debian

* Sam Hartman [250123 23:47]: > > ... > >> > Numerous people are posting Merge Requests on Salsa. Please > >> help review them! > > I think it would improve collaboration a lot if we could make an effort > to get salsa projects into one of two states: > > * Merge requests are disabled fo

Re: Let's make 2025 a year when code reviews became common in Debian

Hi! > I think it would improve collaboration a lot if we could make an effort > to get salsa projects into one of two states: > > * Merge requests are disabled for that project > > * Merge requests are actively watched at least as closely as the BTS We should revisit the decision to have email no

Re: Let's make 2025 a year when code reviews became common in Debian

s down the line when I wonder "why did this change get > made" I can look up the bug report in the BTS. Yes, for bugs that makes sense. Please note however that Merge Requests is more than just patches/bug fixes. It is a general mechanism to facilitate code reviews. It does not necessari

Re: Let's make 2025 a year when code reviews became common in Debian

intended to be a place of permanent documentation. It is just a tool to facilitate fast and accurate code review and efficient feedback among multiple participants, and efficient publication and re-review of code. All permanent documentation should to in inline comments, in READMEs in the repository

Re: Let's make 2025 a year when code reviews became common in Debian

> "Jonas" == Jonas Smedegaard writes: Jonas> Quoting Matthew Vernon (2025-01-23 15:28:00) >> Otto Kekäläinen writes: >> >> > Numerous people are posting Merge Requests on Salsa. Please >> help review them! >> >> I'd much much rather MRs were associated with bug

Re: Let's make 2025 a year when code reviews became common in Debian

Jonas Smedegaard writes: > Quoting Gioele Barabucci (2025-01-23 15:56:24) >> On 23/01/25 15:28, Matthew Vernon wrote: >> > Otto Kekäläinen writes: >> > >> >> Numerous people are posting Merge Requests on Salsa. Please help >> >> review them! >> > >> > I'd much much rather MRs were associated w

Re: Let's make 2025 a year when code reviews became common in Debian

On Thu, Jan 23, 2025 at 03:56:24PM +0100, Gioele Barabucci wrote: > Or forget about the BTS and accept Salsa as the main place where > improvements are discussed? As long as it's very commonly the case that nobody is actually subscribed to merge requests on Salsa, it isn't realistic to expect revi

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Gioele Barabucci (2025-01-23 15:56:24) > On 23/01/25 15:28, Matthew Vernon wrote: > > Otto Kekäläinen writes: > > > >> Numerous people are posting Merge Requests on Salsa. Please help > >> review them! > > > > I'd much much rather MRs were associated with bug reports; that way > > I only

Re: Let's make 2025 a year when code reviews became common in Debian

Quoting Matthew Vernon (2025-01-23 15:28:00) > Otto Kekäläinen writes: > > > Numerous people are posting Merge Requests on Salsa. Please help review > > them! > > I'd much much rather MRs were associated with bug reports; that way I > only have to remember to check one place for outstanding iss

Re: Let's make 2025 a year when code reviews became common in Debian

On 23/01/25 15:28, Matthew Vernon wrote: Otto Kekäläinen writes: Numerous people are posting Merge Requests on Salsa. Please help review them! I'd much much rather MRs were associated with bug reports; that way I only have to remember to check one place for outstanding issues in my packages,

+1 (Re: Let's make 2025 a year when code reviews became common in Debian)

On Thu, Jan 23, 2025 at 02:28:00PM +, Matthew Vernon wrote: > I'd much much rather MRs were associated with bug reports; that way I > only have to remember to check one place for outstanding issues in my > packages, and years down the line when I wonder "why did this change get > made" I can lo

Re: Let's make 2025 a year when code reviews became common in Debian

Hi, Otto Kekäläinen writes: > Numerous people are posting Merge Requests on Salsa. Please help review them! I'd much much rather MRs were associated with bug reports; that way I only have to remember to check one place for outstanding issues in my packages, and years down the line when I wonder

Re: Let's make 2025 a year when code reviews became common in Debian

Hi Gioele, Am Wed, Jan 15, 2025 at 06:38:48PM +0100 schrieb Gioele Barabucci: > Please note that although the package has a repo on Salsa, MRs there > are/were explicitly disabled, at least for non-DDs (see the postscriptum in > [1], I see they are available now). Therefore were the commits in my

Re: Let's make 2025 a year when code reviews became common in Debian

On 15/01/25 15:19, Andreas Tille wrote: I'm not sure that these packages are on BTS only because the associated packages have no Git/salsa repo. The BTS is our prefered form of reporting issues. Adding an MR and linking to it as a patch as you did in [1] is perfect and as a maintainer (who has

Re: Let's make 2025 a year when code reviews became common in Debian

would simply assume the maintainer (in BCC) has somewhere some Git repository since this is the prefered way to maintain code these days. It would be great to have packages of "Priority: required" on Salsa to enable some team work on all our packages with high priority. This might

Re: Let's make 2025 a year when code reviews became common in Debian

Hi, Am Wed, Jan 15, 2025 at 09:01:33AM +0100 schrieb Gioele Barabucci: > Indeed, archiving the project [1], as suggested by Chris, seems a more > sensible course of action. Everything remains available, but users are given > a clear indication of the status of the repository. > > [1] > https://d

Re: Let's make 2025 a year when code reviews became common in Debian

On 14/01/25 23:14, Otto Kekäläinen wrote: Numerous people are posting Merge Requests on Salsa. Please help review them! Could we do the same for BTS patches? There are ~5000 patches that have been sitting in the BTS for years, some trivial (examples from my own: [1,2]), others less so. Most o

Re: Let's make 2025 a year when code reviews became common in Debian

On 15/01/25 08:43, Andreas Tille wrote: However, I would support the idea of bulk closing MRs and complete repositories *if* the package has been removed from Debian for the same reason we bulk close their bug reports. I tend to keep the repository for several reasons: * Users might like to

Re: Let's make 2025 a year when code reviews became common in Debian

Le 2025-01-15 00:37, Chris Hofstaedtler a écrit : Maybe a viable option for the debian namespace is to blanket close any MR that is older than 6 months. But I don't know how that will fare for the Janitor MRs. Given the "Debian time" scale, a much longer delay would be appropriate IMO. I would

Re: Let's make 2025 a year when code reviews became common in Debian

Hi, Am Tue, Jan 14, 2025 at 07:14:09PM -0800 schrieb Otto Kekäläinen: > > I gave this, specifically reviewing MRs in the debian namespace, a > > try after your last message on this topic. Unfortunately I have to > > say, it feels like a huge waste of time and is mostly frustrating. > > Thanks! Se

Re: Let's make 2025 a year when code reviews became common in Debian

Hi, Le 2025-01-14 23:14, Otto Kekäläinen a écrit : 619 (1242) https://salsa.debian.org/groups/java-team/-/merge_requests FWIW I took a look at that and most of them are Janitor merge requests. Please just skip them as some are outdated, and I'm planning to take care of them later this year

Re: Let's make 2025 a year when code reviews became common in Debian

On Tue, Jan 14, 2025 at 07:14:09PM -0800, Otto Kekäläinen wrote: > > The other big category of MRs in the debian namespace was and still > > is: MRs where the maintainers don't get mails from salsa. If one is > > active with the project, one can know who is currently around and > > assign / ping th

Re: Let's make 2025 a year when code reviews became common in Debian

> > 938 (9657) https://salsa.debian.org/groups/debian/-/merge_requests > [..] > > If you have some spare time for Debian today, please consider > > collaborating with another maintainer by providing them > > review/feedback on an open Merge Request. > > I gave this, specifically reviewing MRs in th

Re: Let's make 2025 a year when code reviews became common in Debian

* Otto Kekäläinen [250114 23:14]: > Numerous people are posting Merge Requests on Salsa. Please help review them! > > There is no single dashboard to show all Merge Requests for all Debian > packages, but here are the largest teams listed to show how many they > have open (and total count in pare

Let's make 2025 a year when code reviews became common in Debian

them might be stale for various reasons, but there are for sure many that are genuinely pending review/feedback. You don't need to be a subject-matter expert. Any feedback is surely appreciated by the author. I hope more people do code reviews as I believe it can have these benefits for D

Bug#1091644: ITP: ppx-js-style -- code style checker for Jane Street packages

/ppx_js_style * License : MIT Programming Lang: OCaml Description : code style checker for Jane Street packages Part of the Jane Street's PPX rewriters collection. . This packages is a no-op ppx rewriter. It is used as a 'lint' tool to enforce some coding conventions

Bug#1091346: ITP: ondelsolver -- Assembly Constraints and Multibody Dynamics code

/OndselSolver * License : LGPL-2.1 Programming Lang: C++ Description : Assembly Constraints and Multibody Dynamics code The OndselSolver library for assembly constraints and multibody dynamics is used by FreeCAD 1.0.0 for its new Assembly workbench. FreeCAD usually bundels ondelsolver, this

Bug#1091194: ITP: python-datamodel-code-generator -- pydantic code generator from OpenAPI and more

Package: wnpp Severity: wishlist Owner: Simon Josefsson X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-datamodel-code-generator Version : 0.26.4 Upstream Author : Koudai Aono * URL : https://github.com/koxudaxi

Bug#1090723: ITP: node-anser -- low level ANSI escape code parser

: Expat Programming Lang: JavaScript Description: low level ANSI escape code parser node-anser provides a JavaScript function that is able to parse ANSI escape sequences in text. . One can choose for it to do various combinations of: convert color escape codes into equivalent HTML

Bug#1089109: ITP: pygments-ansi-color -- ANSI color-code highlighting lexer for Pygments

: Apache 2.0 Programming Lang: Python Description : ANSI color-code highlighting lexer for Pygments pygments-ansi-color can highlight your content with Pygments' regular API. The magic is happen due using the dedicated ANSI lexer and formatter provided by the module. This module

Bug#1089037: ITP: node-ace-code -- standalone code editor written in JavaScript

Package: wnpp Severity: wishlist Owner: Philip Hands X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: node-ace-code Version : 1.35.4 Upstream Contact: Fabian Jakobs * URL : http://github.com/ajaxorg/ace * License : BSD-3-Clause Programming Lang

Bug#1088169: ITP: code-minimap -- render source code as minimap

Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@debian.org * Package name: code-minimap Version : 0.6.7 Upstream Contact: Wenxuan Zhang * URL : https://github.com/wfxr/code-minimap * License : MIT

Bug#1087471: ITP: rust-dpi -- types for handling UI scaling - rust source code

: Apache-2.0 Programming Lang: Rust Description : types for handling UI scaling - rust source code I intend to package rust-dpi, since it's needed for the next upstream version of winit. This package will be maintained within the debian rust team.

Bug#1086863: ITP: rust-swc-core -- speedy web compiler - Rust source code

* License : Apache-2.0 or Expat Programming Lang: Rust Description : speedy web compiler - Rust source code swc is a typescript / javascript transpiler. It consumes JavaScript or TypeScript files written in one version of these languages and emits javascript code which can be

Re: Private code: to forge, or not to forge?

On Wed Oct 16, 2024 at 1:18 PM -03, Iustin Pop wrote: > Hi all, this is offtopic (sorry!), but since we kept discussing Salsa - > I wonder, what are people doing for private code? ... > > What do people think? And thanks for reading. Hi Iustin, I use soft-serve and abuse Git hoo

Re: Private code: to forge, or not to forge?

On 2024-10-19 15:47:21, Thomas Hochstein wrote: > Iustin Pop wrote: > > > Gitea/Forgejo are common > > recommended solutions for "home hosting", but neither is packaged. > > Forgejo has unofficial Debian packages that work fine with bookworm, at > least. > >

Re: Private code: to forge, or not to forge?

Hi, On 20-10-2024 20:24, Iustin Pop wrote: I'm also glad to hear! Although, having read more, even the LTS version (of Forgejo) has a very short lifetime, not sure how this will play with Debian releases. Likely keeping sid up with LTS or most recent versions, and relying heavily on backports fo

Re: Private code: to forge, or not to forge?

On 2024-10-16 21:20:48, Jan-Benedict Glaw wrote: > On Wed, 2024-10-16 19:24:32 +0200, Daniel Baumann wrote: > > On 10/16/24 18:18, Iustin Pop wrote: > > > Gitea/Forgejo are common recommended solutions for "home hosting", but > > > neither is packaged. > > > > (jftr) I'm currently working with F

Re: Private code: to forge, or not to forge?

Iustin Pop wrote: > Gitea/Forgejo are common > recommended solutions for "home hosting", but neither is packaged. Forgejo has unofficial Debian packages that work fine with bookworm, at least.

Re: Bug#1085388: ITP: einops -- Flexible and powerful tensor operations for readable and reliable code.

* URL : https://einops.rocks * License : MIT/Expat   Programming Lang: Python   Description : Flexible and powerful tensor operations for readable and reliable code. Flexible and powerful tensor operations for readable and reliable code. Supports numpy, pytorch, tensorflow

Re: Bug#1085388: ITP: einops -- Flexible and powerful tensor operations for readable and reliable code.

  Programming Lang: Python >   Description : Flexible and powerful tensor operations for readable and > reliable code. > > Flexible and powerful tensor operations for readable and reliable code. > Supports numpy, pytorch, tensorflow, jax, and others. This seems to be a python mo

Bug#1085388: ITP: einops -- Flexible and powerful tensor operations for readable and reliable code.

reliable code. Flexible and powerful tensor operations for readable and reliable code. Supports numpy, pytorch, tensorflow, jax, and others. Thank you for using reportbug

  1   2   3   4   5   6   7   8   9   10   >