Re: Simpler git workflow for packaging with upstreamless repositories
Hi! > With all the recent talk about increasing the use of git for > packaging, I'd like to address one thing: git-buildpackage is very > complex to use. As an alternative, I'd like to propose a simpler > setup: .. > sick of it and I can tell you it only makes me want to ignore you. If > you ask me it's git-buildpackage's irreducible difficulty of use > that's the largest road block to increase the use of git for > packaging. I think git-buildpackage is great, and I am a happy user. It did however take me quite a while to figure out what is the best practice to use it, as it has so many options. I see you are also using it at https://salsa.debian.org/science-team/chuffed so you seem to have learned to use it. Can you elaborate, is there a specific thing you think git-buildpackage falls short on? Instead of trying to write a new tool from scratch, I hope more people would offer help to Guido to maintain and polish git-buildpackage and docs. I am for example proposing doc improvements in https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/6 and I tried make git-buildpackage use DEP-14 branches (debian/latest and upstream/latest) by default in https://salsa.debian.org/agx/git-buildpackage/-/merge_requests/1, although I ran out of steam with this latter one as it turned out to be quite complex. I was also planning to suggest updates the the Developers Reference on how to use git-buildpackage in the context of daily package maintenance tasks so people would more easily discover them (draft at https://salsa.debian.org/debian/developers-reference/-/merge_requests/63). To make it easier for contributors I publish in my packages debian/gbp.conf, so the settings are automatically correct, and also README.source(.md) so contributors can discover the correct gbp comands easily. See examples at https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/gbp.conf and https://salsa.debian.org/debian/entr/-/blob/debian/latest/debian/README.source.md. I am contemplating if I should also make videos on Debian packaging best practices, or have start a new Matrix channel specifically to help maintainers setup their git repositories correctly and find the optimal git-buildpackage commands for each thing they want to do.
Re: [Artwork] Survey for the default artwork for Trixie (Debian 13)
Hello El 18/11/24 a las 19:31, Jan Wedekind escribió: Is this a restricted survey? The survey website asks for a token. Kind regards Jan It should be fixed now. Kind regards, -- Laura Arjona Reina https://wiki.debian.org/LauraArjona
Re: [Artwork] Survey for the default artwork for Trixie (Debian 13)
Hi! On Mon, 18 Nov 2024 20:09:28 +0200 Jonathan carter wrote: > To vote for your favourite theme, visit the following website and > click on the "Trixie Artwork Survey" button. From there, you can rank > your choices from the available options to the My Choices section > from most preferred to least preferred. > > https://surveys.debian.net/ > > The survey is now open and closes on 2024-11-30 23:59 UTC. If you attempted to answer earlier, you will have received an access token question. This has now been fixed (thanks to the survey site administrator!) Apologies for the inconvenience and additional noise. -Jonathan pgpvCKZc8qmc_.pgp Description: OpenPGP digital signature
Bug#1087802: ITP: f1db -- Open-source Formula 1 racing database
Package: WNPP Severity: wishlist Owner: Anna Mathew X-Debbugs-CC: debian-devel@lists.debian.org * Package name: f1db Version : v2024.21.0 Upstream Author : F1DB contributors * URL : https://github.com/f1db/f1db * License : CC-BY-4.0 Description : Open-source Formula 1 racing database F1DB is an open-source project offering a comprehensive database of Formula 1 racing data and statistics. This database provides essential information for developers, researchers, and enthusiasts, enabling analysis and integration into custom applications. The project aims to promote transparency and accessibility of Formula 1 data through open-source contributions. This package is intended for the main Debian repository, and its inclusion will benefit a wide range of users interested in motorsport data analysis. The software is not currently packaged in Debian, and I plan to follow Debian's packaging guidelines to ensure its quality and usability. I will create and maintain the package, ensuring regular updates and compliance with Debian standards. Thank you for considering my Intent to Package. Sincerely, Anna Mathew
Re: DEP-18 v2: request for comments
On Mon, Nov 18, 2024 at 01:22:31PM +0100, Fabio Fantoni wrote: > Thanks to Salsa Admins, recently when I used salsa it went much better. > > While unfortunately I still had many cases where packages.debian.org did not > load the pages or took a long time, several cases still for wiki.debian.org > too (even if maybe less), am I the only one who notices or maybe the other > DD/DMs do not use them or use them very little? Not sure how is this related but packages.debian.org is, or should, indeed be used by maintainers only rarely. -- WBR, wRAR signature.asc Description: PGP signature
Re: Simpler git workflow for packaging with upstreamless repositories
On Mon, Nov 18, 2024 at 08:16:59PM +0200, Kari Pahula wrote: > > However... different people are used to different workflows. > > I personally really, really like the fact that I have the Git history of > > all the upstream files in the same repo and I don't have to go over to > > a different repo to figure out what changed when. Also, I like that > > immediately after `gbp import-orig` I can run `git show upstream` to > > review the diff (TBH, me being very pedantic, I usually have already > > given it a quick glance using `diff -urN` on unpacked tarballs before > > even importing it, if only to figure out if there are new files that > > I need to exclude, but that's not always the case), and that I can > > at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path` > > or similar commands. I have even been known to use `git bisect` in > > a Debian package directory in some weird cases. > > > > And yes, all of that can be handled in a separate Git repo with > > a clean checkout of the upstream repository without any of > > the Debian fluff; however, that would require me switching between > > terminals/tmux panes/whatever, and sometimes that seems like too much > > work when I can have it all in a single repository :) > > Preface, just in case: I list a few git commands, don't try running > them if you have uncommitted changes. > > Okay, I could amend what I proposed originally with this option: Do > the debian work in a fork of upstream's repository, but never merge > the debian branch and upstream branch. That is, the start of Debian > maintenance would be by cloning upstream and then with "git checkout > --orphan debian" followed by "git reset --hard". > > Do you think you could do all of the above with that model, with a > command like "git checkout debian -- ." to insert the debian contents > to an upstream branch? > > I'm thinking that it's the merging of debian and upstream branches and > maintaining it that really causes the warts in gbp and I'm not at all > sure if there are any actual workflows that require having that. > "upstreamless" as I described it may be a bit too much for general use > but could there be a case for doing everything with a mergeless model > instead? > > Furthermore, I think import-orig should really be only about > establishing a particular byte string as the orig.tar. Think of > object storage. If there's a connection to a particular commit hash > or release tag in the repository it would better be represented as a > separate entry. Perhaps as a text file like debian/upstream-commits > that would be a list of upstream version/commit hash or tag pairs. > From where I stand, the way these disparate concerns have been merged > seems to be one root cause for all sorts of unintended consequences. You are talking about the upstream git history while Peter is talking about simply importing orig tarballs. Maybe what is causing warts in gbp *for you* is some *specific* gbp workflow, one of the many it supports? -- WBR, wRAR signature.asc Description: PGP signature
Simpler git workflow for packaging with upstreamless repositories
With all the recent talk about increasing the use of git for packaging, I'd like to address one thing: git-buildpackage is very complex to use. As an alternative, I'd like to propose a simpler setup: - Only store debian/ in the repository and use origtargz for the rest. - One branch per distribution you target. - Only tag debian revisions. That's it, less is more. The master branch would be just a single debian directory. What it specifically wouldn't have is an upstream branch and no extracted upstream sources in any permanent branch. The workflow on a new upstream version would be: 1. debchange (or equivalent) to bump debian/changelog. 2. Download orig.tar with origtargz. 3. Use pristine-lfs commit on the orig.tar. pristine-tar wouldn't work with this setup since there wouldn't be an upstream branch anymore. It wouldn't be too hard to have tooling to do the three steps on one go. Step one could also include a commit. gbp dch would still be useful with this workflow. gbp pq could be made to work with this if you extracted orig.tar and committed it to a temporary local working branch and used it against it. I'm not sure if there's much else in gbp that'd be applicable anymore if you do away with having an upstream branch. This workflow is basically what the Haskell team is using [1] except they don't commit orig.tar files to lfs but rely on having them available from Hackage (Haskell's central community package hub). I guess interfacing with upstream's git with gbp has its uses but it just seems to me that the capability comes with a hefty cost. If you can maintain a package with having orig.tar files be your interface to upstream's releases then it simplifies things on our side a whole lot. I've been a DD longer than git-buildpackage has been around and I've been looking at using it at various times but pretty much every time my reaction's been "must I?" I know a lot of people do use gbp daily for work with good effect but somehow I suspect even they had quite a steep learning curve to get into it. I wouldn't fancy the idea of trying to explain how to use it to someone on d-mentors. I must say that I haven't been that impressed with the DEP-18 discussion I've seen. It seems like the message has pretty consistently been "if you don't use git you're the problem" and I'm sick of it and I can tell you it only makes me want to ignore you. If you ask me it's git-buildpackage's irreducible difficulty of use that's the largest road block to increase the use of git for packaging. If gbp works for your team then good for you but you'll have to excuse me if I'm not that enthusiastic about sending patches to your way. I expect it's going to be contentious to come to the list to essentially say that a widely used tool that was first released 18 years ago sucks. [1]: https://wiki.debian.org/Teams/DebianHaskellGroup/CollabMaint/GettingStarted#How_To_Update_the_Debianization_of_a_Package_Already_Under_DHG_Control signature.asc Description: PGP signature
Re: [Artwork] Survey for the default artwork for Trixie (Debian 13)
Is this a restricted survey? The survey website asks for a token. Kind regards Jan
Bug#1087768: ITP: python-renardo-lib -- python-based language and editor for making music (lib)
Package: wnpp Severity: wishlist Owner: Joenio Marques da Costa X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: python-renardo-lib Version : 0.9.12 Upstream Author : Elie Gavoty * URL : https://renardo.org * License : CC-BY-SA-4.0 Programming Lang: Python 3 Description : python-based language and editor for making music (lib) Renardo is a Python programming environment that provides a fast and user-friendly abstraction to SuperCollider. It also comes with its own IDE, which means it can be used straight out of the box. Renardo is a modernized FoxDot fork. -- Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.
Bug#1087773: ITP: sideretro -- pipeline for detecting Somatic Insertion of DEnovo RETROcopies
Package: wnpp Severity: wishlist Owner: Daniela Moreira Mombach X-Debbugs-Cc: debian-devel@lists.debian.org, danielamomb...@gmail.com * Package name: sideretro Version : 1.1.4 Upstream Contact: Thiago L. A. Miller * URL : https://github.com/galantelab/sideRETRO * License : GPL-3+ Programming Lang: C Description : pipeline for detecting Somatic Insertion of DEnovo RETROcopies sideRETRO is a bioinformatics tool designed for the detection of somatic retrocopy insertions, also known as retroCNVs, in whole genome sequencing (WGS) and whole exome sequencing (WES) data. . Retrocopies, also known as processed pseudogenes, are sequences derived from protein-coding genes, generated by the duplication of these genes through the transposition of their mature messenger RNA via the LINE-1 enzymatic machinery. Retrocopies can be fixed, meaning they are present in all genomes of a given species (including the species' reference genome), or unfixed (polymorphic, germline, or somatic), in which case they are referred to as retroCNVs. While fixed retrocopies have received considerable attention in the scientific community, knowledge of retroCNVs remains limited, largely due to the lack of specialized bioinformatics tools for their identification and annotation in DNA sequencing data. . sideRETRO is a dedicated computational algorithm that detects retrocopies absent from the reference genome but present in WGS and WES data from other individuals. In addition to identifying retroCNVs, sideRETRO annotates several characteristics associated with these events. It provides information on the genomic coordinates of the insertion, including chromosome, insertion point, and DNA strand. It also determines the genomic context of the event (exonic, intronic, or intergenic), performs genotyping (presence or absence), and provides haplotyping information (homozygous or heterozygous).
Bug#1087797: ITP: librespeed-server-rs -- rust server for librespeed
Package: wnpp Severity: wishlist Owner: Matthias Geiger X-Debbugs-Cc: debian-devel@lists.debian.org, werdah...@debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 * Package name: librespeed-server-rs Version : 1.3.6 Upstream Contact: Sudo Dios * URL : https://github.com/librespeed/speedtest-rust * License : LGPL-3+ Programming Lang: Rust Description : rust server for librespeed librespeed-server-rs is a rust server (backend) for librespeed. It only consists of the main binary plus some assets (html + a few lines of JS). It features testing of download, upload, ping, jitter and displaying the IP Address and ISP. Optionally telemetry and results sharing can be enabled. I think this is a nice addition to Debian for users that are privacy-concious but still want to mesure their internet speed. best, werdahias -BEGIN PGP SIGNATURE- iIsEARYIADMWIQQUWTv/Sl6/b+DpcW7svtu2B7myvgUCZzuKwhUcd2VyZGFoaWFz QGRlYmlhbi5vcmcACgkQ7L7btge5sr7JcwD8Cn5QodXZq0n6WCoINmcXVl/ten5X OFbNP6fT1H6Pyv8A/1+zyEqHz23dam3yvasTKeObNHBYRAhyjUi+W/PlfkgN =LNlA -END PGP SIGNATURE-
Re: DEP-18 v2: request for comments
Il 18/11/2024 01:04, Otto Kekäläinen ha scritto: Hi all, I published a complete rewrite of the earlier draft as: https://salsa.debian.org/dep-team/deps/-/merge_requests/12 DEP-18: Encourage Continuous Integration and Merge Request based Collaboration for Debian packages If you are in favor of having this as a DRAFT in the DEP directory, please give it a thumbs up. Summary of previous discussion below, but an even better summary was written by LWN in https://lwn.net/Articles/986480/ Related to Salsa in general, I heard we have now new and faster hardware (thanks Salsa Admins!), and related to Salsa CI there is also an overhauled README (https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md) and lots of fixes by 7 different authors. I think a lot of people have also practiced more code reviews and tested the Merge Request feature on Salsa than before. Overall, I think we are on a good path to evolving this way of working, and hopefully doing it in a way that it does not stifle work for maintainers who prefer to continue their single-maintainer habits, so nobody feels at loss. Thanks to Salsa Admins, recently when I used salsa it went much better. While unfortunately I still had many cases where packages.debian.org did not load the pages or took a long time, several cases still for wiki.debian.org too (even if maybe less), am I the only one who notices or maybe the other DD/DMs do not use them or use them very little? Thanks for including to recommend the use of README.source(.md), so if it will be used more I think it will be easier and faster to understand how to contribute to a given package whatever method or tool is used. OpenPGP_signature.asc Description: OpenPGP digital signature
[Artwork] Survey for the default artwork for Trixie (Debian 13)
Hello Debianites o/ While we don't yet have official freeze dates yet, I can assure you that it is coming! And with that, it's that time of the development cycle to choose the desktop artwork to be used in the next Debian release. All the fine submissions can be perused at: https://wiki.debian.org/DebianDesktop/Artwork/Trixie Thank you to everyone who have put work into these! To vote for your favourite theme, visit the following website and click on the "Trixie Artwork Survey" button. From there, you can rank your choices from the available options to the My Choices section from most preferred to least preferred. https://surveys.debian.net/ The survey is now open and closes on 2024-11-30 23:59 UTC. Please be nice and vote only once. If you require assistance, you can find the desktop team on #debian-desktop on the oftc IRC network. -Jonathan pgp0eeyeI8iqM.pgp Description: OpenPGP digital signature
Re: Simpler git workflow for packaging with upstreamless repositories
On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote: > With all the recent talk about increasing the use of git for > packaging, I'd like to address one thing: git-buildpackage is very > complex to use. As an alternative, I'd like to propose a simpler > setup: We want fewer allowed setups, not more. Though it's clear to me at this point that if this become more than a dream, we will need to allow more than one. > - Only store debian/ in the repository and use origtargz for the rest. > > - One branch per distribution you target. > > - Only tag debian revisions. --git-overlay probably supports this, but it's not really documented so I don't really know. > That's it, less is more. The master branch would be just a single > debian directory. What it specifically wouldn't have is an upstream > branch and no extracted upstream sources in any permanent branch. Many people want to have version-tracked upstream sources so this can't be the only allowed workflow. > gbp dch would still be useful with this workflow. gbp pq could be > made to work with this if you extracted orig.tar and committed it to a > temporary local working branch and used it against it. "How do I create and update patches" is actually a big part of a good workflow, and this way doesn't sound easy. Though of course there is no way to have 3.0 (quilt), git and easy patch workflows at the same time. > I guess interfacing with upstream's git with gbp has its uses but it > just seems to me that the capability comes with a hefty cost. If you > can maintain a package with having orig.tar files be your interface to > upstream's releases then it simplifies things on our side a whole lot. It's not necessarily interfacing with upstream's git, just version-tracking tarballs is already very useful. Maybe more useful than the upstream git in certain use cases. > I've been a DD longer than git-buildpackage has been around and I've > been looking at using it at various times but pretty much every time > my reaction's been "must I?" I know a lot of people do use gbp daily > for work with good effect but somehow I suspect even they had quite a > steep learning curve to get into it. I wouldn't fancy the idea of > trying to explain how to use it to someone on d-mentors. I have many interconnected thoughts about this: 1. git-buildpackage is complicated because it supports many different workflows, some of which don't have anything in common. This simply represents a bigger problem in Debian and is not specific to git-buildpackage. 2. git-buildpackage is bad. This is unavoidable, because any tool that tries to wrap the inherently incompatible Debian packages workflow into a VCS will be bad in some way. So we don't and, unavoidably, can't have a better tool and must work with what we have. 3. git-buildpackage has a steep learning curve, but I don't expect it to be that steep for people who are already proficient both with Debian packaging and with git. Which new users aren't, at least because of the former, but it's far from the only thing with a steel learning curve and not enough docs they will hit their heads against. 4. git itself has a steep learning curve, bad UI, bad docs etc. etc., but we clearly don't have a better VCS to store packages in, and we really need to do that. And, at least, git knowledge is both useful outside Debian and possible to already have before becoming a Debian package, unlike almost everything else you need to know in Debian packaging. 5. *Debian packaging itself* is notoriously hard to learn, and as long as it stays as hard as it is now not a lot of things on top of it could make the overall experience harder and some of them may make it *easier* for many people. 6. Whatever workflow one needs to learn, even if it's just a single one, will be hard for a newbie in a large part because of the disconnect between the VCS concept and the "source package as a first class citizen" concept, even before we talk about patches, uscan and upstreams without tarballs. Long story short, I don't envy our newbie contributors and I don't think it will be easier for them in my lifetime. > I must say that I haven't been that impressed with the DEP-18 > discussion I've seen. It seems like the message has pretty > consistently been "if you don't use git you're the problem" and I'm > sick of it and I can tell you it only makes me want to ignore you. I'm afraid I don't see a peaceful way forward for the project. Most likely we will continue stagnating and losing people but in a less probably scenario with big changes many people will resign. > If you ask me it's git-buildpackage's irreducible difficulty of use > that's the largest road block to increase the use of git for packaging. :-/ -- WBR, wRAR signature.asc Description: PGP signature
Re: Simpler git workflow for packaging with upstreamless repositories
On Mon, Nov 18, 2024 at 06:19:58PM +0200, Peter Pentchev wrote: > However... different people are used to different workflows. > I personally really, really like the fact that I have the Git history of > all the upstream files in the same repo and I don't have to go over to > a different repo to figure out what changed when. Also, I like that > immediately after `gbp import-orig` I can run `git show upstream` to > review the diff (TBH, me being very pedantic, I usually have already > given it a quick glance using `diff -urN` on unpacked tarballs before > even importing it, if only to figure out if there are new files that > I need to exclude, but that's not always the case), and that I can > at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path` > or similar commands. I have even been known to use `git bisect` in > a Debian package directory in some weird cases. > > And yes, all of that can be handled in a separate Git repo with > a clean checkout of the upstream repository without any of > the Debian fluff; however, that would require me switching between > terminals/tmux panes/whatever, and sometimes that seems like too much > work when I can have it all in a single repository :) Preface, just in case: I list a few git commands, don't try running them if you have uncommitted changes. Okay, I could amend what I proposed originally with this option: Do the debian work in a fork of upstream's repository, but never merge the debian branch and upstream branch. That is, the start of Debian maintenance would be by cloning upstream and then with "git checkout --orphan debian" followed by "git reset --hard". Do you think you could do all of the above with that model, with a command like "git checkout debian -- ." to insert the debian contents to an upstream branch? I'm thinking that it's the merging of debian and upstream branches and maintaining it that really causes the warts in gbp and I'm not at all sure if there are any actual workflows that require having that. "upstreamless" as I described it may be a bit too much for general use but could there be a case for doing everything with a mergeless model instead? Furthermore, I think import-orig should really be only about establishing a particular byte string as the orig.tar. Think of object storage. If there's a connection to a particular commit hash or release tag in the repository it would better be represented as a separate entry. Perhaps as a text file like debian/upstream-commits that would be a list of upstream version/commit hash or tag pairs. From where I stand, the way these disparate concerns have been merged seems to be one root cause for all sorts of unintended consequences. > So... yes, a simpler setup would work for some people, and it may be > better for beginners. However, there are some benefits to a full > repository containing both the upstream source and the Debian changes, > and some people like to use them every now and then. I don't agree with framing this as a beginner/expert issue. > Still, thanks for your desire to make working on Debian easier and > better! You don't really sound willing to discuss anything with that but I'm still going to try. signature.asc Description: PGP signature
Re: Simpler git workflow for packaging with upstreamless repositories
On Mon, Nov 18, 2024 at 05:40:55PM +0200, Kari Pahula wrote: > With all the recent talk about increasing the use of git for > packaging, I'd like to address one thing: git-buildpackage is very > complex to use. As an alternative, I'd like to propose a simpler > setup: > > - Only store debian/ in the repository and use origtargz for the rest. > > - One branch per distribution you target. > > - Only tag debian revisions. > > That's it, less is more. The master branch would be just a single > debian directory. What it specifically wouldn't have is an upstream > branch and no extracted upstream sources in any permanent branch. Let me start by saying that I understand where you're coming from; any tool that allows different use scenarios will almost inevitably grow more and more complex with time, and become more and more difficult to use by beginners, unless there are good tutorials and step-by-step recipes for the most common cases. TBH, I think that the git-buildpackage manual is relatively easy to read and understand, but, of course, that opinion of mine is tainted by the fact that I cannot exactly be called a beginner :) (although there are new things I learn about Debian packaging every month) However... different people are used to different workflows. I personally really, really like the fact that I have the Git history of all the upstream files in the same repo and I don't have to go over to a different repo to figure out what changed when. Also, I like that immediately after `gbp import-orig` I can run `git show upstream` to review the diff (TBH, me being very pedantic, I usually have already given it a quick glance using `diff -urN` on unpacked tarballs before even importing it, if only to figure out if there are new files that I need to exclude, but that's not always the case), and that I can at any time later run `git diff upstream/2.17.18..upstream/3.14.15 path` or similar commands. I have even been known to use `git bisect` in a Debian package directory in some weird cases. And yes, all of that can be handled in a separate Git repo with a clean checkout of the upstream repository without any of the Debian fluff; however, that would require me switching between terminals/tmux panes/whatever, and sometimes that seems like too much work when I can have it all in a single repository :) So... yes, a simpler setup would work for some people, and it may be better for beginners. However, there are some benefits to a full repository containing both the upstream source and the Debian changes, and some people like to use them every now and then. Still, thanks for your desire to make working on Debian easier and better! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: DEP-0, DEP0 or DEP 0?
On Sunday, November 17, 2024 11:50:27 PM MST Mathias Behrle wrote: > * Otto Kekäläinen: " Re: DEP-0, DEP0 or DEP 0?" (Sun, 17 Nov 2024 15:23:50 > -0800): > > Hi Otto, > > > Let's implement this. Please vote on which variant you prefer by > > giving a thumbs up at > > > > https://salsa.debian.org/dep-team/deps/-/merge_requests/13 > > Unify DEP spelling with a dash instead of a space (e.g. "DEP-0") > > > > OR > > > > https://salsa.debian.org/dep-team/deps/-/merge_requests/14 > > Unify DEP spelling with a space instead of dash (e.g. "DEP 0") > > > > I apologize that this requires JavaScript to those who are concerned. > > I don't know how to +1 in the GitLab API from the command line, so I > > can't offer that as an option now, but I can provide direct links to > > raw diff so you can at least read these without having to run > > JavaScript: > > https://salsa.debian.org/dep-team/deps/-/merge_requests/13.patch > > https://salsa.debian.org/dep-team/deps/-/merge_requests/14.patch > > I know that you are working a lot on Salsa CI and that you like and promote > the platform. Not all in the project are at ease with gitlab. So please avoid > to change communication channels and put pressure on people to use that > platform for voting purposes that have a meaning to the project. Thanks! > > I vote for DEP-0. I actually think that using two merge requests like this with the thumbs-up options is a really good way to get group feedback without the need for a large number of emails. For simple decisions like this, I would hope we do more of it. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Simpler git workflow for packaging with upstreamless repositories
Kari, On Monday, November 18, 2024 8:40:55 AM MST Kari Pahula wrote: > I've been a DD longer than git-buildpackage has been around and I've > been looking at using it at various times but pretty much every time > my reaction's been "must I?" I know a lot of people do use gbp daily > for work with good effect but somehow I suspect even they had quite a > steep learning curve to get into it. I wouldn't fancy the idea of > trying to explain how to use it to someone on d-mentors. I don’t want to necessarily disagree with anything you have said, but if you want an example of me explaining how to use gbp on Debian Mentors you can take a look at: https://lists.debian.org/debian-mentors/2024/09/msg00057.html And yes, it is a steep learning curve. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
