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
Bug#1077908: ITP: python-thumbhash -- compact representation of an image placeholder
Package: wnpp Severity: wishlist Owner: Martin X-Debbugs-Cc: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org * Package name: python-thumbhash Version : 0.1.2 Upstream Author : Justin * URL : https://github.com/justinforlenza/thumbhash-py/ * License : MIT Programming Lang: Python Description : compact representation of an image placeholder This is a Python port of the thumbhash encoder by Evan Wallace. . The library only handles the conversion of images to hashes, not the reverse.
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
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
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 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
