Need help with ITP bug#1107258 needing to vendor source code

X-Debbugs-Cc: rust-deb...@lists.debian.org Hi, i am the the author of https://bugs.debian.org/1107258 When trying to package the project, i noticed the project has to vendor a dedicated dependency (magpie) which has to vendor nvtop v3.2.0 and apply application specifc patches to try to make an

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 22/05/25 18:10, Matthias Geiger wrote: On Thu, 22 May 2025 17:41, Joerg Jaspert wrote: On 17602 March 1977, Matthias Geiger wrote: While it is not that mature yet and some features are still being worked on, I think it already suitable to host small, non-key packages. I would like a swit

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 5/22/25 22:47, Joerg Jaspert wrote: Honestly, the packaging is the least important thing. the point I was trying to make is that the implied argument/momentum of "let's switch from gitlab to forgejo because forgejo is in Debian and gitlab is not" is all hypothetical at this point. if the

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 17602 March 1977, Daniel Baumann wrote: I *currently* think its not time well spent. Time from a *lot* of people, not just Salsa admins. * there's no forgejo in the archive yet - the packaging needs to be finished and a bunch of golang-* packages are in NEW. this will take a whi

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 17602 March 1977, Matthias Geiger wrote: I would like a switch, but i think its currently not realistic. Thanks for the vote of confidence; I concur that this might be a nice goal in the long run. I use forgejo for my own things. I like it. (Its 6 or 7 repos...). While it is not impossibl

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On Thu, 2025-05-22 at 18:10 +0200, Matthias Geiger wrote: > Nice to have the raw numbers; > 16k users is indeed a lot. > The most recent number I could find for codeberg was 11k users and > 12k repos. FWIW: based on the "Explore" pages there seem to be ~161k repositories, ~157k users and ~11k orga

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On Thu, 22 May 2025 18:10:54 +0200, Matthias Geiger wrote: >Nice to have the raw numbers; > 16k users is indeed a lot. >The most recent number I could find for codeberg was 11k users and 12k >repos. Salsa happens to be one of the largest gitlab instances that exist. Greetings Marc --

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On Thu, 22 May 2025 17:41, Joerg Jaspert wrote: On 17602 March 1977, Matthias Geiger wrote: While it is not that mature yet and some features are still being worked on, I think it already suitable to host small, non-key packages. I would like a switch, but i think its currently not realisti

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 5/22/25 17:41, Joerg Jaspert wrote: I *currently* think its not time well spent. Time from a *lot* of people, not just Salsa admins. yes, *this*. apart from what I already wrote [0][1], please try to not follow up on this topic for now: * there's no forgejo in the archive yet - the pa

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On Thu, 22 May 2025 14:36, Marco d'Itri wrote: On May 22, Matthias Geiger wrote: I think at the very least it's worth exploring its use parallel to salsa, so we aren't negatively surprised one day. Good idea: I propose that once a year you report to debian-project@ a comparison of the featur

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On 17602 March 1977, Matthias Geiger wrote: While it is not that mature yet and some features are still being worked on, I think it already suitable to host small, non-key packages. I would like a switch, but i think its currently not realistic. On the techical side of things: To give peo

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On Thu, May 22, 2025 at 02:30:13PM +0100, Jonathan Dowland wrote: The formatting of this was mangled so I couldn't figure out which parts of the mail were quotes and which weren't. It's, again, related to format=flowed. -- WBR, wRAR signature.asc Description: PGP signature

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

The formatting of this was mangled so I couldn't figure out which parts of the mail were quotes and which weren't. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net

Re: Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

On May 22, Matthias Geiger wrote: I think at the very least it's worth exploring its use parallel to salsa, so we aren't negatively surprised one day. Good idea: I propose that once a year you report to debian-project@ a comparison of the features available in Gitlab and forgejo. -- ciao, Ma

Exploring forgejo as alternative to salsa ? (Was Re: Private code: to forge, or not to forge?)

dogfooding) [0], which IMO attributes to their dedication to actively test things. The source code is also completly open, which can't be said for Github and enterprise Gitlab. While it is not that mature yet and some features are still being worked on, I think it already suitable to

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

On 5/21/25 22:18, Thomas Hochstein wrote: Probably Otto thought you would be going to provide as an alternative to salsa. oh, I see. no - I absolutely don't want to do anything like that at all. I do want to provide forgejo packages in Debian so it's available and

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

Daniel Baumann wrote: > On 5/21/25 03:23, Otto Kekäläinen wrote: >> costs from fragmentation. > > I'm not sure I understand what you mean with "fragmentation" in this > context. Would you mind explaining? Probably Otto thought you woould be going to provide as an a

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

Hi Otto, On 5/21/25 03:23, Otto Kekäläinen wrote: It would be nice to read a writeup of what you plan is, and how the Go team or other DDs in general are expected to relate to this. I'm packaging forgejo (currently ~21 golang packages are waiting in NEW, another ~10 soon to be finished) to be

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

On Wed, 16 Oct 2024 at 10:42, 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 Forgejo upstream to get one last > feature implemented that we'll

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

  1   2   3   4   5   6   7   8   9   10   >