Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sun Sep 1, 2024 at 6:14 PM BST, Otto Kekäläinen wrote: > The discussion was summarized in a separate "Summay" email by me on this > list, and a comment in the MR (which merges the two discussions) and it > just happened that the next day it was also covered in > https://lwn.net/Articles/986480/ > > I am currently writing revision 2 of the proposal. I will notify when > published. Thanks. I look forward to it. It would be great if this was iterative on top of your first, in distinct commits, such that you/we/someone can mark conversation threads on GitLab as "resolved" (if they are by your second draft). Best, -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: LPC: Support for Complex Cameras in Debian
Hi Ricardo, Am Tue, Sep 03, 2024 at 10:37:27PM +0200 schrieb Ricardo Ribalda Delgado: > ... > As a newer DD, I don't feel comfortable speaking on behalf of the > project just yet. I'm hoping someone from debian-dev or > debian-multimedia might be interested in participating, either in > person or virtually.s If you are a "newer DD" but with competence on the actual topic I wonder what some "older DD" who has no idea about the topic can do better than you? > Alternatively, if someone could spare 30-60 > minutes to discuss Debian's best approach with me before the event, > that would be immensely helpful. What actual question do you want to discuss? Kind regards Andreas. -- https://fam-tille.de
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi! On Wed, Sep 4, 2024 at 12:39 PM PICCA Frederic-Emmanuel wrote: > > Hello, > > > Well, I didn't mean we should *give up* decentralization. I mean we > > shouldn't > > give up *centralization*. These examples are to prove centralization > > actually > > works and is quite common, sometimes necessary. > > It would be great if we could run the salsa-ci pipeline localy easily, in > chroot via sbuild or whatever. > Do not get me wrong I like the fact that we have these pipelines in salsa, it > is a great plus for Debian. > > I Just see that the salsa-ci pipelines does not gives somethimes exacly the > same result than my current sbuild + autopkgtest run locally. > So I need to iterate also on salsa-ci to fix my autopkgtests. > > It would be great if the "quality-pipeline" could be decouple from salsa and > could be run locally / salsa / what ever other infra. I am working on achieving this decoupling to enable it to run on environments other than salsa including locally. The ability to run salsaci locally should be ready by the end of this month. Issue where we discuss this goal: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/230 Let me know if you have any feedback in this regard. Best regards, Ahmed Siam
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On 04/09/2024 17:21, PICCA Frederic-Emmanuel wrote: > Hello, > >> Well, I didn't mean we should *give up* decentralization. I mean we shouldn't >> give up *centralization*. These examples are to prove centralization actually >> works and is quite common, sometimes necessary. > > It would be great if we could run the salsa-ci pipeline localy easily, in > chroot via sbuild or whatever. > Do not get me wrong I like the fact that we have these pipelines in salsa, it > is a great plus for Debian. > > I Just see that the salsa-ci pipelines does not gives somethimes exacly the > same result than my current sbuild + autopkgtest run locally. > So I need to iterate also on salsa-ci to fix my autopkgtests. > > It would be great if the "quality-pipeline" could be decouple from salsa and > could be run locally / salsa / what ever other infra. > > We have plenty of quality tools, but it is not easy to run them all in a row > during the package preparation. Indeed, thus I wished earlier about delegating salsa CI to debci. Arguably, the reason code forges have such complex, cryptic CI configurations with irreproducible behaviors is the wild number of ways people want to run CI in. But we in Debian already have the One True Way: sbuild and autopkgtest! -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, > Well, I didn't mean we should *give up* decentralization. I mean we shouldn't > give up *centralization*. These examples are to prove centralization actually > works and is quite common, sometimes necessary. It would be great if we could run the salsa-ci pipeline localy easily, in chroot via sbuild or whatever. Do not get me wrong I like the fact that we have these pipelines in salsa, it is a great plus for Debian. I Just see that the salsa-ci pipelines does not gives somethimes exacly the same result than my current sbuild + autopkgtest run locally. So I need to iterate also on salsa-ci to fix my autopkgtests. It would be great if the "quality-pipeline" could be decouple from salsa and could be run locally / salsa / what ever other infra. We have plenty of quality tools, but it is not easy to run them all in a row during the package preparation. > Besides, *you* are the centralization point when you are the only maintainer. > With a centralized code hosting, you exchange being SPOF with redundancy and > team work :p most of my packages are team maintain and I agreed that this central git repository is valuable when it comes to team works. Fred
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
(Please send To/Cc me if you'd like to continue on this branch of conversation, I'm not subscribed to -devel, only digests.) On Wed, 04 Sep 2024 06:42:33 +0200, Jonas Smegegaard wrote: > Quoting Blair Noctis (2024-09-04 04:33:10) (...) >> > PICCA Frederic-Emmanuel writes: >> > >> >> What about dog fooding ? >> >> >> >> for now we can setup a schroot and sbuild very easily and start to build a >> >> local repository in minutes. >> >> >> >> But when it comes to install gitlab and the CI system it is another story. >> >> So we rely on the central salsa instance. (...) >> >> I do not know if I am clear but I have the fear that this >> >> centralisation will make us forget that de-centralisation is sort of >> >> "central" to the Debian way. (...) >> > I suspect that if the DEP was clearer in scope and aims, these concerns >> > would not actually arise >> >> Debian infrastructure is "centralized" in many ways. The power to decide >> which packages go in the archive and which do not is "centralized" in the FTP >> team, and you must upload to a "centralized" machine for them to review. >> buildds build the public facing packages, debci runs migration reference >> tests, they are all "centralized" on a few hosts and in a few people. >> Packages are distributed from a single source (mirrors don't have the say of >> the content). Even the very list you are posting to is hosted on a >> centralized machine. How would storing packaging sources on a centralized >> code hosting instance be different than package distribution? How would a >> centralized CI be different than buildds and debci? >> >> The more important decentralization is in the decision process. Not >> everything is fit for decentralization; don't push it only for the sake of >> it. >> >> GitLab isn't perfect, sure, but it's an implementation detail of having a >> centralized code hosting and CI. I'd personally expect the CI to be basically >> the same as debci (maybe even merge the two or make salsa delegate CI to >> debci), but that's another topic. > > Yes, some parts of Debian are centralized, but it seems you turn those into > reasons for giving up on the flexibility of others which are not. Well, I didn't mean we should *give up* decentralization. I mean we shouldn't give up *centralization*. These examples are to prove centralization actually works and is quite common, sometimes necessary. > I have worked in areas with weak internet connection (near the Amazonas > jungle in Peru, and at the country side of Sweden) where I could have a > full mirror of Debian and an archive of email conversations, and from > that not only release package updates but also work on developing Debian > Pure Blends (i.e. "forks" of Debian containing purely Debian parts), > with only occational need to syncronize my data with Debian. > > I don't say that Debian must work for jungle developers, nor that we > must all use email and not different forms of collaboration requiring > better connectivity. My point is that Debian *allows* collaboration > also without heavy realtime connectivity that most of us take for > granted in our working environments, and I fail to see why the few > points that are centralized is a reason for giving up on all the others > as well. And I did not push "realtime connectivity" either. All I'm saying is that centralization isn't inherently bad, it's a characteristic with benefits and tradeoffs. It's also not inherently synchronous, just means a single source of truth. Well, some aspects are, but not all. That said, your example, package releases, *is* synchronous. It's totally fine to work on one aspect while your coworkers work on another, only exchanging progress now and then, but I imagine it'd be a mess if you each decide to release on one's own. The release point inevitably requires all work to be synchronized to a single source of truth, from where a canonical release is produced. It's of course not necessary if you are a lone wolf, but we are trying to avoid that. Besides, *you* are the centralization point when you are the only maintainer. With a centralized code hosting, you exchange being SPOF with redundancy and team work :p -- Sdrager, Blair Noctis OpenPGP_0xC21D9AD423A39727.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Tuesday, 3 September 2024 23.42.33 CDT Jonas Smedegaard wrote: > I don't say that Debian must work for jungle developers, nor that we > must all use email and not different forms of collaboration requiring > better connectivity. My point is that Debian *allows* collaboration > also without heavy realtime connectivity that most of us take for > granted in our working environments, and I fail to see why the few > points that are centralized is a reason for giving up on all the others > as well. Hard agree. As someone who is actively trying to reduce the amount of synchronous connection I have with the rest of the world, the fact that much of Debian's process can be done asynchronously is a strong positive for me. I acknowledge that more synchronous workflows may be more efficient, but to me the current system is part of what makes Debian special in a sea of more "modern" operating systems. -- Piper McCorkle (~pmc) they/them cont...@piperswe.me https://piperswe.me/ PGP fingerprint: 47EA 31C6 C718 6273 1A21 81F8 BDD8 9B35 FBA0 CD06 signature.asc Description: This is a digitally signed message part.
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Blair, Quoting Blair Noctis (2024-09-04 04:33:10) > On 02/09/2024 06:38, Richard Lewis wrote: > > PICCA Frederic-Emmanuel > > writes: > > > >> What about dog fooding ? > >> > >> for now we can setup a schroot and sbuild very easily and start to build a > >> local repository in minutes. > >> > >> But when it comes to install gitlab and the CI system it is another story. > >> So we rely on the central salsa instance. > > > > fwiw, i dont think that a properly scoped DEP would change any of > > that. eg, it could be written to be only about what goes into the > > archive and not say anything about using schroot locally, or whether > > salsa is gitlab or something else. but maybe i misunderstand > > >> I do not know if I am clear but I have the fear that this > >> centralisation will make us forget that de-centralisation is sort of > >> "central" to the Debian way. > > > > I suspect that if the DEP was clearer in scope and aims, these concerns > > would not actually arise > > Debian infrastructure is "centralized" in many ways. The power to decide which > packages go in the archive and which do not is "centralized" in the FTP team, > and you must upload to a "centralized" machine for them to review. buildds > build > the public facing packages, debci runs migration reference tests, they are all > "centralized" on a few hosts and in a few people. Packages are distributed > from > a single source (mirrors don't have the say of the content). Even the very > list > you are posting to is hosted on a centralized machine. How would storing > packaging sources on a centralized code hosting instance be different than > package distribution? How would a centralized CI be different than buildds and > debci? > > The more important decentralization is in the decision process. Not everything > is fit for decentralization; don't push it only for the sake of it. > > GitLab isn't perfect, sure, but it's an implementation detail of having a > centralized code hosting and CI. I'd personally expect the CI to be basically > the same as debci (maybe even merge the two or make salsa delegate CI to > debci), > but that's another topic. Yes, some parts of Debian are centralized, but it seems you turn those into reasons for giving up on the flexibility of others which are not. I have worked in areas with weak internet connection (near the Amazonas jungle in Peru, and at the country side of Sweden) where I could have a full mirror of Debian and an archive of email conversations, and from that not only release package updates but also work on developing Debian Pure Blends (i.e. "forks" of Debian containing purely Debian parts), with only occational need to syncronize my data with Debian. I don't say that Debian must work for jungle developers, nor that we must all use email and not different forms of collaboration requiring better connectivity. My point is that Debian *allows* collaboration also without heavy realtime connectivity that most of us take for granted in our working environments, and I fail to see why the few points that are centralized is a reason for giving up on all the others as well. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On 02/09/2024 06:38, Richard Lewis wrote: > PICCA Frederic-Emmanuel > writes: > >> What about dog fooding ? >> >> for now we can setup a schroot and sbuild very easily and start to build a >> local repository in minutes. >> >> But when it comes to install gitlab and the CI system it is another story. >> So we rely on the central salsa instance. > > fwiw, i dont think that a properly scoped DEP would change any of > that. eg, it could be written to be only about what goes into the > archive and not say anything about using schroot locally, or whether > salsa is gitlab or something else. but maybe i misunderstand >> I do not know if I am clear but I have the fear that this >> centralisation will make us forget that de-centralisation is sort of >> "central" to the Debian way. > > I suspect that if the DEP was clearer in scope and aims, these concerns > would not actually arise Debian infrastructure is "centralized" in many ways. The power to decide which packages go in the archive and which do not is "centralized" in the FTP team, and you must upload to a "centralized" machine for them to review. buildds build the public facing packages, debci runs migration reference tests, they are all "centralized" on a few hosts and in a few people. Packages are distributed from a single source (mirrors don't have the say of the content). Even the very list you are posting to is hosted on a centralized machine. How would storing packaging sources on a centralized code hosting instance be different than package distribution? How would a centralized CI be different than buildds and debci? The more important decentralization is in the decision process. Not everything is fit for decentralization; don't push it only for the sake of it. GitLab isn't perfect, sure, but it's an implementation detail of having a centralized code hosting and CI. I'd personally expect the CI to be basically the same as debci (maybe even merge the two or make salsa delegate CI to debci), but that's another topic. -- Sdrager, Blair Noctis OpenPGP_signature.asc Description: OpenPGP digital signature
LPC: Support for Complex Cameras in Debian
Hi everyone, [A continuation of my previous email, hoping that a new subject get more attention :) https://lists.debian.org/debian-devel/2024/06/msg00191.html] In two weeks, I'll be hosting a micro-conference about Complex Cameras in Linux at LPC in Vienna: https://lpc.events/event/18/contributions/1679/ . Unfortunately, the event is sold out and we only have a 3-hour slot to address 20 years of challenges! To make the most of our time, we're organizing a full day of meetings the day before the conference, bringing together vendors, distros, and Linux kernel maintainers. The goal of these sessions is to collaborate on how to best support complex cameras in Linux, such as the IPU-6 and those found in smartphones. It would be fantastic to have someone from Debian present at this meeting to represent our users and ensure they can fully utilize their devices within our distro. As a newer DD, I don't feel comfortable speaking on behalf of the project just yet. I'm hoping someone from debian-dev or debian-multimedia might be interested in participating, either in person or virtually. Alternatively, if someone could spare 30-60 minutes to discuss Debian's best approach with me before the event, that would be immensely helpful. Feel free to reach out to me via email or IRC anytime. Thanks in advance! Regards,
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
On 03/09/2024 15:36, Otto Kekäläinen wrote: My information was based on what Salsa admin posted at https://salsa.debian.org/salsa/support/-/issues/395 Hi Otto, Thanks for that link, which took me nearly a minute to open! Quoting from there. Could we keep the issue open for now and only close it once it is fixed? Agreed. I can't reopen it myself, buy maybe you could as reporter. Perhaps people might provide as comments further insights about the issue. More likely if its open. Regards, Peter
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Hi! > Hi Otto, > Until recently I generally found Salsa response to be adequate, > but for the last couple of days it has been so > excruciatingly slow as to be almost unusable. > > > In response, Otto Kekäläinen noted that the Salsa admins > > had posted about upcoming hardware upgrades and other improvements to > > address these issues at > > https://salsa.debian.org/salsa/support/-/issues. > > Which particular issue here relates to the planned hardware upgrade? My information was based on what Salsa admin posted at https://salsa.debian.org/salsa/support/-/issues/395 I have also witnessed Salsa being very slow in the past couple of days, but I am not aware of what is going on. Hopefully it gets fixed soon.
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
On 28/08/2024 03:13, Otto Kekäläinen wrote: ## Performance and Reliability Multiple participants, including Salvo Tomaselli, Johannes Schauer Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as important. Hi Otto, Until recently I generally found Salsa response to be adequate, but for the last couple of days it has been so excruciatingly slow as to be almost unusable. In response, Otto Kekäläinen noted that the Salsa admins had posted about upcoming hardware upgrades and other improvements to address these issues at https://salsa.debian.org/salsa/support/-/issues. Which particular issue here relates to the planned hardware upgrade? Regards, Peter
Debian Mentors - Confirmed package of the day - graphite-carbon - Needs love
Hi Debian Developers, Our package marked as "confirmed" that has languished on mentors for quite some time is our package of the day. Please could a DD with a little free time, graciously give it your time and show this package some love? Package: graphite-carbon Links... * Mentors - https://mentors.debian.net/package/graphite-carbon/ * RFS bug - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077619 * Salsa - https://salsa.debian.org/debian-graphite-team/graphite-carbon Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
PICCA Frederic-Emmanuel writes: > What about dog fooding ? > > for now we can setup a schroot and sbuild very easily and start to build a > local repository in minutes. > > But when it comes to install gitlab and the CI system it is another story. So > we rely on the central salsa instance. fwiw, i dont think that a properly scoped DEP would change any of that. eg, it could be written to be only about what goes into the archive and not say anything about using schroot locally, or whether salsa is gitlab or something else. but maybe i misunderstand > I do not know if I am clear but I have the fear that this > centralisation will make us forget that de-centralisation is sort of > "central" to the Debian way. I suspect that if the DEP was clearer in scope and aims, these concerns would not actually arise
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
What about dog fooding ? for now we can setup a schroot and sbuild very easily and start to build a local repository in minutes. But when it comes to install gitlab and the CI system it is another story. So we rely on the central salsa instance. It seems to me that a great strength of Debian is to empower the user and provide everything (almost out of the box) in order to de-centralize the build process. I do not know if I am clear but I have the fear that this centralisation will make us forget that de-centralisation is sort of "central" to the Debian way. Frederic
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
> My overall impression is that this is a bold attempt, but the document could > do > with some copy-editing to whittle it down, make it more focussed, and possibly > narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be > done further down the line in a follow-up DEP? If you want editing advice debian-l10n-engl...@lists.debian.org is a great resource I would suggest: - make the "intro" less general. Set out a clear, short, list of objectives/goals/what you want to improve. This will also help with setting a clearer scope - make the "principals" more general (or keep them but dont call them principals -- they currently read like a set of implementation details), and explain how they help the project achieve the objectives. This will help you edit down the text below each 'principal'. You might also want to decide if these are mandatory, recommended or suggested. - (then see whether the other sections are still needed)
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi Jonathan! The discussion was summarized in a separate "Summay" email by me on this list, and a comment in the MR (which merges the two discussions) and it just happened that the next day it was also covered in https://lwn.net/Articles/986480/ I am currently writing revision 2 of the proposal. I will notify when published. - Otto
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Thanks for working on this. I finally had a read over it today.
I've found the split in discussion between this list and the Merge Request
comments
hard to manage. It would help a lot, I think, if some of the MR threads were
marked
resolved, assuming the issues they describe are resolved. That would reduce the
amount of stuff to read.
I got random errors from Gitlab whilst trying to add comments myself
("Error dismissing suggestion popover. Please try again.") but perhaps they're
irrelevant (or perhaps nobody will see my comments).
My overall impression is that this is a bold attempt, but the document could do
with some copy-editing to whittle it down, make it more focussed, and possibly
narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
done further down the line in a follow-up DEP?
There are a few references to DEP-14, which Bastian points out has been in
"candidate" state since 2020. Your proposal is not strictly depending on
DEP-14, but I wonder if someone invested should try and get that one over
the line as well (if not before). It would give me (and I wager others) more
confidence in the whole DEP process if more of the proposals made it into a
"final" state than are now.
Re: Debian openssh option review: considering splitting out GSS-API key exchange
Excellent - this substantially reduces the amount of pre-authentication attack surface exposed on your users' sshd by default. On Fri, 30 Aug 2024, Colin Watson wrote: > On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote: > > * for Debian trixie (current testing): > > > >* add dependency-only packages called something like > > openssh-client-gsskex and openssh-server-gsskex, depending on their > > non-gsskex alternatives > >* add NEWS.Debian entry saying that people need to install these > > packages if they want to retain GSS-API key exchange support > > This is now implemented in Debian unstable. I called the packages > openssh-client-gssapi and openssh-server-gssapi, with the intention of > splitting out both GSS-API authentication and key exchange support > later: that is, in trixie+1 I intend to build openssh without > --with-kerberos5 as well as dropping the key exchange patch from the > main packages, and you'd have to use openssh-*-gssapi for either > function. > > -- > Colin Watson (he/him) [cjwat...@debian.org] > ___ > openssh-unix-dev mailing list > openssh-unix-...@mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi! > NOTE: The following idea might be out-of-scope in DEP-18, but specific > use-case to improve > collaboration in Debian, IMHO. > > Here is just an idea: put collaboration policy metadata in debian/control. > (The following idea assumes that non-maintainer DD tend to hesitate to > commit/merge it) > > * Collaboration-Policy: debian/CONTRIBUTION.md > Yes, we have README.source already, but it might be better to note > in a separate file about collaboration. > * Collaboration-Policy-Commit: yes > It declares that the package owner encourages non-maintainer DD to > commit directly without merge request. > * Collaboration-Policy-Merge: yes > It declares that the package owner encourages non-maintainer DD to > allow merge requests. > (DD has maintainer right in salsa.d.o by default as you know, but > you can merge without worry if there is it.) > * Collaboration-Policy-LowThresholdNmu: yes > It declares that LowThresholdNmu rule [1] is applied. > * Collabollation-Policy-NMU-Delay: 15 > It declares that NMU delay the package owner wants. I agree that the CONTRIBUTING.md pattern is common on GitHub/GitLab, but we have already thousands of packages with debian/README.source (a couple also with README.source.md) as this file is documented in https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source. This should be to go-to location for any generic info on how to maintain the package or contribute to it. We also have some debian/source/* files as documented in https://www.debian.org/doc/manuals/maint-guide/dother.en.html#sourcel (and https://manpages.debian.org/unstable/dpkg-dev/dpkg-source.1.en.html#FILES) that instruct how patches should be managed in the sources. Perhaps there could be more metadata to define how patch submissions should be managed Nearly ten thousand packages also have a debian/gbp.conf file, which in a way is also a way to communicate (automatically) how to build the package and how to contribute to it correctly. I am tempted to put a gbp.conf and README.source template in DEP-18, but that would probably not be received well by those who prefer dgit, although dgit can be used together with git-buildpackage as well.
Re: Debian openssh option review: considering splitting out GSS-API key exchange
On Tue, Apr 02, 2024 at 01:30:11AM +0100, Colin Watson wrote: > * for Debian trixie (current testing): > >* add dependency-only packages called something like > openssh-client-gsskex and openssh-server-gsskex, depending on their > non-gsskex alternatives >* add NEWS.Debian entry saying that people need to install these > packages if they want to retain GSS-API key exchange support This is now implemented in Debian unstable. I called the packages openssh-client-gssapi and openssh-server-gssapi, with the intention of splitting out both GSS-API authentication and key exchange support later: that is, in trixie+1 I intend to build openssh without --with-kerberos5 as well as dropping the key exchange patch from the main packages, and you'd have to use openssh-*-gssapi for either function. -- Colin Watson (he/him) [cjwat...@debian.org]
Re: Debian 10 "buster" moved to archive.debian.org
Hi, On Mon, May 27, 2024 at 8:07 PM Leandro Cunha wrote: > > Hi, > > On Fri, May 24, 2024 at 10:28 PM Otto Kekäläinen wrote: > > > > Hi! > > > > So just to clarify, are you saying that a copy of > > https://security.debian.org/debian-security/dists/buster/ will never > > be archived at https://archive.debian.org/debian-security/dists/ like > > previous releases have been so far? > > > > This is not about getting *new security updates*, but purely a > > question of how moving Buster to archival works and how e.g. CI > > systems that test upgrades from Buster should work. > > > > I see that e.g. > > https://deb.debian.org/debian/dists/buster/main/binary-armel and > > https://deb.debian.org/debian/dists/buster-updates/main/binary-armel > > no longer exists, but have been archived at > > https://archive.debian.org/debian/dists/buster/main/binary-armel/ and > > https://archive.debian.org/debian/dists/buster-updates/main/binary-armel/. > > > > The > > https://security.debian.org/debian-security/dists/buster/updates/main/binary-armel > > is now gone, is the intent for it to show up on archive.debian.org in > > some form? > > True, you're right, the buster is missing from > https://archive.debian.org/debian-security/dists/ and I'm waiting for > a response from the people who take care of this repository about > this. I think they forgot to migrate. > > -- > Cheers, > Leandro Cunha I don't know if I understood correctly, it would only be at the end of LTS support that the security repository file would be created, this has already happened and is not in the repository. Anyone who wants to clarify this point, know that I would be very grateful to a Debian user of more than 10 years. :) For the most part, I have always been a user of testing and sometimes I have used stable. As the release of the next version approaches, I switch to testing if I am on stable and then use testing most of the time. But it is very difficult to stay on older versions. But there is a risk of them being used in containers, which is my case with buster and I run an application of mine in Ruby (Ruby on Rails) in a container using Podman using this Debian version. https://archive.debian.org/debian-security/dists/ https://www.debian.org/News/2024/20240814 https://wiki.debian.org/LTS/Extended -- Cheers, Leandro Cunha signature.asc Description: Binary data
Re: Debian installation problem on Macbook pro from 2019
On 8/23/24 00:24, lina wrote: Hi, During the Debian (stable) installation on Macbook pro from 2019, my internal keyboard is not recognizable even I exhausted all possible keyboard options listed during dpkg-reconfiguration keyboard-configuration # more /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. *XKBMODEL="apple_laptop"* XKBLAYOUT="us" XKBVARIANT="dvorak-classic" XKBOPTIONS="lv3:ralt_alt" BACKSPACE="guess" I also tried *XKBMODEL="macbook79" XKBMODEL="macbook78" XKBMODEL="macintosh"** XKBMODEL="macintosh_old"* *XKBMODEL="apple"* *XKBMODEL="applealu_ansi"* # dmesg | grep -i keyboard [ 2.237578] usb 1-1.2: Product: Magic Keyboard [ 2.464951] usb 1-1.3: Product: USB Keyboard [ 2.466381] apple 0003:05AC:0267.0002: fixing up Magic Keyboard battery report descriptor [ 2.466464] apple 0003:05AC:0267.0002: Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling [ 2.466485] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:0267.0002/input/input6 [ 2.466530] apple 0003:05AC:0267.0002: input,hiddev0,hidraw1: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input0 [ 2.466686] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:0267.0003/input/input7 [ 2.471679] hid-generic 0003:2109:D101.0005: hiddev1,hidraw2: USB HID v1.10 Device [VIA Labs, Inc. USB Keyboard ] on usb-:00:14.0-1.3/input0 [ 2.523233] apple 0003:05AC:0267.0003: input,hiddev2,hidraw3: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input1 [ 2.523305] apple 0003:05AC:0267.0004: hiddev3,hidraw4: USB HID v1.10 Device [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input2 [ 4.231170] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... I have done a lot of installs on a 2011 iMac, and in my experience, you need to do it with a wired USB keyboard. After the install, you can manage the system with any keyboard you can manage to get working, but for the purposes of installation, the Debian Installer and the Macintosh together seem to need a wired USB keyboard.
Re: DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Il 28/08/2024 04:13, Otto Kekäläinen ha scritto: Hi! While I intend to continue on iterating DEP-18, here is a summary to those who did not wade through the 140+ messages on the topic. Unfortunately, the summary itself is also a bit long :) Big thanks for your work and of other people that are trying to improve contribution and collaboration in Debian. ## Maintainer Workflows There were concerns that requiring specific Git and Gitlab practices could create burdens for existing maintainers, especially single-person maintainers. Sean Whitton described his own preferences as a maintainer: I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written such as to account for these sorts of choices. Fabio Fantoni suggested allowing maintainers to specify their preferred collaboration methods in a machine-readable way, for example through a "Collaboration-Policy" field in debian/control. As pointed by other people there is debian/README.source that can be used for that. So if don't want to add a new field/s to d/control, and/or a new file we could simply use that one making this thing more known. and in the case of teams or people who manage many packages (even hundreds or thousands) with the same methods could put a link in d/README.source so as to point to a single page/site/repository to keep updated in a simpler and faster way with all the information ## Performance and Reliability Multiple participants, including Salvo Tomaselli, Johannes Schauer Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as important. In response, Otto Kekäläinen noted that the Salsa admins had posted about upcoming hardware upgrades and other improvements to address these issues at https://salsa.debian.org/salsa/support/-/issues. Thanks for working to improving Salsa. However, there have also been numerous performance problems and unavailability of other parts useful to both contributors and users, in particular packages.debian.org and wiki.debian.org which don't seems has been considered, or am I wrong? ## Machine-Readable Metadata Fabio Fantoni and Niels Thykier proposed including more machine-readable metadata about packaging workflows (e.g. in debian/control) to help automate contributor onboarding. Niels Thykier outlined some specific examples of information that could be captured: Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-sort`, then which options)? Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review. Even if don't want to add them as Machine-Readable Metadata, I think can put them at least in debian/README.source (more details above), I think the important thing would be to advise maintainers more to make such information easily available. OpenPGP_signature.asc Description: OpenPGP digital signature
DEP-18 discussion summary (Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Hi! While I intend to continue on iterating DEP-18, here is a summary to those who did not wade through the 140+ messages on the topic. Unfortunately, the summary itself is also a bit long :) Summary of mailing list discussion in https://lists.debian.org/debian-devel/2024/07/msg00429.html ## Overall Sentiment There was a broad consensus that Debian workflows are too fractured and would benefit from more standardization and unification. However, there were differing opinions on the right approach to achieve this. Soren Stoutner expressed this sentiment clearly: > 1. Debian workflows are too fractured. The project would be better if we > asked people to standardize around a single (or a small number) of workflows. > To do so, the workflow would need to be flexible enough to handle the wide > range of technical needs of all the packages and upstream configurations. > 2. Standardizing around a single (or small number of) workflows wil make some > people unhappy. But that is an acceptable price to pay because of the general > benefit to the project as long as the correct solution is adopted. Unity is > more important than minority opinions on this particular issue. Similarly, Andrey Rakhmatullin argued that while some may resign, "the '1000 DDs status quo' problem also means that more people leave than join _anyway_. Not the unity per se, but having significantly lower barriers to start contributing" is important. ## Git and Gitlab Usage Multiple participants noted that most other Linux distributions use Git as the primary version control system, often with GitLab or GitHub for collaboration. Debian's multi-branch approach with pristine-tar was seen as somewhat unique. There were differing views on whether Debian should move closer to the more common Git-based workflows used elsewhere, or maintain its own custom approach, which of git-buildpackage and dgit are the most common ones (both with multiple ways to use them). ## Mandatory vs Optional Policies Some participants, like Salvo Tomaselli, felt DEP-18 was too prescriptive in mandating specific tools and workflows, and that a more flexible, optional approach would be better: > Keep in mind that unhappy people quit. I don't think that unity is so > important that we're willing to sacrifice project members. Others, including Soren Stoutner, argued that standardization was important, even if it made some people initially unhappy, as long as the right solution was adopted: "Unity is more important than minority opinions on this particular issue." ## Maintainer Workflows There were concerns that requiring specific Git and Gitlab practices could create burdens for existing maintainers, especially single-person maintainers. Sean Whitton described his own preferences as a maintainer: > I am happy to use salsa for git hosting and access management. I love that I > can easily grant push access to my non-DD team members. But, I turn off salsa > MRs for the repos of all packages I regularly upload. I would hope that this > DEP can be written such as to account for these sorts of choices. Fabio > Fantoni suggested allowing maintainers to specify their preferred > collaboration methods in a machine-readable way, for example through a > "Collaboration-Policy" field in debian/control. ## Performance and Reliability Multiple participants, including Salvo Tomaselli, Johannes Schauer Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained about Salsa/GitLab being slow or unreliable at times, which deterred contribution. Improvements to performance and uptime were seen as important. In response, Otto Kekäläinen noted that the Salsa admins had posted about upcoming hardware upgrades and other improvements to address these issues at https://salsa.debian.org/salsa/support/-/issues. ## Machine-Readable Metadata Fabio Fantoni and Niels Thykier proposed including more machine-readable metadata about packaging workflows (e.g. in debian/control) to help automate contributor onboarding. Niels Thykier outlined some specific examples of information that could be captured: > Does this package use `gbp dch` (or some other mechanisms) to generate the > changelog OR should I include a changelog entry with my patch. Does this > package use some form of automatic formatting that I should apply when I do > my changes (if `wrap-and-sort`, then which options)? Does the maintainer > prefer MR via salsa or BTS with patches for when I want to submit my changes > for review. ## Overall There seemed to be general agreement that improving collaboration was important, but the right approach was still being debated. ## Mailing list participants - Jonas Smedegaard - Salvo Tomaselli - Luca Boccassi - Charles Plessy - Marco d'Itri - Sean W
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-08-27
Dear all DDs, Below is the link to the page of currently "confirmed" being in good order packages that are awaiting a DD review and possible upload. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests Please check that another DD is not already involved in the package. P.S. I have have emailed some team lists, as we have packages in a variety of laguages and may interest DDs from these teams. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Debian 10 "buster" moved to archive.debian.org
Hello Ansgar, Am Sat, Mar 23, 2024 at 09:30:49AM +0100 schrieb Ansgar 🙀: > Debian 10 "buster" has moved to archive.debian.org in order to free > space on the main mirror network. We plan to start removing files for > non-LTS architectures in about two weeks; the existing Release files > will then refer to no longer existing files on the main mirror network. > > An exception is the security archive (which already has no non-LTS > architectures): we will only archive it after LTS support ended. > > For LTS users this does not require any changes. I'd like to understand the process a little better: 1. First *non*-LTS architectures (mips,ppc,s390,…) have been moved 2024-03 2. LTS for Buster ended recently 2024-06-30 ¹ 3. Debian 13 Trixie release is expected in 2025 4. ELTS for Buster is probably until 2029-06 ² When will *LTS* architectures (x86,arm,…) also be removed? My guess would be between 2. and either when more free space is needed anytime in the future, or latest 3. Thank you for your excellent work and hopefully an answer. Philipp 1: https://wiki.debian.org/LTS 2: https://wiki.debian.org/LTS/Extended
Re: DEP-18: Git and GitLab usage in other Linux distros (Re: Representing Debian Metadata in Git)
Hi, Quoting Otto Kekäläinen (2024-08-27 08:42:53) > > Before pushing for new ways of representing Debian stuff in git, I think it > > would be a good idea to learn from all the other distros and distro-like > > systems successfully using git [1]. Debian is not the only distro that > > wants to use git to capture changes and encourage contributions to its > > packages. > > > > Chris > > > > [1] alpine, homebrew, freebsd ports come to mind immediately. nixos > > and others too. > > …this is the right attitude and I wanted to cater to it and summarize > how packaging sources look in various distros. thank you for your investigations. > - The number of contributors/maintainers is low everywhere. Ending > single-person maintainership is not going to happen any soon, but hopefully, > we can work towards first increasing the pool of contributors who > participate, and then expand on practices around Merge Requests and reviews > and maybe have some kind of formal sign-offs from at least two people before > upload. Initially, perhaps only for the top-150 packages. But before we can > institute review workflows, we need to have more unification around the > version control and basic packaging workflows. I'm still dubious any "2 people sign-off" can work [1]. In your investigations, did you find other distributions which implemented this successfully? I think "work towards easier collaboration" and "require more than one person for every commit/upload" are two very different things which should be discussed independently. Thanks! cheers, josch [1] My own experience with this comes from my contributions to devscripts which is in the debian group, thus "team" maintained and probably all of you have it installed and should feel responsible for it (right?). Nevertheless, my MRs mostly get zero replies, so I usually just merge them after waiting a couple of months. The situation is a bit better for sbuild but not by much. signature.asc Description: signature
DEP-18: Git and GitLab usage in other Linux distros (Re: Representing Debian Metadata in Git)
Hi! Considering what other Linux distros are doing and what is popular among software developers today, Debian will probably gain more contributors and be more approachable if we don't reinvent too many custom things, and hence... .. > In the current DEP14/DEP18 discussions a lot of discussion was had > about how we should represent Debian things in git; your mail also > goes into this direction. > > My *feeling* is we should do the opposite - that is, represent less > Debian stuff in git, and especially do it in less Debian-specific > ways. IOW, no git extensions, no setup with multiple branches that > contain more or less unrelated things, etc. > > I think we should move more towards a setup that is easily > understood by people not closely following our Debian-specific > things. We should avoid surprising things, again that would include > the multiple branches and any git extensions. > > Before pushing for new ways of representing Debian stuff in git, I > think it would be a good idea to learn from all the other distros > and distro-like systems successfully using git [1]. Debian is not > the only distro that wants to use git to capture changes and > encourage contributions to its packages. > > Chris > > [1] alpine, homebrew, freebsd ports come to mind immediately. nixos > and others too. …this is the right attitude and I wanted to cater to it and summarize how packaging sources look in various distros. I am using MariaDB in the examples as it is a big and common package that can be found everywhere. ## Alpine Example: https://git.alpinelinux.org/aports/tree/main/mariadb Package defined in a single APKBUILD file somewhat similar to a .spec file. Patches are plain patches in the same directory. References to upstream source packages by SHA256SUMs. In my view it is not effortless nor transparent to track code changes. Hosting is a monorepo on cgit. The official way to contribute is on their GitLab instance using Merge Requests at https://gitlab.alpinelinux.org/alpine/aports ## Arch Example: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=android-x86-64-mariadb Very similar to Alpine, package defined in a single PKGBUILD file. Patches as plain files in the same directory. No upstream git or files, just MD5SUM references to upstream tarballs. One git repository per package. Authoritative git repo on cgit. Collaboration features via https://gitlab.archlinux.org/archlinux. ## Fedora Example: https://src.fedoraproject.org/rpms/mariadb10.11/tree/rawhide Fully custom code hosting, building and testing system due to long history building up their own infra, which includes a facility to make pull requests. Base of packaging is a .spec file plus a bunch of included extra files. Patches as plain files. ## CentOS Stream Example: https://gitlab.com/redhat/centos-stream/rpms/mariadb/-/tree/c9s Basically, downstream from Fedora with some modifications. Hosting and collaboration on custom GitLab instance. ## Rocky Linux Example: https://git.rockylinux.org/staging/rpms/mariadb/-/tree/r9 This is one of the CentOS clones that came about after Red Hat acquired CentOS. Inherits the .spec file from Fedora/CentOS. Custom GitLab instance for all collaboration. ## OpenSUSE Example: https://build.opensuse.org/package/show/openSUSE:Factory/mariadb Packaging based on .spec file and individual patch files. The .spec file format is custom and not fully the same as in the Fedora ecosystem. Hosting and building on their custom-build platform (the Open Build System) which includes graphical merge requests under name "Requests". ## NixOS Example: https://github.com/NixOS/nixpkgs/tree/nixos-unstable/pkgs/servers/sql/mariadb Custom single-file packaging format in a .nix file. No upstream source code hosting, just reference by SHA256 to upstream tarballs. Monorepo with all packaging files. Uses GitHub. Currently, 5k+ open Pull Requests and almost 300k (!) closed ones. ## Gentoo Custom single-file .ebuild files, with some patches as individual files under files/. Authoritative hosting on cgit, but https://packages.gentoo.org/packages/dev-db/mariadb links to GitHub for Pull Requests as the recommended way to contribute. ## Deepin Example: https://github.com/deepin-community/mariadb/tree/master/debian/deepin The most popular Debian variant in China. Packaging done in subdirectory `debian/deepin/`. Hosted on GitHub. Imports seem to be one commit per upstream release, not sure if the content is from git or tarball, but it isn't upstream git commits. They seem to have some automation that files Pull Requests automatically when new upstream import is pending. ## OpenMandriva Example: https://github.com/OpenMandrivaAssociation/mariadb/tree/rolling Again a .spec file user, patches as individual files. Hosting and Pull Requests on GitHub. ## FreeBSD ports Example: https://www.freshports.org/databases/mariadb114-server/ -> https:/
Re: Debian installation problem on Macbook pro from 2019
On Fri, 2024-08-23 at 09:24 +0200, lina wrote: > Hi, > > During the Debian (stable) installation on Macbook pro from 2019, Installation problems should generally be reported to the debian-boot list. > my internal keyboard is not recognizable even I exhausted all possible > keyboard options listed during > > dpkg-reconfiguration keyboard-configuration [...] If I understand you correctly, typing on the internal keyboard had no effect (rather than generating the wrong symbols). You plugged in an external USB keyboard to interact with the installer, wich worked. Is that right? This would mean that a driver needed for the internal keyboard was missing. The keyboard-configuration package wouldn't help with this. We'll need to update the list of drivers included in the installer. Ben. -- Ben Hutchings Man invented language to satisfy his deep need to complain. - Lily Tomlin signature.asc Description: This is a digitally signed message part
Re: debian/gbp.cnf analytics?
On Tue, 20 Aug 2024 09:04:59 +0100, Simon McVittie wrote: > 3. a workflow where upstream/latest contains imported tarball snapshots >*with* upstream git history merged in, most likely via upstream-vcs-tag >(like src:glib2.0) … > I'm surprised the number your statistics give for (3.) is such a small > proportion: I find this workflow really useful as a way to reconcile > devref 6.8.8.1's assertion that pristine upstream tarballs are important > with the desire to have upstream git history readily available to make > maintenance easier. In the Debian Perl Group, our dpt-import-orig wrapper around gbp-import-orig uses --upstream-vcs-tag, but it guesses the name of the upstream tag, so we're typically not using upstream-vcs-tag in gbp.conf. As a result, the numbers from checking all gbp.conf files are lower than the real use. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Re: [Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Sat, Aug 24, 2024 at 2:06 AM Ahmed Siam wrote: > On Sat, Aug 24, 2024 at 2:00 AM Ahmed Siam wrote: > > On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote: > > > Perl pipeline run: > > > - https://salsa.debian.org/ahmedsiam/perl/-/pipelines/719321 > This pipeline run from Nodejs shows a similar error to the one I got > in Perl package: > https://salsa.debian.org/js-team/nodejs/-/pipelines/683419 Hmm, although they look similar, It seems that the cause of each one of them is different. I have opened issues for reporting this two pipeline runs here: - Perl error: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/378 - Nodejs error: https://salsa.debian.org/salsa-ci-team/pipeline/-/issues/379
Re: [Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Sat, Aug 24, 2024 at 2:00 AM Ahmed Siam wrote: > > On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote: > > > > On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote: > > > A bunch of packages I know (nodejs, receptor to name a few) have salsa CI > > > failures, but no sbuild failures. > > > It would be perfect if the build process was exactly the same. > > > > There is a work-in-progress MRs about using sbuild for building packages. > > > > When I tried to run salsaci on the perl package, It failed at the first job. > > Maybe the bug that causes failure of the pipeline on nodejs is similar. > > I will try to figure out the cause and fix it. > > Actually, it isn't the same error. > It seems that nodejs fails to build because of runner timeout. > I think this error won't be solved even after switching to sbuild. > Nodejs package needs more powerful runners and/or larger timeout value. > > Nodejs pipeline run: > https://salsa.debian.org/js-team/nodejs/-/pipelines/681481 This pipeline run from Nodejs shows a similar error to the one I got in Perl package: https://salsa.debian.org/js-team/nodejs/-/pipelines/683419 -- Ahmed Siam
Re: [Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Sat, Aug 24, 2024 at 1:45 AM Ahmed Siam wrote: > > On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote: > > A bunch of packages I know (nodejs, receptor to name a few) have salsa CI > > failures, but no sbuild failures. > > It would be perfect if the build process was exactly the same. > > There is a work-in-progress MRs about using sbuild for building packages. > > When I tried to run salsaci on the perl package, It failed at the first job. > Maybe the bug that causes failure of the pipeline on nodejs is similar. > I will try to figure out the cause and fix it. Actually, it isn't the same error. It seems that nodejs fails to build because of runner timeout. I think this error won't be solved even after switching to sbuild. Nodejs package needs more powerful runners and/or larger timeout value. Nodejs pipeline run: https://salsa.debian.org/js-team/nodejs/-/pipelines/681481 -- Ahmed Siam
Re: [Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
On Sat, Aug 24, 2024 at 1:25 AM Jérémy Lal wrote: > A bunch of packages I know (nodejs, receptor to name a few) have salsa CI > failures, but no sbuild failures. > It would be perfect if the build process was exactly the same. There is a work-in-progress MRs about using sbuild for building packages. When I tried to run salsaci on the perl package, It failed at the first job. Maybe the bug that causes failure of the pipeline on nodejs is similar. I will try to figure out the cause and fix it. sbuild related MRs: - https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/483 - https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/484 Perl pipeline run: - https://salsa.debian.org/ahmedsiam/perl/-/pipelines/719321 -- Ahmed Siam
Re: [Debian-salsa-ci] DEP18 follow-up: What would be the best path to have all top-150 packages use Salsa CI?
Hi! > And is this web page authoratative? Or just a false search positive? > > https://salsa.debian.org/salsa-ci-team/pipeline#basic-use > > It doesn't mention the "salsa" command at all, but maybe that isn't > the right web page. This goes back to my observation that it would be > helpful if there was better documentation to make life easier for > package maintainers. Yes, it is the authoritative page. I will update the page based on discussions on debian-devel. Draft pending at https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/519 Thanks for sharing your experiences!
Re: Debian installation problem on Macbook pro from 2019
On Friday, 23 August 2024 02:24:44 CDT lina wrote: > Hi, > > During the Debian (stable) installation on Macbook pro from 2019, > > my internal keyboard is not recognizable even I exhausted all possible > keyboard options listed during Hi, I think this question would fit better on [debian-user]. This mailing list is for discussing Debian development, not support. [debian-user]: https://lists.debian.org/debian-user/ -- Piper McCorkle (~pmc) they/them cont...@piperswe.me https://piperswe.me/ PGP fingerprint: 47EA 31C6 C718 6273 1A21 81F8 BDD8 9B35 FBA0 CD06 signature.asc Description: This is a digitally signed message part.
Re: Debian installation problem on Macbook pro from 2019
Thanks, originally I posted on debian user, the only one who replied is rather arrogant, I do not see the point to continue that thread, I probably to start a new thread next time on debian-user, thanks again, lina On Fri, Aug 23, 2024 at 10:05 AM Piper McCorkle wrote: > On Friday, 23 August 2024 02:24:44 CDT lina wrote: > > Hi, > > > > During the Debian (stable) installation on Macbook pro from 2019, > > > > my internal keyboard is not recognizable even I exhausted all possible > > keyboard options listed during > > Hi, > > I think this question would fit better on [debian-user]. This mailing list > is for discussing Debian development, not support. > > [debian-user]: https://lists.debian.org/debian-user/ > > -- > Piper McCorkle (~pmc) > they/them > cont...@piperswe.me > https://piperswe.me/ > > PGP fingerprint: > 47EA 31C6 C718 6273 1A21 > 81F8 BDD8 9B35 FBA0 CD06
Debian installation problem on Macbook pro from 2019
Hi, During the Debian (stable) installation on Macbook pro from 2019, my internal keyboard is not recognizable even I exhausted all possible keyboard options listed during dpkg-reconfiguration keyboard-configuration # more /etc/default/keyboard # KEYBOARD CONFIGURATION FILE # Consult the keyboard(5) manual page. *XKBMODEL="apple_laptop"* XKBLAYOUT="us" XKBVARIANT="dvorak-classic" XKBOPTIONS="lv3:ralt_alt" BACKSPACE="guess" I also tried *XKBMODEL="macbook79"XKBMODEL="macbook78"XKBMODEL="macintosh"* *XKBMODEL="macintosh_old"* *XKBMODEL="apple"* *XKBMODEL="applealu_ansi"* # dmesg | grep -i keyboard [2.237578] usb 1-1.2: Product: Magic Keyboard [2.464951] usb 1-1.3: Product: USB Keyboard [2.466381] apple 0003:05AC:0267.0002: fixing up Magic Keyboard battery report descriptor [2.466464] apple 0003:05AC:0267.0002: Fn key not found (Apple Wireless Keyboard clone?), disabling Fn key handling [2.466485] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.0/0003:05AC:0267.0002/input/input6 [2.466530] apple 0003:05AC:0267.0002: input,hiddev0,hidraw1: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input0 [2.466686] input: Apple Inc. Magic Keyboard as /devices/pci:00/:00:14.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:05AC:0267.0003/input/input7 [2.471679] hid-generic 0003:2109:D101.0005: hiddev1,hidraw2: USB HID v1.10 Device [VIA Labs, Inc. USB Keyboard ] on usb-:00:14.0-1.3/input0 [2.523233] apple 0003:05AC:0267.0003: input,hiddev2,hidraw3: USB HID v1.10 Keyboard [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input1 [2.523305] apple 0003:05AC:0267.0004: hiddev3,hidraw4: USB HID v1.10 Device [Apple Inc. Magic Keyboard] on usb-:00:14.0-1.2/input2 [4.231170] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout...
Re: Representing Debian Metadata in Git
Hello, I think that more than you realise of this already exists :) On Tue 20 Aug 2024 at 04:10pm +09, Simon Richter wrote: > From a requirements perspective, I'd like to be able to > > - express patches as commits: >- allow cherry-picking upstream commits as Debian patches >- allow cherry-picking Debian patches for upstream submission git-debrebase and git-dpm already achieve this. > - express filter steps for generating the upstream archive(s) from a tree‑ish > and some metadata Excluded-Files in d/copyright is for this. I guess that you disprefer that because it's part of the tree, though. > - store upstream signatures inside Git Well, there's signatures on their tags. > - keep a history of patches, including patches applied to previously released > packages This is already there with git-debrebase and git-dpm, though it is a bit fiddly to dig it out. -- Sean Whitton signature.asc Description: PGP signature
Re: Representing Debian Metadata in Git
On Aug 22, Aurélien COUDERC wrote: > I personally think it’s crazy / not a good use of my time to try and > mix both upstream and packaging history in the same repo and try to > make git dance around that when handling new upstream releases. The > extents of the ongoing d-devel discussions on the topic tend to > reinforce that feeling. Oh well. FWIW I think it's crazy and not a good use of my time to NOT have the complete upstream history in the same repository that I use for Debian packaging. :-) > (For some value of $fun, try cloning the mesa or > Firefox repos from a sloppy Internet connection for a packaging > analysis or an occasional contribution.) But --depth 1 should work around this. -- ciao, Marco signature.asc Description: PGP signature
Re: Representing Debian Metadata in Git
On 2024-08-20 15:10, Simon Richter wrote: (...) > Right now, git is used mainly as a network file system, and only tagged > releases are expected to be consistent enough to compile, because often > going from one consistent state to another as an atomic operation would > require multiple changes to be applied in the same commit. > > The imported archive is represented either directly as a tree (which may > be imported from the upstream project if no files are undistributable > for Debian), or via a mechanism that can reproduce a compressed archive > that is bitwise identical to the upstream release, from a tree and some > additional patch data. > > The patch stack is stored as a set of patches inside a directory, and > rebased using quilt. > > An alternate representation stores the patch stack as a branch that is > rebased using git, and then exported to single files. > > The Debian changelog is stored as a file inside Git, but some automation > exists to update this from Git commit messages. > > Debian changelog entries refer to bugs in the Debian Bug Tracking > system. There is a desire to also incorporate forges (currently, GitLab) > and refer to the forges' issue tracker from commit messages (where the > issue tracker is used for team collaboration, while the Debian BTS is > used for user-visible bugs). > > All of this is very silly, because we're essentially storing metadata as > data because we cannot express in Git what we're actually doing, and the > conflicting priorities people have have led to conflicting solutions. > > I'd like to xkcd 927 this now, and find a common mapping. Here's my very likely very naive 2 cents: we are basically maintaining a fork for each non-native package. Being a fork, a "Debianized" package can also live like other "upstream" forks: with its own branch based on the original, make necessary changes and record them as commits; merge original onto its own branch, dealing with conflicts; maintain its own changelog; rinse and repeat. Debian-specific metadata can be represented structurally in commit messages, or if necessary, (still) in a plain debian/ subdirectory that won't conflict with upstream. Then, > From a requirements perspective, I'd like to be able to > > - express patches as commits: > - allow cherry-picking upstream commits as Debian patches > - allow cherry-picking Debian patches for upstream submission > - generate the Debian changelog from changes committed to Git > - express filter steps for generating the upstream archive(s) from a > tree‑ish and some metadata > - store upstream signatures inside Git > - keep a history of patches, including patches applied to previously > released packages these are naturally met; and (...) > Changes to packaging would still be represented as commit objects > containing a tree, but that tree would contain a special entry for the > "debian" subdirectory that points to the last packaging change. no more needed. > This is very high-level so far, because I'd like to get some feedback > first on whether it makes sense to pursue this further.This would use > up the last unused three-bit object type in Git, so it will have to be > very generic on this side to not block future development -- and it > would require a lot of design effort on the Debian side as well to > hammer out the details. Even less thought out, but probably easier to implement once the design is finished. ;) -- Sdrager, Blair Noctis pgpKPKc_MGGaO.pgp Description: OpenPGP digital signature
Re: Representing Debian Metadata in Git
Hi ! Le mercredi 21 août 2024, 23:37:38 CEST Chris Hofstaedtler a écrit : > Hi Simon, > > * Simon Richter [240820 09:11]: > > One of the long-standing issues is that there are multiple ways Debian > > packaging can be represented in a git tree, and none of them are optimal. […] > > Any feelings/objections/missed requirements? > > In the current DEP14/DEP18 discussions a lot of discussion was had > about how we should represent Debian things in git; your mail also > goes into this direction. In the Qt/KDE Team (~600-700 source packages) we’ve taken the complete opposite approach. We keep debian/ only repos in salsa and don’t put the upstream source in git anywhere, only in the uploads to the archive. Updating a package to a new upstream version is then as simple as a new changelog entry, and uscan / dpkg-builpackage / sbuild handle the rest for us. I personally think it’s crazy / not a good use of my time to try and mix both upstream and packaging history in the same repo and try to make git dance around that when handling new upstream releases. The extents of the ongoing d-devel discussions on the topic tend to reinforce that feeling. Keeping debian and upstream changes separate is a nice feature. I’d even qualify the debian-only workflow as essential for packages with large source trees like Qt WebEngine that embeds Chromium. The source-included workflows add orders of magnitude of overhead in this kind of situation. (For some value of $fun, try cloning the mesa or Firefox repos from a sloppy Internet connection for a packaging analysis or an occasional contribution.) Happy hacking, -- Aurélien
Re: Representing Debian Metadata in Git
On 2024-08-21 19:11:40 -0400 (-0400), rsbec...@nexbridge.com wrote: [...] > On the other side (perhaps), git is increasingly being used in the > Ops setting for DevOps and DevSecOps. Production configurations > for high-value applications are moving to storing those > configurations into git for tracing and audit. Git is an enabler > for good production operations practices. My $0.02 (and my > customers') This is nothing new though. Long before Git existed, before people started using terms like DevOps, it was fairly typical for sysadmins (that's what we called ourselves back then) to track the entirety of /etc in RCS. Yes having an auditable change history for your configuration is useful, but Git didn't invent that. Git has merely supplanted all prior version control systems, for this use case as well as others. -- Jeremy Stanley signature.asc Description: PGP signature
Re: Representing Debian Metadata in Git
* rsbec...@nexbridge.com [240822 01:21]: > >> Any feelings/objections/missed requirements? > > > >In the current DEP14/DEP18 discussions a lot of discussion was had about how > >we > >should represent Debian things in git; your mail also goes into this > >direction. > > > >My *feeling* is we should do the opposite - that is, represent less Debian > >stuff in git, > >and especially do it in less Debian-specific ways. IOW, no git extensions, > >no setup > >with multiple branches that contain more or less unrelated things, etc. >[..] > On the other side (perhaps), git is increasingly being used in the Ops > setting for > DevOps and DevSecOps. Production configurations for high-value applications > are > moving to storing those configurations into git for tracing and audit. Git is > an > enabler for good production operations practices. Don't get me wrong. Yes, we should use git to do what git is good for (tracking changes, etc). We should not invent new ways of using git that no one else uses. I'd like to reduce the delta of "how Debian uses git" to "how everyone else uses git" to, hopefully, zero. Chris
RE: Representing Debian Metadata in Git
On Wednesday, August 21, 2024 5:38 PM, Chris Hofstaedtler wrote: >* Simon Richter [240820 09:11]: >> One of the long-standing issues is that there are multiple ways Debian >> packaging can be represented in a git tree, and none of them are optimal. >[..] >> A possible implementation would be a type of Git "user extension" >> object that contains >> >> - an extension name >> - an object type (interpreted by the extension) >> - type-tagged references to other objects >> - other type-tagged data >[..] > >> Any feelings/objections/missed requirements? > >In the current DEP14/DEP18 discussions a lot of discussion was had about how we >should represent Debian things in git; your mail also goes into this direction. > >My *feeling* is we should do the opposite - that is, represent less Debian >stuff in git, >and especially do it in less Debian-specific ways. IOW, no git extensions, no >setup >with multiple branches that contain more or less unrelated things, etc. > >I think we should move more towards a setup that is easily understood by people >not closely following our Debian-specific things. We should avoid surprising >things, >again that would include the multiple branches and any git extensions. > >Before pushing for new ways of representing Debian stuff in git, I think it >would be a >good idea to learn from all the other distros and distro-like systems >successfully >using git [1]. Debian is not the only distro that wants to use git to capture >changes >and encourage contributions to its packages. On the other side (perhaps), git is increasingly being used in the Ops setting for DevOps and DevSecOps. Production configurations for high-value applications are moving to storing those configurations into git for tracing and audit. Git is an enabler for good production operations practices. My $0.02 (and my customers') --Randall
Re: Representing Debian Metadata in Git
Chris Hofstaedtler writes: > My *feeling* is we should do the opposite - that is, represent less > Debian stuff in git, and especially do it in less Debian-specific > ways. IOW, no git extensions, no setup with multiple branches that > contain more or less unrelated things, etc. +1 I think this is particularly important for attracting new contributors and easing the onboarding process. There are a lot of odd Debian-specific things that people have to learn because they're necessary to make Debian work. I am dubious that the Git representation is one of them, and would rather continue down the path of providing Debian tools and processes that reduce the delta between how Debian packaging uses Git and how most free software development uses Git. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
Re: Representing Debian Metadata in Git
Hi Simon, * Simon Richter [240820 09:11]: > One of the long-standing issues is that there are multiple ways Debian > packaging can be represented in a git tree, and none of them are optimal. [..] > A possible implementation would be a type of Git "user extension" object > that contains > > - an extension name > - an object type (interpreted by the extension) > - type-tagged references to other objects > - other type-tagged data [..] > Any feelings/objections/missed requirements? In the current DEP14/DEP18 discussions a lot of discussion was had about how we should represent Debian things in git; your mail also goes into this direction. My *feeling* is we should do the opposite - that is, represent less Debian stuff in git, and especially do it in less Debian-specific ways. IOW, no git extensions, no setup with multiple branches that contain more or less unrelated things, etc. I think we should move more towards a setup that is easily understood by people not closely following our Debian-specific things. We should avoid surprising things, again that would include the multiple branches and any git extensions. Before pushing for new ways of representing Debian stuff in git, I think it would be a good idea to learn from all the other distros and distro-like systems successfully using git [1]. Debian is not the only distro that wants to use git to capture changes and encourage contributions to its packages. Chris [1] alpine, homebrew, freebsd ports come to mind immediately. nixos and others too.
Re: The end of 32-bit PostgreSQL support in Debian
Re: Simon Richter > That is not a 32 bit bug, but an indication of something else being broken. It is the same problem in the sense that 64-bit architectures are fine, and something (probably in some autoconf script) is broken on 32-bit. The point here is that these are always weird bugs in weird places that upstream doesn't see because they aren't on 32-bit, and wasting maintainer time here doesn't pay off because there are no users on 32-bit. It's likely just a 1-line fix, but finding that one line would take at least 30min. Christoph
Re: The end of 32-bit PostgreSQL support in Debian
Hi, On 8/21/24 18:32, Christoph Berg wrote: 10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have ‘const char *(const char *, int)’ 10:39:04 409 | strchrnul(const char *s, int c) 10:39:04 | ^ 10:39:04 In file included from snprintf.c:43: 10:39:04 /usr/include/string.h:286:14: note: previous declaration of ‘strchrnul’ with type ‘char *(const char *, int)’ 10:39:04 286 | extern char *strchrnul (const char *__s, int __c) 10:39:04 | ^ Erm, that's a different class of bug: for some reason, strchrnul() is defined as returning a pointer to a non-const char, but this pointer is derived from the pointer to const char passed in. The extension for some reason provides its own variant (probably a bug in a configure script) instead of using the glibc version. That is not a 32 bit bug, but an indication of something else being broken. Simon
Re: The end of 32-bit PostgreSQL support in Debian
Re: To debian-devel > it has probably been a decade since I've last seen a PostgreSQL > installation in the wild on a 32-bit machine. PostgreSQL itself works > fine there, but more and more extensions are not compatible anymore, > either deliberately, or (more common) because of subtle bugs in printf > patterns, double precision values not fitting in a PG Datum, or other > porting problems. Each time this happens, someone has to go digging > what's wrong this time, while in reality, there are likely no users at > all for this PG extension on 32-bit architectures. A new example for this has just arrived, in pgpool2 4.5.3: https://pgdgbuild.dus.dg-i.net/job/pgpool2-binaries/architecture=i386,distribution=sid/130/console 10:39:04 snprintf.c:409:1: error: conflicting types for ‘strchrnul’; have ‘const char *(const char *, int)’ 10:39:04 409 | strchrnul(const char *s, int c) 10:39:04 | ^ 10:39:04 In file included from snprintf.c:43: 10:39:04 /usr/include/string.h:286:14: note: previous declaration of ‘strchrnul’ with type ‘char *(const char *, int)’ 10:39:04 286 | extern char *strchrnul (const char *__s, int __c) 10:39:04 | ^ 64-bit builds are fine. So we'll definitely proceed with removing 32-bit extensions. Christoph
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
On Mon, 19 Aug 2024 at 22:42:53 -0700, Otto Kekäläinen wrote: > ## How many packages have a 'upstream-vcs-tag' and what is it typically? Unlike most of the other questions you asked and answered (thanks!) we should never expect this to be consistent, because it isn't Debian's decision: it's upstream's decision what they will name their tags. The only decision we can make here as Debian packagers is whether to use: 1. a workflow where upstream/latest contains the same commits as upstream git (like src:mesa); 2. a workflow where upstream/latest contains imported tarball snapshots, *without* upstream git history merged in (like src:libsdl2); 3. a workflow where upstream/latest contains imported tarball snapshots *with* upstream git history merged in, most likely via upstream-vcs-tag (like src:glib2.0) and the total number of upstream-vcs-tag is effectively counting (3.) (and possibly some of (1.)). I'm surprised the number your statistics give for (3.) is such a small proportion: I find this workflow really useful as a way to reconcile devref 6.8.8.1's assertion that pristine upstream tarballs are important with the desire to have upstream git history readily available to make maintenance easier. The main reason I don't use upstream-vcs-tag in all the packages I maintain[1] is that some upstreams have non-DFSG or not-obviously-DFSG content in their VCS, and as a project we can be very uncompromising about the application of the DFSG, so using a non-ideal workflow is less of a concern to me than the prospect that the project might decide that the upstream VCS is insufficiently Free and demand that the packaging history is destroyed and re-created. smcv [1] other than the usual exceptional cases like packages not maintained in git upstream, or very large data packages
Representing Debian Metadata in Git
Hi, there's a bit of a discussion within Debian on collaborating using Git. One of the long-standing issues is that there are multiple ways Debian packaging can be represented in a git tree, and none of them are optimal. The problem at hand is that the packaging workflow consists of 1. importing an upstream release 2. optionally stripping out undistributable parts 3. adding packaging metadata 4. optionally adding a patch stack The workflow for upgrading a package is 1. import a new upstream release 2. apply and possibly modify the exclusion list 3. apply the packaging metadata, updating it in the process 4. rebase the patch stack Right now, git is used mainly as a network file system, and only tagged releases are expected to be consistent enough to compile, because often going from one consistent state to another as an atomic operation would require multiple changes to be applied in the same commit. The imported archive is represented either directly as a tree (which may be imported from the upstream project if no files are undistributable for Debian), or via a mechanism that can reproduce a compressed archive that is bitwise identical to the upstream release, from a tree and some additional patch data. The patch stack is stored as a set of patches inside a directory, and rebased using quilt. An alternate representation stores the patch stack as a branch that is rebased using git, and then exported to single files. The Debian changelog is stored as a file inside Git, but some automation exists to update this from Git commit messages. Debian changelog entries refer to bugs in the Debian Bug Tracking system. There is a desire to also incorporate forges (currently, GitLab) and refer to the forges' issue tracker from commit messages (where the issue tracker is used for team collaboration, while the Debian BTS is used for user-visible bugs). All of this is very silly, because we're essentially storing metadata as data because we cannot express in Git what we're actually doing, and the conflicting priorities people have have led to conflicting solutions. I'd like to xkcd 927 this now, and find a common mapping. From a requirements perspective, I'd like to be able to - express patches as commits: - allow cherry-picking upstream commits as Debian patches - allow cherry-picking Debian patches for upstream submission - generate the Debian changelog from changes committed to Git - express filter steps for generating the upstream archive(s) from a tree‑ish and some metadata - store upstream signatures inside Git - keep a history of patches, including patches applied to previously released packages A possible implementation would be a type of Git "user extension" object that contains - an extension name - an object type (interpreted by the extension) - type-tagged references to other objects - other type-tagged data Validity of the object would be determined by the extension, and git would treat this object as mostly opaque (i.e. whenever one is encountered, the extension needs to be called). The only exception would be references, because we need to be able to transfer these objects and all their dependencies efficiently (so the extension would generate a list of references that should be recursively packed or omitted). On top of that, we could represent a Debian package through special objects, such as - debian::debian-dir (a tree-like object referenced from the root tree, contains a tree for plain files plus links to special objects for generated items, such as patch stacks) - debian::upstream-archive (a tree-like object that marks the boundary between objects imported from upstream, and objects that are part of packaging, and gives instructions for regenerating the upstream archives without storing them as blobs) - debian::update-upstream (a commit-like object to move to a new upstream-archive object, this contains the upstream version number that the following upload object must use) - debian::changelog-entry (a commit-like object that adds an item to the Debian changelog) - debian::upload (a commit-like object that adds a version to the Debian changelog) - debian::rebase-patches (a commit-like object that links the patch stacks before and after a rebase) - ... Changes to packaging would still be represented as commit objects containing a tree, but that tree would contain a special entry for the "debian" subdirectory that points to the last packaging change. This is very high-level so far, because I'd like to get some feedback first on whether it makes sense to pursue this further. This would use up the last unused three-bit object type in Git, so it will have to be very generic on this side to not block future development -- and it would require a lot of design effort on the Debian side as well to hammer out the details. Any feelings/objections/missed requirements? Simon
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
Hi!
## How many source packages are in Debian unstable as of today?
± zgrep "^Package: " Sources.gz | wc -l
38199
## How many source packages have a gbp.conf?
± ls -1 *_gbp.conf | wc -l
13570
(24629 do not have it)
## What is the most popular 'debian-branch'?
Note! The Sources.gz used to analyze this was from Debian unstable so
one would not expect to see any debian/bookworm or debian/12-bookworm
kind of lines here.
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^debian-branch( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c | sort
-nr
2284 debian/master
1898 debian/sid
1655 debian/latest
990 master
520 debian
304 debian/unstable
179 debian/main
156 main
133 debian-sid
28 debian/experimental
24 unstable
20 debian-unstable
12 experimental
5 debian-experimental
4 latest
3 sid
2 llvm18/main
2 llvm17/main
2 llvm16/main
2 llvm15/main
2 llvm14/main
2 debian-pkg
2 deb
## What is the most popular 'upstream-branch'?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^upstream-branch( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c | sort
-nr
1846 upstream/latest
1488 upstream
220 master
130 upstream-sid
47 upstream/master
30 main
15 upstream-unstable
14 upstream/sid
10 master-dfsg
9 there-is-no-upstream-branch
6 dfsg
5 release
4 upstream-experimental
4 dfsg-orig
3 upstream-tarball
3 upstream-release
3 upstream-dfsg
3 invalid
3 dfsg_clean
3 debian-upstream
## What is the most popular 'upstream-tag' format?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^upstream-tag( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c | sort
-nr
943 upstream/%(version)s
350 v%(version)s
267 %(version)s
23 'v%(version)s'
11 '%(version)s'
9 upstream/v%(version)s
4 version/%(version)s
4 'upstream/%(version)s'
3 upstream-tarball/v%(version)s
3 snapshot-%(version)s
3 release-%(version)s
2 v%(version%~%-)s
2 version_%(version)s
2 upstream/%(version)s+dfsg
2 release/v%(version)s
## How many packages have a 'upstream-vcs-tag' and what is it typically?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^upstream-vcs-tag( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c |
sort -nr
214 %(version)s
187 v%(version)s
156 %(version%~%.)s
126 %(version%~%-)s
52 v%(version%~%-)s
19 v%(version%~%.)s
8 release/%(version)s
5 release/%(version)s/final
3 release-%(version)s
2 v-%(version)s
2 rel-%(version)s
2 gnupg-%(version)s
## How many packages have 'pristine-tar'?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^pristine-tar( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c | sort
-nr
9098 True
508 False
169 true
46 false
3 1
## How many packages have 'upstream-signatures'?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^upstream-signatures( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c |
sort -nr
7 on
6 True
2 auto
## How many packages have 'sign-tags'?
± grep --no-filename --only-matching --max-count=1 --perl-regex
"^sign-tags( )?=( )?\K([^ ]*)" *gbp.conf | sort | uniq -c | sort -nr
2587 True
55 true
9 False
## Which lines in gbp.conf in general are most common?
± cat *_gbp.conf | sort | uniq -c | sort -nr
13032 [DEFAULT]
10116
8450 pristine-tar = True
2746 [import-orig]
2553 sign-tags = True
1771 debian-branch = debian/sid
1734 upstream-branch = upstream/latest
1731 [buildpackage]
1547 dist = DEP14
1527 debian-branch = debian/latest
1446 debian-branch = debian/master
1307 upstream-branch = upstream
1117 [dch]
1059 patch-numbers = False
987 filter = [ '.gitignore', '.travis.yml', '.git*' ]
967 [pq]
873 debian-branch = master
870 upstream-tag = upstream/%(version)s
771 debian-branch=debian/master
729 # Configuration file for git-buildpackage and friends
691 pristine-tar=True
678 multimaint-merge = True
604 debian-tag = debian/%(version)s
526 filter = */.git*
501 pristine-tar = False
489 filter=[ '.gitignore', '.travis.yml', '.git*' ]
466 debian-branch = debian
436 filter-pristine-tar = True
369 compression = xz
360 # Always use pristine-tar.
In the light of these stats I am fine with current version of the
DEP-14 text, and I am happy with what I settled on in my packages, in
particular the most complex one
(https://salsa.debian.org/mariadb-team/mariadb-server/-/blob/debian/latest/d
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
For those playing along at home... On 19/08/2024 14:53, Stuart Prescott wrote: url=$(curl -s https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r .raw_url) The API URL should obviously be https://sources.debian.org/api/src/$pkg/latest/debian/gbp.conf/ and curl will also need -L to follow the redirect from 'latest' to the specific version: url=$(curl -sL https://sources.debian.org/api/src/$pkg/latest/debian/gbp.conf/ | jq -r .raw_url) -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
Hi Otto Getting the list of source packages with a particular file in them can be done by apt-file (see "--index-names dsc"). sources.debian.org can provide single files - you need an API call to find the correct URL for the file first. I don't know if the service admins would get upset at 1655 files being downloaded in the following fashion. apt-file search --index-names dsc --package-only debian/gbp.conf | while read pkg; do echo -n $pkg url=$(curl -s https://sources.debian.org/api/src/zzuf/0.15-4/debian/gbp.conf/ | jq -r .raw_url) curl -s https://sources.debian.org/$url > $pkg echo . done (takes 1-2s per source package it seems) sources.d.o can also do lookups by file sha256sum. The simple 2-line gbp.conf that sets debian/master is in 183 source packages according to: https://sources.debian.org/api/sha256/?checksum=c4a26b58ec236eab6919435af0267c29840191a97beeb3caa4712e42a6d51be8 which might permit some pre-filtering of the list of packages to inspect. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Re: debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
Quoting Otto Kekäläinen (2024-08-19 03:45:37) > I tried to use codesearch.debian.net to find out how many packages have a > debian/gbp.conf but it seems it can't be used to simply list packages that > have a specific file, it always also needs a search terms to look up inside > the file. > > With > https://codesearch.debian.net/search?q=path%3Adebian%2Fgbp.conf+debian-branch+%3F%3D+%3Fdebian%2Flatest&literal=0 > I was able to find that 1655 packages have either "debian-branch = > debian/latest" or "debian-branch=debian/latest". > > Is there some easy way to iterate every single Debian package and > extract just one single file from them without having to download all > packages? > > I'd like to see how many % of all Debian packages have a gbp.conf file, and > then download all of them to do stats on what they contain. finding out which package contains a given file is better done via the Contents files from our mirrors. The apt-file tool provides an easy interface to search these contents files and answer the question "which package contains a file or path that looks like this". By default, apt-file will only download (and search) Contents files for binary packages and not source packages. To change that, edit /etc/apt/apt.conf.d/50apt-file.conf and change DefaultEnabled from "false" to "true" in the section deb-src::Contents-dsc. Once that is done you run "apt update" to download the newly enabled Contents files and then you can run a search like this: $ apt-file --index-names dsc search debian/gbp.conf You need to add --index-names because the default value is "deb" and that would only search through binary packages. Thanks! cheers, josch signature.asc Description: signature
debian/gbp.cnf analytics? (Re: Re: Accepting DEP14?)
Hi! I am happily using debian/gbp.conf and debian-branch=debian/latest in all of my packages but based on the DEP14 discussion seems some people prefer debian/sid or debian/unstable (and some of them upload to experimental from the branch despite the name, and some maintain a separate debian/experimental branch for experimental uploads). However this the responses are just a sample based on who happens to have time to read debian-devel@ discussions. I tried to use codesearch.debian.net to find out how many packages have a debian/gbp.conf but it seems it can't be used to simply list packages that have a specific file, it always also needs a search terms to look up inside the file. With https://codesearch.debian.net/search?q=path%3Adebian%2Fgbp.conf+debian-branch+%3F%3D+%3Fdebian%2Flatest&literal=0 I was able to find that 1655 packages have either "debian-branch = debian/latest" or "debian-branch=debian/latest". Is there some easy way to iterate every single Debian package and extract just one single file from them without having to download all packages? I'd like to see how many % of all Debian packages have a gbp.conf file, and then download all of them to do stats on what they contain. - Otto
The end of 32-bit PostgreSQL support in Debian
Hi debian-devel, it has probably been a decade since I've last seen a PostgreSQL installation in the wild on a 32-bit machine. PostgreSQL itself works fine there, but more and more extensions are not compatible anymore, either deliberately, or (more common) because of subtle bugs in printf patterns, double precision values not fitting in a PG Datum, or other porting problems. Each time this happens, someone has to go digging what's wrong this time, while in reality, there are likely no users at all for this PG extension on 32-bit architectures. Hence, we would like to stop building PG extensions on 32-bit architectures. The server packages will still build, but extension packages will be restricted to 64-bit architectures. (If the server starts to break as well, we could strip down the PG packages to provide libpq5.deb and friends only.) I haven't yet decided whether to extend that to PG applications, but this would likely be the preferred fix for anything 32-bit related in case of problems. apt.postgresql.org has already stopped building 32-bit packages for all releases past past buster, and in the years since then, I've only received a single question about that. (Which wasn't a user but the pgbackrest upstream trying to test their software against 32-bit, so with the same problem.) On pgsql-pkg-debian I proposed this plan: * Remove buster-pgdg from apt.pg.o (buster-lts was EOLed last month) * Remove i386 from sid-pgdg (packages are still preserved on apt-archive.postgresql.org) * Upload postgresql-17 to Debian unstable, with all architectures supported [*] (once rc1 is there) * When re-uploading all extensions to Debian to transition them from 16 to 17, disable extensions on 32-bit archs. Adding this should do the trick: Build-Depends: architecture-is-64-bit , That way, people could still build extension packages manually if they really wanted (dpkg-buildpackage -Ppkg.postgresql.32-bit). * Remove postgresql-16 from unstable Comments? Christoph [*] On a side note, 32-bit powerpc did actually start to break: https://buildd.debian.org/status/logs.php?pkg=postgresql-17&ver=17%7Ebeta2-1&arch=powerpc I told the package to ignore the regression test results there with the next postgresql-common upload: https://salsa.debian.org/postgresql/postgresql-common/-/commit/593fa32fa0c6d2a963a7b3b514d1d6a2423ef534 signature.asc Description: PGP signature
Packages "confirmed" and ready for DD review/possible upload - Debian Mentors - 2024-08-15
Dear all DDs, Below is the link to the page of currently "confirmed" being in good order packages that are awaiting a DD review and possible upload. If DDs could spare the time to pick up a package or two and finish off the package mentor process it would be greatly appreciated. https://bugs.debian.org/cgi-bin/pkgreport.cgi?include=tags%3Aconfirmed;package=sponsorship-requests Please check that another DD is not already involved in the package. Regards Phil -- "I play the game for the game’s own sake" Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans -- Buy Me A Coffee: https://buymeacoffee.com/kathenasorg Internet Relay Chat (IRC): kathenas Matrix: #kathenas:matrix.org Website: https://kathenas.org Instagram: https://instagram.com/kathenasorg/ Threads: https://www.threads.net/@kathenasorg -- signature.asc Description: This is a digitally signed message part
Re: Moving libdeflate from Debian-Med to a more appropriate team
On 08/08/2024 07.02, nick black wrote: Michael R. Crusoe left as an exercise for the reader: Please create a new group on salsa and then we can move the repo[0] from the debian-med namespace. done: https://salsa.debian.org/deflate-team Thank you Nick, I've moved the libdeflate Salsa repo from the Debian-Med namespace to that one: https://salsa.debian.org/deflate-team/libdeflate Anyone else who is interested in volunteering, please contact Nick and Andrea. Thanks again! OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Moving libdeflate from Debian-Med to a more appropriate team
Michael R. Crusoe left as an exercise for the reader: > Please create a new group on salsa and then we can move the repo[0] from the > debian-med namespace. done: https://salsa.debian.org/deflate-team I've sent invites to you and Andrea. Feel free to ignore them. > Then you can formalize the change by uploading the new version[1] of > libdeflate with the new "Maintainer". > [1] https://github.com/ebiggers/libdeflate/releases/tag/v1.21 on it. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
[resending to your correct address] Hello, On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote: > It's similar but different: I'm talking about workflows to build a package > from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). > And yeah it could be a metadata field. Just to note that once people are using tag2upload, this information will start being recorded on salsa, as a side-effect. I've filed #1078016 about exposing this information in a machine-readable way. -- Sean Whitton
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote: > It's similar but different: I'm talking about workflows to build a package > from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). > And yeah it could be a metadata field. Just to note that once people are using tag2upload, this information will start being recorded on salsa, as a side-effect. I've filed #1078016 about exposing this information in a machine-readable way. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote: > 1. Debian workflows are too fractured. The project would be better if we > asked people > to standardize around a single (or a small number) of workflows. To do so, > the workflow > would need to be flexible enough to handle the wide range of technical needs > of all the > packages and upstream configurations. > > 2. Standardizing around a single (or small number of) workflows will make > some people > unhappy. But that is an acceptable price to pay because of the general > benefit to the > project as long as the correct solution is adopted. Unity is more important > than minority > opinions on this particular issue. > > 3. I do not yet have the wisdom to ascertain what the correct solution is. > Until I do, I > applaud those who attempt to push this discussion forward, and I follow it > closely, but I > haven’t commented. I think adopting an incorrect mandated (or maybe even > recommended) workflow is worse than the fractured status quo. We need to distinguish different workflows or workflow stages. There is the git hosting workflow -- gitlab vs. github vs. personal server. This seems solely about what people like to use. I agree with you that we should probably pick just one of these -- not even a small number. But there is also the git->dsc workflow -- gbp vs. dpm vs. debrebase vs. debcherry. The crucial difference is that in this area it's not just personal preferences, but that different packages have different needs. A small Python library is vastly different to, say, SBCL or Xen. My two favourite git->dsc workflows are documented in dgit-maint-merge(7) and dgit-maint-rebase(7). These manpages include some explanations as to what sort of packages are best suited to each of them. -- Sean Whitton signature.asc Description: PGP signature
Re: Moving libdeflate from Debian-Med to a more appropriate team
On 06/08/2024 20.36, Andrea Pappacoda wrote: Il giorno mar 6 ago 2024 alle 11:32:15 -04:00:00, nick black ha scritto: I maintain it for Fedora, and would be happy to handle it in Debian; it's a dependency for one of my other packages (notcurses). Happy to enter into a team maintainership as well. Hi Nick and Michael, I'd be happy to join this hypothetical team as well. I already maintain multiple C++/CMake packages, and I'm looking into using libdeflate in Pistache, a library which I maintain both upstream and in Debian. Thank you Andrea and Nick for volunteering! Please create a new group on salsa and then we can move the repo[0] from the debian-med namespace. Then you can formalize the change by uploading the new version[1] of libdeflate with the new "Maintainer". [0] https://salsa.debian.org/med-team/libdeflate [1] https://github.com/ebiggers/libdeflate/releases/tag/v1.21 OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 09:19am +02, PICCA Frederic-Emmanuel wrote: > Hello, I like the dgit idea, produce a git repository for people who want to > use git and let other use whatever they want. > > Maybe uploading a paquage to Debian could push automatically into dgit. (maybe > this is already the case) If the upload is done with dgit or tag2upload this is already the case. For other uploads, 'dgit clone' constructs the dgit view on-the-fly. We could consider having this done in advance. It would make 'dgit clone much faster' and it would enable importing into salsa as you also suggest. -- Sean Whitton signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, On Sat 03 Aug 2024 at 08:26am +02, Jonas Smedegaard wrote: > My problem with DEP-18 is that people who have zero problem with using > git and are also not fundamentally against using salsa, but have > reservations surrounding *which parts* of salsa to use and the > consequences for related already used tooling. This describes me. I use and am enthusiastic about git, and when the workflow is not obvious from team policy or whatever, I document it in README.source. I took time to write up the complex workflow emacs.git uses (not developed by me) precisely so that more people could become involved. I am happy to use salsa for git hosting and access management. I love that I can easily grant push access to my non-DD team members. But, I turn off salsa MRs for the repos of all packages I regularly upload. I would hope that this DEP can be written such as to account for these sorts of choices. -- Sean Whitton
Re: Moving libdeflate from Debian-Med to a more appropriate team
Il giorno mar 6 ago 2024 alle 11:32:15 -04:00:00, nick black ha scritto: I maintain it for Fedora, and would be happy to handle it in Debian; it's a dependency for one of my other packages (notcurses). Happy to enter into a team maintainership as well. Hi Nick and Michael, I'd be happy to join this hypothetical team as well. I already maintain multiple C++/CMake packages, and I'm looking into using libdeflate in Pistache, a library which I maintain both upstream and in Debian. Bye!
Re: Moving libdeflate from Debian-Med to a more appropriate team
Michael R. Crusoe left as an exercise for the reader: > libdeflate-dev has 3304 reverse-dependencies in "unstable"[0]. > I would like to move it from Debian-Med to a more appropriate team. > Are there any volunteers? I maintain it for Fedora, and would be happy to handle it in Debian; it's a dependency for one of my other packages (notcurses). Happy to enter into a team maintainership as well. -- nick black -=- https://nick-black.com to make an apple pie from scratch, you need first invent a universe. signature.asc Description: PGP signature
Moving libdeflate from Debian-Med to a more appropriate team
libdeflate-dev has 3304 reverse-dependencies in "unstable"[0]. I would like to move it from Debian-Med to a more appropriate team. Are there any volunteers? Some history: libzstd-dev (3020 reverse build-depends) was also first packaged by Debian-Med but is now under the RPM packaging team. liblzma-dev (from xz-utils, 4381 reverse build-depend) has never been under team maintainership as far as I can tell. Thanks! [0] According to `build-rdeps --distribution unstable libdeflate-dev` -- Michael R. Crusoe OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 05/08/2024 10:40, Simon Richter ha scritto: Hi, On 8/5/24 17:10, Fabio Fantoni wrote: currently you find such information from a simple search and/or looking a bit in the source, in the possible git in a few minutes only in part of cases, in many other cases instead it requires more time, the possible contact of the maintainer, attempts (and then eventually feel that it would be better to "improve" your contributions using other methods). This information should be in debian/README.source. Simon debian/README.source can be used for that, this according to the current documentation does partially that, make it standard also for other parts mentioned, more known thing and change/improve the documentation, for example in https://www.debian.org/doc/debian-policy/ch-source.html#source-package-handling-debian-readme-source as at the moment reading at the beginning it leaves to understand to a restricted use of it, can be an improvement with minimal effort. for example also in the end of it description have: |debian/README.source| may also include any other information that would be helpful to someone modifying the source package. Even if the package doesn’t fit the above description, maintainers are encouraged to document in a |debian/README.source| file any source package with a particularly complex or unintuitive source layout or build system (for example, a package that builds the same source multiple times to generate different binary packages). that it may suggest a greater use than what I saw and remembered but at least something like this should be put at the beginning of the description: "debian/README.source may include any information that would be helpful to someone modifying the source package and how to contribute to it" could suggest to optionally add other parts on how to contribute that have been discussed, to insert any external links where to find the information (in order to update a single page/file even for a big amount of packages, but leaving README.source unchanged, so I guess it would be much more used thanks to less effort from the maintainers) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi, On 8/5/24 17:10, Fabio Fantoni wrote: currently you find such information from a simple search and/or looking a bit in the source, in the possible git in a few minutes only in part of cases, in many other cases instead it requires more time, the possible contact of the maintainer, attempts (and then eventually feel that it would be better to "improve" your contributions using other methods). This information should be in debian/README.source. Simon
Machine readable contributor information (was: Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages)
Fabio Fantoni: Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto: [...] Thanks for reply, what I mean is precisely a standard field that points to a file, inside the package or even an url as already explained can be very useful in most cases) that contains all the useful information for contributing to that package, including the one you mention. even if everyone applied DEP-14 and DEP-18 there would be some differences that could be useful to know in a simple and immediate way. and I think this is even more useful with the current situation and also very useful in case of any future migrations to more standardized systems. currently you find such information from a simple search and/or looking a bit in the source, in the possible git in a few minutes only in part of cases, in many other cases instead it requires more time, the possible contact of the maintainer, attempts (and then eventually feel that it would be better to "improve" your contributions using other methods). a single standard field (to be added optionally) and adding links to that file or url in the tracker (if present) I think would bring advantages and save time for both contributors and maintainers in many cases (when used) If we go down this route, could we consider making it machine readable (in parallel with human readable)[0]. For people doing drive-by nmu/patches across many packages, having to manual open link and read policies can often take considerable time. It is the small things really like: * Does this package use `gbp dch` (or some other mechanisms) to generate the changelog OR should I include a changelog entry with my patch. * Does this package use some form of automatic formatting that I should apply when I do my changes (if `wrap-and-sort`, then which options)? * Does the maintainer prefer MR via salsa or BTS with patches for when I want to submit my changes for review. (I get this is the DEP-18 thread and the answer should be "MR via salsa", but then DEP-18 is opt-in, which means it might not be "MR via salsa" after all) * Does the maintainer prefer dgit and if so, which of its 5+ different documented workflows should I follow? (Like how does it manage patches git-wise) * Etc. And yet we do not have good answers for these kind of questions in an automated fashion. I am happy to work on the client side of this problem. I already took a stab at something similar (see [1], currently stuck on getting a single source of truth data source), so it would fit into the work I am doing anyway. Best regards, Niels [0]: I mean a dedicated `JSON` or `YAML` file in parallel to the human policy. Shenanigans like parsing special statements from formats aimed at humans do not really cut it in my book. [1]: https://salsa.debian.org/debian/debputy/-/merge_requests/37
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto: On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote: Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto: On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: one problem I have with NMUs in team-maintained package is that they often bypass Salsa… Would it make sense to add to the DEP a request that NMUs are started from and pushed to the default branch? Only if DEP-18 also includes an easy way to find the workflow used by the repo, which I'm not seeing there (which may be my fault). something like wrote here can help for you? https://lists.debian.org/debian-devel/2024/08/msg00058.html https://lists.debian.org/debian-devel/2024/08/msg00062.html I think something like this could be useful, even in a possible future where all packages would use git and salsa; but from the answers received so far it seems to be considered a useless thing. I would be curious to know the opinion of more people. It's similar but different: I'm talking about workflows to build a package from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). And yeah it could be a metadata field. Thanks for reply, what I mean is precisely a standard field that points to a file, inside the package or even an url as already explained can be very useful in most cases) that contains all the useful information for contributing to that package, including the one you mention. even if everyone applied DEP-14 and DEP-18 there would be some differences that could be useful to know in a simple and immediate way. and I think this is even more useful with the current situation and also very useful in case of any future migrations to more standardized systems. currently you find such information from a simple search and/or looking a bit in the source, in the possible git in a few minutes only in part of cases, in many other cases instead it requires more time, the possible contact of the maintainer, attempts (and then eventually feel that it would be better to "improve" your contributions using other methods). a single standard field (to be added optionally) and adding links to that file or url in the tracker (if present) I think would bring advantages and save time for both contributors and maintainers in many cases (when used) OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote: > Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto: > > On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > > > one problem I have with NMUs in team-maintained package is that they > > > often bypass Salsa… Would it make sense to add to the DEP a request > > > that NMUs are started from and pushed to the default branch? > > Only if DEP-18 also includes an easy way to find the workflow used by the > > repo, which I'm not seeing there (which may be my fault). > > > something like wrote here can help for you? > > https://lists.debian.org/debian-devel/2024/08/msg00058.html > > https://lists.debian.org/debian-devel/2024/08/msg00062.html > > I think something like this could be useful, even in a possible future where > all packages would use git and salsa; but from the answers received so far > it seems to be considered a useless thing. I would be curious to know the > opinion of more people. It's similar but different: I'm talking about workflows to build a package from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs"). And yeah it could be a metadata field. -- WBR, wRAR signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto: On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: one problem I have with NMUs in team-maintained package is that they often bypass Salsa… Would it make sense to add to the DEP a request that NMUs are started from and pushed to the default branch? Only if DEP-18 also includes an easy way to find the workflow used by the repo, which I'm not seeing there (which may be my fault). something like wrote here can help for you? https://lists.debian.org/debian-devel/2024/08/msg00058.html https://lists.debian.org/debian-devel/2024/08/msg00062.html I think something like this could be useful, even in a possible future where all packages would use git and salsa; but from the answers received so far it seems to be considered a useless thing. I would be curious to know the opinion of more people. OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > one problem I have with NMUs in team-maintained package is that they > often bypass Salsa… Would it make sense to add to the DEP a request > that NMUs are started from and pushed to the default branch? Only if DEP-18 also includes an easy way to find the workflow used by the repo, which I'm not seeing there (which may be my fault). -- WBR, wRAR signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 03, 2024 at 10:37:42PM +0200, Salvo Tomaselli wrote: > > 2. Standardizing around a single (or small number of) workflows will make > > some people unhappy. But that is an acceptable price to pay because of the > > general benefit to the project *as long as the correct solution is > > adopted*. Unity is more important than minority opinions on this > > particular issue. > > Keep in mind that unhappy people quit. Yes, people will resign, but (other) people resign because they got tired of Debian not having standartized workflows, and the "1000 DDs status quo" problem also means that more people leave than join *anyway*. > I don't think that unity is so important that we're willing to sacrifice > project members. Not the unity per se, but having significantly lower barriers to start contributing. -- WBR, wRAR signature.asc Description: PGP signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi all, On 03-08-2024 22:37, Salvo Tomaselli wrote: At the bottom, is it ok for a package to have a single maintainer or not? I have never wanted to be the single maintainer of a package, and here I am, I'm member of a bunch of teams, but most of my packages uploads (not a lot luckily) are for packages that nobody else uploads. The people that believe that package should not be single person maintained, please become co-maintainer of all the packages I list below, you're welcome. In this discussion about single maintainer packages I nearly feel guilty, while at the same time I don't *want* to be the single maintainer. Actually, I don't want to maintain packages at all, my joy is elsewhere in Debian. I'm on LowThresholdNMU and LowThresholdAdoption lists. I guess I should have created a wnpp RFH" bug for all my packages? Not that those really work either (see e.g. #846328, it's still open). So we have established processes, but apparently they don't work as intended. Now we trying to *add* to the set. Maybe we should clean up older processes at the same time because additions just make it even more difficult. XKCD 927 comes to mind [1]. I'm the single maintainer for the following package, only to reflect reality, not because I consider myself "owner". E.g. for years there was a different person in the maintainer field for liferea, but de-facto I was the real maintainer. If people recognize a good team for them, we should make a team maintainer of these: dbconfig-common -> in the debian namespace liferea -> in the debian namespace viking -> in the debian namespace I'm the only member of the teams maintaining: * cacti and cacti-spine -> in the debian namespace (bit complicated packaging due to upstream vendoring stuff; receives quite some CVE's) * siridb, libcleri, qpack, siridb-connector and siridb-admin -> in the siridb-team namespace, but I'd happily move them to the debian namespace if it would help (I don't expect it would, see dbconfig-common, liferea and viking). Feel free to enable all ci pipelines that work for those packages (I couldn't get cacti to build on salsa last time I tried, would love to see that fixed, I now use debomatic to try run builds). I'm not sure if I receive MR message if somebody would try to create one for these packages. Paul [1] https://xkcd.com/927/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi! > I have three feelings. > > > 1. Debian workflows are too fractured. The project would be better if we > asked people to standardize around a single (or a small number) of workflows. > To do so, the workflow would need to be flexible enough to handle the wide > range of technical needs of all the packages and upstream configurations. > > > 2. Standardizing around a single (or small number of) workflows will make > some people unhappy. But that is an acceptable price to pay because of the > general benefit to the project as long as the correct solution is adopted. > Unity is more important than minority opinions on this particular issue. > > > 3. I do not yet have the wisdom to ascertain what the correct solution is. > Until I do, I applaud those who attempt to push this discussion forward, and > I follow it closely, but I haven’t commented. I think adopting an incorrect > mandated (or maybe even recommended) workflow is worse than the fractured > status quo. > > > Number 3 is why I haven’t previously commented. In regards to DEP-18, I > don’t know if it is the correct way to go for many of the criticisms that > have already been expressed. But, if it isn’t DEP-18, I think it will > eventually be something. And, although this might not be a popular opinion > among some, I think Debian should get to the point that there is one workflow > (or a very small number of workflows) that all packages are expected to > follow, both for packaging and for collaboration. Thanks for voicing this! I think a lot of people have the same feeling that if there were a bit more common principles and practices across all packages and maintainers, contributing to multiple different packages would be easier for old maintainers, and learning how to contribute efficiently in the first place would be easier for new maintainers. Also I fully agree that suddenly forcing everybody to do something unpractical would be detrimental to Debian. Therefore the DEP-18 proposal is based on the principles most packages and teams already follow based on trends.debian.net and what I know about e.g. Python, Golang and kernel team policies. There is also no way a volunteer project such as Debian could mandate a two-person-rule as it would instantly grind all single-maintainer packages to a halt. It is and will be OK to have single maintainer packages now and going forward if there is just one person interested in the package. DEP-18 hopefully helps to unify some things and allow for more people to step up and help with packages they have not worked on before, but I intentionally want it to be a fairly soft mechanism, and not overly prescriptive in the details. I also object to having any votes or mandatory rules on this. This is just a DEP on purpose and not a GR. Who knows if a superior alternative to for example git surfaces in the next 15 years. If at that time people *really* want to move away from git they should be allowed to do so and not be prohibited by too strict rules. For the reasons 2 and 3 in Soren's list, let's continue to discuss what are the best practices and principles. I am sure we can eventually get a consensus that suits most people and creates the best environment for easier collaboration.
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Saturday, August 3, 2024 1:37:42 PM MST Salvo Tomaselli wrote: > > 2. Standardizing around a single (or small number of) workflows will make > > some people unhappy. But that is an acceptable price to pay because of the > > general benefit to the project *as long as the correct solution is > > adopted*. Unity is more important than minority opinions on this > > particular issue. > > Keep in mind that unhappy people quit. > > I don't think that unity is so important that we're willing to sacrifice > project members. Yes, but based on my work helping new contributors start working on Debian, I think the number of people the project would gain would far exceed those who would leave. > What exact issue are we trying to fix? The core of the issue is that it is far too hard for a new contributor to figure out how to contribute to Debian, and far too hard for an experienced DD to figure out how to contribute to a package that is based on a workflow with which they are not familiar. > At the bottom, is it ok for a package to have a single maintainer or not? Yes, as I have written elsewhere, I am a proponent of a strong package maintainer orientation. However, even single maintainer packages periodically need input from other developers, either as an NMU or as an adoption or because of a mass bug report or a transition or various other things. Having one workflow that everyone understands is a strong benefit for all packages, whether or not they are team maintained. > If as a project this has to change, I think a vote is warranted. Absolutely. This is such a core aspect of Debian that any changes or mandates would need to involve a vote. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Friday, August 2, 2024 11:26:01 PM MST Jonas Smedegaard wrote: > I imagine that some in the silent crowd hesitate to chime in due to that > lumping together the use of git and the use of Gitlab into an > all-or-nothing choice. I think you intended that reduction, for the > purpose of simplifying the conversation. I don't think that > simplification is helpfull, however. I am one of the silent crowd who has followed this discussion. I have three feelings. 1. Debian workflows are too fractured. The project would be better if we asked people to standardize around a single (or a small number) of workflows. To do so, the workflow would need to be flexible enough to handle the wide range of technical needs of all the packages and upstream configurations. 2. Standardizing around a single (or small number of) workflows will make some people unhappy. But that is an acceptable price to pay because of the general benefit to the project *as long as the correct solution is adopted*. Unity is more important than minority opinions on this particular issue. 3. I do not yet have the wisdom to ascertain what the correct solution is. Until I do, I applaud those who attempt to push this discussion forward, and I follow it closely, but I haven’t commented. I think adopting an incorrect mandated (or maybe even recommended) workflow is worse than the fractured status quo. Number 3 is why I haven’t previously commented. In regards to DEP-18, I don’t know if it is the correct way to go for many of the criticisms that have already been expressed. But, if it isn’t DEP-18, I think it will eventually be something. And, although this might not be a popular opinion among some, I think Debian should get to the point that there is one workflow (or a very small number of workflows) that all packages are expected to follow, both for packaging and for collaboration. -- Soren Stoutner so...@debian.org signature.asc Description: This is a digitally signed message part.
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Fabio Fantoni (2024-08-03 16:45:24) > Il 03/08/2024 15:59, Jonas Smedegaard ha scritto: > > Quoting Fabio Fantoni (2024-08-03 15:39:00) > >> Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: > >>> Hi, > >>> > >>> Even though +1 for DEP-18 basically, I think that it might be better > >>> to add an option > >>> to formalize package owner's (single person maintainer) collaboration > >>> policy > >>> especially about non-team maintained packages under > >>> https://salsa.debian.org/debian/. > >>> > >>> If such a package repository enables merge request feature, then I > >>> will send merge request and > >>> send E-mail to bugs.d.o about url of the MR to notify it. > >>> But it is not true that such MR is merged in timely manner. > >>> (Surely collaboration takes longer time, I know.) > >>> > >>> If the package owner expresses a collaboration policy in advance, it > >>> can improve such a situation > >>> in a particular case and we can respect it. > >>> > >>> NOTE: The following idea might be out-of-scope in DEP-18, but specific > >>> use-case to improve > >>> collaboration in Debian, IMHO. > >>> > >>> Here is just an idea: put collaboration policy metadata in debian/control. > >>> (The following idea assumes that non-maintainer DD tend to hesitate to > >>> commit/merge it) > >>> > >>> * Collaboration-Policy: debian/CONTRIBUTION.md > >>> Yes, we have README.source already, but it might be better to note > >>> in a separate file about collaboration. > >>> * Collaboration-Policy-Commit: yes > >>> It declares that the package owner encourages non-maintainer DD to > >>> commit directly without merge request. > >>> * Collaboration-Policy-Merge: yes > >>> It declares that the package owner encourages non-maintainer DD to > >>> allow merge requests. > >>> (DD has maintainer right in salsa.d.o by default as you know, but > >>> you can merge without worry if there is it.) > >>> * Collaboration-Policy-LowThresholdNmu: yes > >>> It declares that LowThresholdNmu rule [1] is applied. > >>> * Collabollation-Policy-NMU-Delay: 15 > >>> It declares that NMU delay the package owner wants. > >>> > >>> [1] https://wiki.debian.org/LowThresholdNmu > >>> > >>> Pros: > >>> * DD/DM and contributors can respect the package owner's intent about > >>> the package collaboration. > >>> * Reduce a chance to cause inconsistency between the content of each > >>> package repository on salsa.d.o and NMU'ed package source. > >>> * Because other DD (non package owner) can commit/merge, then ship > >>> NMU package. > >>> Cons: > >>> * Maintainers will be bothered to add that new field to every package > >>> (If there is no Collaboration-Policy, it is safe that sending merge > >>> request and let it the package manager, thus nothing changed) > >>> * No mechanism to enforce Collaboration-Policy-Commit: no or > >>> Collaboration-Policy-Merge: no policy > >>> because DD has maintainer rights on salsa.d.o and can commit/merge > >>> it in reality. > >>> > >>> It might worry too much, but it might be able to block an unfortunate > >>> accident, a so-called package hijack > >>> with incomplete communication in some cases. > >> Hi, this I think is can be useful (beyond the example use of > >> salsa/debian packages which is not necessary as replied by Tobias > >> Frost), I think will be better with only one additional (and optional) > >> field in d/control, like Collaboration-Policy that point a file or url, > >> this I think that can decrease the possible annoyance and in the case of > >> teams or even single maintainers having a single policy file to point to > >> and update in a simpler and faster way (especially if there were the > >> same policies for dozens of packages or more, there could be also > >> hundreds or thousands) > > What annoyance are you referring to? > annoyance maintainers for update it on many package, with a url that > point to an external file can be update once for even on tens, hundreds > or more packages it could be set on > > > > Are some new contributors annoyed by the lack of formalized rul
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 03/08/2024 15:59, Jonas Smedegaard ha scritto: Quoting Fabio Fantoni (2024-08-03 15:39:00) Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: Hi, Even though +1 for DEP-18 basically, I think that it might be better to add an option to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/. If such a package repository enables merge request feature, then I will send merge request and send E-mail to bugs.d.o about url of the MR to notify it. But it is not true that such MR is merged in timely manner. (Surely collaboration takes longer time, I know.) If the package owner expresses a collaboration policy in advance, it can improve such a situation in a particular case and we can respect it. NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve collaboration in Debian, IMHO. Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it) * Collaboration-Policy: debian/CONTRIBUTION.md Yes, we have README.source already, but it might be better to note in a separate file about collaboration. * Collaboration-Policy-Commit: yes It declares that the package owner encourages non-maintainer DD to commit directly without merge request. * Collaboration-Policy-Merge: yes It declares that the package owner encourages non-maintainer DD to allow merge requests. (DD has maintainer right in salsa.d.o by default as you know, but you can merge without worry if there is it.) * Collaboration-Policy-LowThresholdNmu: yes It declares that LowThresholdNmu rule [1] is applied. * Collabollation-Policy-NMU-Delay: 15 It declares that NMU delay the package owner wants. [1] https://wiki.debian.org/LowThresholdNmu Pros: * DD/DM and contributors can respect the package owner's intent about the package collaboration. * Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source. * Because other DD (non package owner) can commit/merge, then ship NMU package. Cons: * Maintainers will be bothered to add that new field to every package (If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed) * No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy because DD has maintainer rights on salsa.d.o and can commit/merge it in reality. It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack with incomplete communication in some cases. Hi, this I think is can be useful (beyond the example use of salsa/debian packages which is not necessary as replied by Tobias Frost), I think will be better with only one additional (and optional) field in d/control, like Collaboration-Policy that point a file or url, this I think that can decrease the possible annoyance and in the case of teams or even single maintainers having a single policy file to point to and update in a simpler and faster way (especially if there were the same policies for dozens of packages or more, there could be also hundreds or thousands) What annoyance are you referring to? annoyance maintainers for update it on many package, with a url that point to an external file can be update once for even on tens, hundreds or more packages it could be set on Are some new contributors annoyed by the lack of formalized rules for collaboration? not only new but also any contributors that want to contribute on other package, also about that I tried to explain something in one of my previous mail Are some maintainers annoyed by how some new contributors initiate collaborative contributions? I don't know how likely it is, I hope it's very rare As a maintainer, I can imagine getting annoyed by *non-collaborative* contributions done in ways that I feel leaves an extra burden on me. One description for that is "drive-by contributions", meaning that someone contributes without having the time to *collaborate* on it, to align the contribution with how the package is maintained. But since this whole thread is about "true open collaboration", I assume that you are talking about *collaborative* work, and then I cannot recognize what is the kind of annoyance you are referring to. There is a lot of other information that may vary on how to contribute in certain packages or teams beyond what is already listed, here only some example: Debian Python Team - https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst Java team - https://www.debian.org/doc/packaging-manuals/java-policy/ Rust team - https://wiki.debian.org/Teams/RustPackaging go team - https://go-team.pages.debian.net/packaging.html Kind regards, -
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Fabio Fantoni (2024-08-03 15:39:00) > Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: > > Hi, > > > > Even though +1 for DEP-18 basically, I think that it might be better > > to add an option > > to formalize package owner's (single person maintainer) collaboration policy > > especially about non-team maintained packages under > > https://salsa.debian.org/debian/. > > > > If such a package repository enables merge request feature, then I > > will send merge request and > > send E-mail to bugs.d.o about url of the MR to notify it. > > But it is not true that such MR is merged in timely manner. > > (Surely collaboration takes longer time, I know.) > > > > If the package owner expresses a collaboration policy in advance, it > > can improve such a situation > > in a particular case and we can respect it. > > > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > > use-case to improve > > collaboration in Debian, IMHO. > > > > Here is just an idea: put collaboration policy metadata in debian/control. > > (The following idea assumes that non-maintainer DD tend to hesitate to > > commit/merge it) > > > > * Collaboration-Policy: debian/CONTRIBUTION.md > >Yes, we have README.source already, but it might be better to note > > in a separate file about collaboration. > > * Collaboration-Policy-Commit: yes > >It declares that the package owner encourages non-maintainer DD to > > commit directly without merge request. > > * Collaboration-Policy-Merge: yes > >It declares that the package owner encourages non-maintainer DD to > > allow merge requests. > >(DD has maintainer right in salsa.d.o by default as you know, but > > you can merge without worry if there is it.) > > * Collaboration-Policy-LowThresholdNmu: yes > >It declares that LowThresholdNmu rule [1] is applied. > > * Collabollation-Policy-NMU-Delay: 15 > >It declares that NMU delay the package owner wants. > > > > [1] https://wiki.debian.org/LowThresholdNmu > > > > Pros: > > * DD/DM and contributors can respect the package owner's intent about > > the package collaboration. > > * Reduce a chance to cause inconsistency between the content of each > > package repository on salsa.d.o and NMU'ed package source. > >* Because other DD (non package owner) can commit/merge, then ship > > NMU package. > > Cons: > > * Maintainers will be bothered to add that new field to every package > >(If there is no Collaboration-Policy, it is safe that sending merge > > request and let it the package manager, thus nothing changed) > > * No mechanism to enforce Collaboration-Policy-Commit: no or > > Collaboration-Policy-Merge: no policy > >because DD has maintainer rights on salsa.d.o and can commit/merge > > it in reality. > > > > It might worry too much, but it might be able to block an unfortunate > > accident, a so-called package hijack > > with incomplete communication in some cases. > > Hi, this I think is can be useful (beyond the example use of > salsa/debian packages which is not necessary as replied by Tobias > Frost), I think will be better with only one additional (and optional) > field in d/control, like Collaboration-Policy that point a file or url, > this I think that can decrease the possible annoyance and in the case of > teams or even single maintainers having a single policy file to point to > and update in a simpler and faster way (especially if there were the > same policies for dozens of packages or more, there could be also > hundreds or thousands) What annoyance are you referring to? Are some new contributors annoyed by the lack of formalized rules for collaboration? Are some maintainers annoyed by how some new contributors initiate collaborative contributions? As a maintainer, I can imagine getting annoyed by *non-collaborative* contributions done in ways that I feel leaves an extra burden on me. One description for that is "drive-by contributions", meaning that someone contributes without having the time to *collaborate* on it, to align the contribution with how the package is maintained. But since this whole thread is about "true open collaboration", I assume that you are talking about *collaborative* work, and then I cannot recognize what is the kind of annoyance you are referring to. Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 03/08/2024 15:16, Jonas Smedegaard ha scritto: Quoting Kentaro Hayashi (2024-08-03 14:40:51) Hi, Even though +1 for DEP-18 basically, I think that it might be better to add an option to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/. If such a package repository enables merge request feature, then I will send merge request and send E-mail to bugs.d.o about url of the MR to notify it. But it is not true that such MR is merged in timely manner. (Surely collaboration takes longer time, I know.) If the package owner expresses a collaboration policy in advance, it can improve such a situation in a particular case and we can respect it. NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve collaboration in Debian, IMHO. Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it) * Collaboration-Policy: debian/CONTRIBUTION.md Yes, we have README.source already, but it might be better to note in a separate file about collaboration. * Collaboration-Policy-Commit: yes It declares that the package owner encourages non-maintainer DD to commit directly without merge request. * Collaboration-Policy-Merge: yes It declares that the package owner encourages non-maintainer DD to allow merge requests. (DD has maintainer right in salsa.d.o by default as you know, but you can merge without worry if there is it.) * Collaboration-Policy-LowThresholdNmu: yes It declares that LowThresholdNmu rule [1] is applied. * Collabollation-Policy-NMU-Delay: 15 It declares that NMU delay the package owner wants. [1] https://wiki.debian.org/LowThresholdNmu Pros: * DD/DM and contributors can respect the package owner's intent about the package collaboration. * Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source. * Because other DD (non package owner) can commit/merge, then ship NMU package. Cons: * Maintainers will be bothered to add that new field to every package (If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed) * No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy because DD has maintainer rights on salsa.d.o and can commit/merge it in reality. It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack with incomplete communication in some cases. What is the core purpose of adding these suggested new metadata fields? An NMU is non-collaborative - it is a non-maintainer that not only offers a contribution but bypasses maintainers and issues a release with the contribution integrated. It makes sense for me that we have ways for maintainers to communicate ahead of time, how NMUs are acceptable, because NMUs lack collaboration. I was under the impression that collaboration was, well, collaborative. That it was about collaboration between contributors and maintainers. Am I mistaken, and it is instead about collaboration between contributors and non-maintainer mentors, which potentially ends in an NMU? If not - if it is collaboration with maintainers - then I don't understand the need for signalling ahead of time how maintainers prefer to work, as contributors can simply ask the maintainer. there is a purpose and that is what I was trying to explain in a part of one of my emails: to have certain information on how to contribute in a simple and fast way, without having to write emails to which you might never receive a reply, or after days or even weeks so you can instead immediately proceed to contribute in the preferred methods indicated and even if there is no response less emails to answer from maintainers and instead spend that time analyzing the contributions received (maybe more likely as he or his team prefers) more chance of contributions, rather than maybe sending an email to the maintainer, waiting and since he doesn't respond you think it's useless to contribute there and you avoid it (in some packages where I wanted to contribute occasionally I ended up doing that). once there are contributions there is a greater chance that they will be made NMU by DD (especially if RC), if already mostly ready, more chance that they will be used by other DD in case of team packages, or possibly by contributors trying to save an abandoned package, and these are some examples that come to mind - Jonas OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 03/08/2024 14:40, Kentaro Hayashi ha scritto: Hi, Even though +1 for DEP-18 basically, I think that it might be better to add an option to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/. If such a package repository enables merge request feature, then I will send merge request and send E-mail to bugs.d.o about url of the MR to notify it. But it is not true that such MR is merged in timely manner. (Surely collaboration takes longer time, I know.) If the package owner expresses a collaboration policy in advance, it can improve such a situation in a particular case and we can respect it. NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve collaboration in Debian, IMHO. Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it) * Collaboration-Policy: debian/CONTRIBUTION.md Yes, we have README.source already, but it might be better to note in a separate file about collaboration. * Collaboration-Policy-Commit: yes It declares that the package owner encourages non-maintainer DD to commit directly without merge request. * Collaboration-Policy-Merge: yes It declares that the package owner encourages non-maintainer DD to allow merge requests. (DD has maintainer right in salsa.d.o by default as you know, but you can merge without worry if there is it.) * Collaboration-Policy-LowThresholdNmu: yes It declares that LowThresholdNmu rule [1] is applied. * Collabollation-Policy-NMU-Delay: 15 It declares that NMU delay the package owner wants. [1] https://wiki.debian.org/LowThresholdNmu Pros: * DD/DM and contributors can respect the package owner's intent about the package collaboration. * Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source. * Because other DD (non package owner) can commit/merge, then ship NMU package. Cons: * Maintainers will be bothered to add that new field to every package (If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed) * No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy because DD has maintainer rights on salsa.d.o and can commit/merge it in reality. It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack with incomplete communication in some cases. Hi, this I think is can be useful (beyond the example use of salsa/debian packages which is not necessary as replied by Tobias Frost), I think will be better with only one additional (and optional) field in d/control, like Collaboration-Policy that point a file or url, this I think that can decrease the possible annoyance and in the case of teams or even single maintainers having a single policy file to point to and update in a simpler and faster way (especially if there were the same policies for dozens of packages or more, there could be also hundreds or thousands) Also the local file or via url to which it points I think should have both predefined and machine readable fields and the possibility of having other text or other links for further details as an additional field I think it is useful to add one regarding the preferred method for contributing, patches on bugtracker (if there were those who would prefer to continue on those even if DEP-18 recommended salsa), or via vcs (be it MR on salsa, PR on github etc.) depending on what you use, or both (if both are welcome) alternatively to not have an extra field in d/control simply use debian/CONTRIBUTION.md, if it exists and if you want to do it in a simple/fast way with a single one on many packages pointing to the url insert there a single machine readable case that points to the url that would have been put in d/control instead Regards, 2024年7月28日(日) 7:39 Otto Kekäläinen : Hi all, I have drafted a new DEP at https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: Enable true open collaboration on all Debian packages". Direct link to raw text: https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn This would have been a great topic to discuss in person at DebConf, but unfortunately I can't attend this year, so I'll just kick this off on the mailing list. This is continuation to the 'single maintainership' discussions earlier this year. I also think that more unified and open collaboration processes could help decrease maintainer burnout, lower barrier for existing and new maintainers to help with multiple packages, and overall perhaps also improve quality of uploads by having more attention on the so
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Kentaro Hayashi (2024-08-03 14:40:51) > Hi, > > Even though +1 for DEP-18 basically, I think that it might be better > to add an option > to formalize package owner's (single person maintainer) collaboration policy > especially about non-team maintained packages under > https://salsa.debian.org/debian/. > > If such a package repository enables merge request feature, then I > will send merge request and > send E-mail to bugs.d.o about url of the MR to notify it. > But it is not true that such MR is merged in timely manner. > (Surely collaboration takes longer time, I know.) > > If the package owner expresses a collaboration policy in advance, it > can improve such a situation > in a particular case and we can respect it. > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > use-case to improve > collaboration in Debian, IMHO. > > Here is just an idea: put collaboration policy metadata in debian/control. > (The following idea assumes that non-maintainer DD tend to hesitate to > commit/merge it) > > * Collaboration-Policy: debian/CONTRIBUTION.md > Yes, we have README.source already, but it might be better to note > in a separate file about collaboration. > * Collaboration-Policy-Commit: yes > It declares that the package owner encourages non-maintainer DD to > commit directly without merge request. > * Collaboration-Policy-Merge: yes > It declares that the package owner encourages non-maintainer DD to > allow merge requests. > (DD has maintainer right in salsa.d.o by default as you know, but > you can merge without worry if there is it.) > * Collaboration-Policy-LowThresholdNmu: yes > It declares that LowThresholdNmu rule [1] is applied. > * Collabollation-Policy-NMU-Delay: 15 > It declares that NMU delay the package owner wants. > > [1] https://wiki.debian.org/LowThresholdNmu > > Pros: > * DD/DM and contributors can respect the package owner's intent about > the package collaboration. > * Reduce a chance to cause inconsistency between the content of each > package repository on salsa.d.o and NMU'ed package source. > * Because other DD (non package owner) can commit/merge, then ship > NMU package. > Cons: > * Maintainers will be bothered to add that new field to every package > (If there is no Collaboration-Policy, it is safe that sending merge > request and let it the package manager, thus nothing changed) > * No mechanism to enforce Collaboration-Policy-Commit: no or > Collaboration-Policy-Merge: no policy > because DD has maintainer rights on salsa.d.o and can commit/merge > it in reality. > > It might worry too much, but it might be able to block an unfortunate > accident, a so-called package hijack > with incomplete communication in some cases. What is the core purpose of adding these suggested new metadata fields? An NMU is non-collaborative - it is a non-maintainer that not only offers a contribution but bypasses maintainers and issues a release with the contribution integrated. It makes sense for me that we have ways for maintainers to communicate ahead of time, how NMUs are acceptable, because NMUs lack collaboration. I was under the impression that collaboration was, well, collaborative. That it was about collaboration between contributors and maintainers. Am I mistaken, and it is instead about collaboration between contributors and non-maintainer mentors, which potentially ends in an NMU? If not - if it is collaboration with maintainers - then I don't understand the need for signalling ahead of time how maintainers prefer to work, as contributors can simply ask the maintainer. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 03, 2024 at 09:40:51PM +0900, Kentaro Hayashi wrote: > Hi, > > Even though +1 for DEP-18 basically, I think that it might be better > to add an option > to formalize package owner's (single person maintainer) collaboration policy > especially about non-team maintained packages under > https://salsa.debian.org/debian/. > (...) > If such a package repository enables merge request feature, then I > will send merge request and > send E-mail to bugs.d.o about url of the MR to notify it. > But it is not true that such MR is merged in timely manner. > (Surely collaboration takes longer time, I know.) > > If the package owner expresses a collaboration policy in advance, it > can improve such a situation > in a particular case and we can respect it. > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > use-case to improve > collaboration in Debian, IMHO. > > Here is just an idea: put collaboration policy metadata in debian/control. > (The following idea assumes that non-maintainer DD tend to hesitate to > commit/merge it) > > * Collaboration-Policy: debian/CONTRIBUTION.md > Yes, we have README.source already, but it might be better to note > in a separate file about collaboration. > * Collaboration-Policy-Commit: yes > It declares that the package owner encourages non-maintainer DD to > commit directly without merge request. > * Collaboration-Policy-Merge: yes > It declares that the package owner encourages non-maintainer DD to > allow merge requests. > (DD has maintainer right in salsa.d.o by default as you know, but > you can merge without worry if there is it.) > * Collaboration-Policy-LowThresholdNmu: yes > It declares that LowThresholdNmu rule [1] is applied. > * Collabollation-Policy-NMU-Delay: 15 > It declares that NMU delay the package owner wants. > > [1] https://wiki.debian.org/LowThresholdNmu > > Pros: > * DD/DM and contributors can respect the package owner's intent about > the package collaboration. > * Reduce a chance to cause inconsistency between the content of each > package repository on salsa.d.o and NMU'ed package source. > * Because other DD (non package owner) can commit/merge, then ship > NMU package. > Cons: > * Maintainers will be bothered to add that new field to every package > (If there is no Collaboration-Policy, it is safe that sending merge > request and let it the package manager, thus nothing changed) > * No mechanism to enforce Collaboration-Policy-Commit: no or > Collaboration-Policy-Merge: no policy > because DD has maintainer rights on salsa.d.o and can commit/merge > it in reality. > > It might worry too much, but it might be able to block an unfortunate > accident, a so-called package hijack > with incomplete communication in some cases. by placing a package in the debian namespace on salsa, the packagee is declared as team maintained by everyone, so above is alrady today acceptble, even without explict placet by the maintainer. https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group -- tobi
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi, Tobias. Thank you for kindly advice, I've misunderstood about debian/ namespace. Please ignore the previous my post. [1] I felt sorry posting just a noise. [1] https://lists.debian.org/debian-devel/2024/08/msg00052.html Regards, 2024年8月3日(土) 21:54 Tobias Frost : > > On Sat, Aug 03, 2024 at 09:40:51PM +0900, Kentaro Hayashi wrote: > > Hi, > > > > Even though +1 for DEP-18 basically, I think that it might be better > > to add an option > > to formalize package owner's (single person maintainer) collaboration policy > > especially about non-team maintained packages under > > https://salsa.debian.org/debian/. > > > (...) > > > If such a package repository enables merge request feature, then I > > will send merge request and > > send E-mail to bugs.d.o about url of the MR to notify it. > > But it is not true that such MR is merged in timely manner. > > (Surely collaboration takes longer time, I know.) > > > > If the package owner expresses a collaboration policy in advance, it > > can improve such a situation > > in a particular case and we can respect it. > > > > NOTE: The following idea might be out-of-scope in DEP-18, but specific > > use-case to improve > > collaboration in Debian, IMHO. > > > > Here is just an idea: put collaboration policy metadata in debian/control. > > (The following idea assumes that non-maintainer DD tend to hesitate to > > commit/merge it) > > > > * Collaboration-Policy: debian/CONTRIBUTION.md > > Yes, we have README.source already, but it might be better to note > > in a separate file about collaboration. > > * Collaboration-Policy-Commit: yes > > It declares that the package owner encourages non-maintainer DD to > > commit directly without merge request. > > * Collaboration-Policy-Merge: yes > > It declares that the package owner encourages non-maintainer DD to > > allow merge requests. > > (DD has maintainer right in salsa.d.o by default as you know, but > > you can merge without worry if there is it.) > > * Collaboration-Policy-LowThresholdNmu: yes > > It declares that LowThresholdNmu rule [1] is applied. > > * Collabollation-Policy-NMU-Delay: 15 > > It declares that NMU delay the package owner wants. > > > > [1] https://wiki.debian.org/LowThresholdNmu > > > > Pros: > > * DD/DM and contributors can respect the package owner's intent about > > the package collaboration. > > * Reduce a chance to cause inconsistency between the content of each > > package repository on salsa.d.o and NMU'ed package source. > > * Because other DD (non package owner) can commit/merge, then ship > > NMU package. > > Cons: > > * Maintainers will be bothered to add that new field to every package > > (If there is no Collaboration-Policy, it is safe that sending merge > > request and let it the package manager, thus nothing changed) > > * No mechanism to enforce Collaboration-Policy-Commit: no or > > Collaboration-Policy-Merge: no policy > > because DD has maintainer rights on salsa.d.o and can commit/merge > > it in reality. > > > > It might worry too much, but it might be able to block an unfortunate > > accident, a so-called package hijack > > with incomplete communication in some cases. > > by placing a package in the debian namespace on salsa, the packagee is > declared as team maintained by everyone, so above is alrady today > acceptble, even without explict placet by the maintainer. > > https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group > > > -- > tobi > -- Kentaro Hayashi
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi, Even though +1 for DEP-18 basically, I think that it might be better to add an option to formalize package owner's (single person maintainer) collaboration policy especially about non-team maintained packages under https://salsa.debian.org/debian/. If such a package repository enables merge request feature, then I will send merge request and send E-mail to bugs.d.o about url of the MR to notify it. But it is not true that such MR is merged in timely manner. (Surely collaboration takes longer time, I know.) If the package owner expresses a collaboration policy in advance, it can improve such a situation in a particular case and we can respect it. NOTE: The following idea might be out-of-scope in DEP-18, but specific use-case to improve collaboration in Debian, IMHO. Here is just an idea: put collaboration policy metadata in debian/control. (The following idea assumes that non-maintainer DD tend to hesitate to commit/merge it) * Collaboration-Policy: debian/CONTRIBUTION.md Yes, we have README.source already, but it might be better to note in a separate file about collaboration. * Collaboration-Policy-Commit: yes It declares that the package owner encourages non-maintainer DD to commit directly without merge request. * Collaboration-Policy-Merge: yes It declares that the package owner encourages non-maintainer DD to allow merge requests. (DD has maintainer right in salsa.d.o by default as you know, but you can merge without worry if there is it.) * Collaboration-Policy-LowThresholdNmu: yes It declares that LowThresholdNmu rule [1] is applied. * Collabollation-Policy-NMU-Delay: 15 It declares that NMU delay the package owner wants. [1] https://wiki.debian.org/LowThresholdNmu Pros: * DD/DM and contributors can respect the package owner's intent about the package collaboration. * Reduce a chance to cause inconsistency between the content of each package repository on salsa.d.o and NMU'ed package source. * Because other DD (non package owner) can commit/merge, then ship NMU package. Cons: * Maintainers will be bothered to add that new field to every package (If there is no Collaboration-Policy, it is safe that sending merge request and let it the package manager, thus nothing changed) * No mechanism to enforce Collaboration-Policy-Commit: no or Collaboration-Policy-Merge: no policy because DD has maintainer rights on salsa.d.o and can commit/merge it in reality. It might worry too much, but it might be able to block an unfortunate accident, a so-called package hijack with incomplete communication in some cases. Regards, 2024年7月28日(日) 7:39 Otto Kekäläinen : > > Hi all, > > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". > > Direct link to raw text: > https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.mdwn > > This would have been a great topic to discuss in person at DebConf, but > unfortunately I can't attend this year, so I'll just kick this off on the > mailing list. > > This is continuation to the 'single maintainership' discussions earlier this > year. I also think that more unified and open collaboration processes could > help decrease maintainer burnout, lower barrier for existing and new > maintainers to help with multiple packages, and overall perhaps also improve > quality of uploads by having more attention on the source code prior to > upload. > > If you think this proposal makes sense, please press the thumbs up button. > > If you have comments, please share them here or on the draft itself. > > Thanks, > > Otto > -- Kentaro Hayashi
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Il 03/08/2024 01:28, Jonas Smedegaard ha scritto: Quoting Fabio Fantoni (2024-08-02 23:51:26) Il 02/08/2024 15:49, Jonas Smedegaard ha scritto: I think that both email and systems like salsa/github/gitlab etc. are useful, both with pros and cons. Forcing people to use only one or the other could be counterproductive at the moment. One thing that I think would be useful is to have certain, fast and simple information for each package about which actual collaboration methods it uses and prefers. For example seeing a package it would be very useful to know immediately if it wants a collaboration only through bugtracker and patch, only through vcs or both are accepted. If managed in a team point more easily to information about the team and any pages with details (for example on wiki). I guess that you mean something like this: ```patch --- a/debian/control +++ b/debian/control @@ -60,6 +60,7 @@ Standards-Version: 4.7.0 Homepage: https://github.com/oxigraph/oxigraph Vcs-Git: https://salsa.debian.org/debian/oxigraph.git Vcs-Browser: https://salsa.debian.org/debian/oxigraph +Contact: https://bugs.debian.org/oxigraph Rules-Requires-Root: no Package: oxigraph ``` In principle I find that an interesting suggestion, as I can imagine such information being helpful in understanding if debbugs is used only by "dinosaurs". I see two problems, however: a) Maintainers will be bothered to add that new field to every package (or at least a substantial subset) for it to be of practical use. b) Which other answers exist for that field? I mean, is it ok in Debian for a maintainer to not use Debbugs? Is it ok in Debian for a maintainer to also use another issue tracker and not replicate whatever is collected elsewhere in Debbugs? Or perhaps I am missing the point of your suggestion, and you do not mean where *bug* chatter goes, but instead where *non-bug* conversations go. If that is the case, then I believe we have a field already for that, called "Maintainer:". If you mean neither issue tracking nor the main contact information for a package, then please elaborate what you had in mind, because that's pretty essential to get clarified before discussing any further... contact field don't exist now right? even if the contact field maybe doesn't give you an idea, maybe something like "contributing" that links to the bugtracker, to the repository MR/PR or a wiki page or site with any details (especially in case of a group) Yes, the contact field exists: https://www.debian.org/doc/debian-policy/ch-controlfields.html#maintainer I spent a lot of time writing but it seems I didn't manage to convey most of what I mean :( DEP-18 doesn't seem to me to want to change existing contact methods but to standardize/improve the collaboration part regarding contributing to the development of packages, or am I perhaps missing something? and I was just thinking about that part and thinking about how to contribute in a package then I did a more extensive and practical reasoning and it seems that in most of what I said I was unable to explain myself in theory DEP-18 would be great and could produce great results but in practice I suppose there are not enough contributors and enough participation to make it possible (or at most it will be possible on a small part of packages) and so I was thinking about what would be a prerequisite to have more possibilities of contributors and contributions and also possible small improvements on the situation from which we start maybe I'm not good at explaining myself, I think the problem is that if a contributor, maybe even new or who wants to make even occasional contributions on specific packages is not able to find in a simple and fast way about the package on which he wants to contribute as he should (or is better to do), in some cases you can understand in short time by looking a bit at the bugtracker and the vcs while, looking for any wiki pages if he is part of a team but in many cases it is not simple/fast to understand how he should contribute for that package in order to get the best result. using patches on bugtracker or vcs (like salsa) is just one part, then there could be more you could say to force everyone to use the same system, in theory it would solve the problem, but in practice I find it difficult and perhaps more harmful. I try to summarize: the contributors are people and not machines, moreover many do it as a passion in a little free time and not as if it were a job. We all do it as a passion in little free time and not if it were a job. Also Maintainers. What is the point of introducing additional ways to interact with maintainers than the ones that already exist and (as I understand it) is mandatory: A general contact *email* address, and tied to that a connection to the *Debbugs* issue tracker. If a new contributor is unable to contact a package maintainer throug
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hello, I like the dgit idea, produce a git repository for people who want to use git and let other use whatever they want. Maybe uploading a paquage to Debian could push automatically into dgit. (maybe this is already the case) Is it possible then to mirror this dgit repository in salsa ? Fred
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote: > > I have drafted a new DEP at > > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > > Enable true open collaboration on all Debian packages". > > Hi Otto, > > thank you for your initiative, > > one problem I have with NMUs in team-maintained package is that they > often bypass Salsa… Would it make sense to add to the DEP a request > that NMUs are started from and pushed to the default branch? +1 Regardless of what VCS is used, an NMU that bypasses it just makes more work for the maintainer. If not pushed, there should at minimum be an open merge request that applies cleanly to whatever was in the archive prior to the NMU. It would be nice to codify this. noah
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Le Sat, Jul 27, 2024 at 03:38:40PM -0700, Otto Kekäläinen a écrit : > > I have drafted a new DEP at > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18: > Enable true open collaboration on all Debian packages". Hi Otto, thank you for your initiative, one problem I have with NMUs in team-maintained package is that they often bypass Salsa… Would it make sense to add to the DEP a request that NMUs are started from and pushed to the default branch? Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
On Sat, Aug 3, 2024 at 2:26 PM Jonas Smedegaard wrote: > > My problem with DEP-18 is that people who have zero problem with using > git and are also not fundamentally against using salsa, but have > reservations surrounding *which parts* of salsa to use and the > consequences for related already used tooling. > > I am also not against being welcoming to newcomers, but I am concerned > if the focus on tose unreasonably reshapes the tooling for all of us. > > Essentially, my concern is that DEP-18 reduces a spectrum of options to > "either you are for or against true collaboration". > > Leaning more on Gitlab is not the "true" choice, but the pragmatic one, > because yes, we have invested in it, and some parts of it might be made > to better use for use. > > I imagine that some in the silent crowd hesitate to chime in due to that > lumping together the use of git and the use of Gitlab into an > all-or-nothing choice. I think you intended that reduction, for the > purpose of simplifying the conversation. I don't think that > simplification is helpfull, however. +1 I also feel uncomfortable with this proposal that pushes the use of Gitlab in the name of true collaboration. -- Shengjing Zhu
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Quoting Otto Kekäläinen (2024-08-03 06:38:38) > > I am not suggesting salsa use because I think it's the best thing since the > > invention of sliced bread. But personally, I rather use something > > suboptimal if > > it means that we can more or less agree on a "default" and I think that the > > current situation (submission of patches by mail and the debian archive is > > the > > bts) is deterring to newcomers. I know that most people probably have faster > > machines than I. As it was pointed out elsewhere in this thread, Debian > > work > > already implies a lot more waiting than "a few seconds" for salsa to finish > > loading a page or finish yet another animation, so meh. With the glab tool I > > think I can be happy enough. > > This I think summarizes well the opinion of most people I have spoken > with. GitLab is not perfect, but it was chosen and we have been using > it for 5+ years mostly successfully. Most packages are there and we > should state that it is the recommended option. Currently the second > most popular option is to use GitHub, or not use any vcs at all. > > A lot of this thread has gone into people expressing their dislike for > Salsa. Most people still use Salsa - I guess the silent mass isn't > chiming in in this thread that much now. Some people probably have > very optimized email workflows, and nobody can argue against the > statement that a pure email workflow for sure is simple, and has its > elegance. But it also has shortcomings such as no lack of > metadata/status, no built-in way to run CI and share the code+logs+CI > results etc. > > Following the principles 1 (use git) and 2 (use Salsa) allows for the > next principles 3, 4 and 5 to take place. I would be curious to hear > more views about them. > > DEP-18 summary (https://salsa.debian.org/dep-team/deps/-/merge_requests/8): > 1. Have package source code in version control, using git > 2. Host package source on Debian's code forge Salsa > 3. Run Salsa CI at least once before every upload to ensure minimal > level of quality > 4. Allow Merge Requests to be submitted > 5. Allow changes to be reviewed before uploads to Debian > > My plan is to summarize the discussion and update the proposal in the > coming days, incorporating as many views as possible. I will also in > the next update include additional relevant context info such as > tag2upload, glab and examples of how to easily work with both Debian > bug tracker and MRs in parallel. > > Please share your views, and also +1 or -1 the proposal on Salsa so we > can incorporate that too in measuring the support of this. > > Remember that DEPs are soft rules - unlike General Resolutions (GRs) - > and maintainers who have specific reasons to not want to use git or > Salsa will not be forced to do so. My problem with DEP-18 is that people who have zero problem with using git and are also not fundamentally against using salsa, but have reservations surrounding *which parts* of salsa to use and the consequences for related already used tooling. I am also not against being welcoming to newcomers, but I am concerned if the focus on tose unreasonably reshapes the tooling for all of us. Essentially, my concern is that DEP-18 reduces a spectrum of options to "either you are for or against true collaboration". Leaning more on Gitlab is not the "true" choice, but the pragmatic one, because yes, we have invested in it, and some parts of it might be made to better use for use. I imagine that some in the silent crowd hesitate to chime in due to that lumping together the use of git and the use of Gitlab into an all-or-nothing choice. I think you intended that reduction, for the purpose of simplifying the conversation. I don't think that simplification is helpfull, however. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Request for feedback on draft: DEP-18: Enable true open collaboration on all Debian packages
Hi, On Fri, 2 Aug 2024 at 16:27, Johannes Schauer Marin Rodrigues wrote: > Quoting Otto Kekäläinen (2024-08-02 17:23:51) > > I agree that Salsa is sometimes a bit sluggish > > (https://salsa.debian.org/salsa/support/-/issues/395), > > what kind of hardware do you have? For people like me who are on slower I have a 4-year old Dell XPS 13 (that came with Ubuntu preinstalled and has perfect Linux support, great laptop by the way). > hardware, the web experience is absolutely not funny and "a bit sluggish" > doesn't begin to describe it. It is hard to find any other website I'm > visiting > that is slower than gitlab. For example, when I run this on my Firefox I get a > score of 1.53: https://browserbench.org/Speedometer3.0/#summary I got 9.25. Some of the GitLab slowness is due to the server side, and some due to JavaScript. I prefer to use mild terms "a bit sluggish" out of empathy to the people who maintain Salsa, as it is probably not fun for them to read too vocal complaints after the incredible amount of work they have put in to get us this far. I am very grateful for their work and with the language in the bug report I try to be constructive on what things to prioritize next. ... > You now said "I hope we can do something to improve it and it is now a > permanent reason to not use Salsa." twice: > > Did you typo it twice or do you actually mean that it's now a permanent reason > to not use salsa? Thanks for pointing out the typo. I meant 'not a permanent reason'. I typo now/not frequently for some odd reason and since both words are in the dictionary, my spell checker does not flag it. > I am not suggesting salsa use because I think it's the best thing since the > invention of sliced bread. But personally, I rather use something suboptimal > if > it means that we can more or less agree on a "default" and I think that the > current situation (submission of patches by mail and the debian archive is the > bts) is deterring to newcomers. I know that most people probably have faster > machines than I. As it was pointed out elsewhere in this thread, Debian work > already implies a lot more waiting than "a few seconds" for salsa to finish > loading a page or finish yet another animation, so meh. With the glab tool I > think I can be happy enough. This I think summarizes well the opinion of most people I have spoken with. GitLab is not perfect, but it was chosen and we have been using it for 5+ years mostly successfully. Most packages are there and we should state that it is the recommended option. Currently the second most popular option is to use GitHub, or not use any vcs at all. A lot of this thread has gone into people expressing their dislike for Salsa. Most people still use Salsa - I guess the silent mass isn't chiming in in this thread that much now. Some people probably have very optimized email workflows, and nobody can argue against the statement that a pure email workflow for sure is simple, and has its elegance. But it also has shortcomings such as no lack of metadata/status, no built-in way to run CI and share the code+logs+CI results etc. Following the principles 1 (use git) and 2 (use Salsa) allows for the next principles 3, 4 and 5 to take place. I would be curious to hear more views about them. DEP-18 summary (https://salsa.debian.org/dep-team/deps/-/merge_requests/8): 1. Have package source code in version control, using git 2. Host package source on Debian's code forge Salsa 3. Run Salsa CI at least once before every upload to ensure minimal level of quality 4. Allow Merge Requests to be submitted 5. Allow changes to be reviewed before uploads to Debian My plan is to summarize the discussion and update the proposal in the coming days, incorporating as many views as possible. I will also in the next update include additional relevant context info such as tag2upload, glab and examples of how to easily work with both Debian bug tracker and MRs in parallel. Please share your views, and also +1 or -1 the proposal on Salsa so we can incorporate that too in measuring the support of this. Remember that DEPs are soft rules - unlike General Resolutions (GRs) - and maintainers who have specific reasons to not want to use git or Salsa will not be forced to do so.
