Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.devel > #111354 > unrolled thread
| Started by | Andreas Tille <andreas@an3as.eu> |
|---|---|
| First post | 2024-04-07 16:10 +0200 |
| Last post | 2024-04-08 12:30 +0200 |
| Articles | 14 on this page of 114 — 37 participants |
Back to article view | Back to linux.debian.devel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-07 16:10 +0200
Re: finally end single-person maintainership Wouter Verhelst <w@uter.be> - 2024-04-07 16:20 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-07 16:50 +0200
Re: finally end single-person maintainership Scott Kitterman <debian@kitterman.com> - 2024-05-20 22:50 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-05-21 09:00 +0200
Re: finally end single-person maintainership Philip Hands <phil@hands.com> - 2024-05-21 12:10 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-05-21 13:00 +0200
Re: finally end single-person maintainership Stefano Rivera <stefanor@debian.org> - 2024-05-21 16:40 +0200
Re: finally end single-person maintainership Russ Allbery <rra@debian.org> - 2024-05-21 18:30 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-05-22 07:40 +0200
Re: finally end single-person maintainership Salvo Tomaselli <tiposchi@tiscali.it> - 2024-05-22 00:30 +0200
broad goals (Re: finally end single-person maintainership) Holger Levsen <holger@layer-acht.org> - 2024-05-22 11:30 +0200
Re: finally end single-person maintainership Salvo Tomaselli <tiposchi@tiscali.it> - 2024-05-21 16:00 +0200
Re: finally end single-person maintainership Salvo Tomaselli <tiposchi@tiscali.it> - 2024-05-22 00:40 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-05-22 01:50 +0200
Re: Documenting packaging workflows (was: finally end single-person maintainership) Philip Hands <phil@hands.com> - 2024-05-22 15:30 +0200
Re: Documenting packaging workflows (was: finally end single-person maintainership) PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2024-05-22 08:40 +0200
Re: Documenting packaging workflows Russ Allbery <rra@debian.org> - 2024-05-22 09:00 +0200
Re: Documenting packaging workflows (was: finally end single-person maintainership) Salvo Tomaselli <tiposchi@tiscali.it> - 2024-05-22 10:20 +0200
Documenting packaging workflows (was: finally end single-person maintainership) Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-05-22 07:20 +0200
Re: finally end single-person maintainership Russ Allbery <rra@debian.org> - 2024-05-22 01:50 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-05-22 07:50 +0200
Re: finally end single-person maintainership Holger Levsen <holger@layer-acht.org> - 2024-05-22 11:30 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-05-22 07:20 +0200
Re: finally end single-person maintainership Wookey <wookey@wookware.org> - 2024-04-07 22:50 +0200
Re: finally end single-person maintainership Marco d'Itri <md@Linux.IT> - 2024-04-07 23:10 +0200
Re: finally end single-person maintainership Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-04-08 04:00 +0200
Re: finally end single-person maintainership Undef <debian-devel@undef.tools> - 2024-04-08 08:00 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-04-08 14:50 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-04-08 15:00 +0200
Re: finally end single-person maintainership Julien Puydt <julien.puydt@gmail.com> - 2024-04-08 15:50 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-04-08 16:10 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-09 16:10 +0200
Re: finally end single-person maintainership gregor herrmann <gregoa@debian.org> - 2024-04-10 22:40 +0200
Re: finally end single-person maintainership Wookey <wookey@wookware.org> - 2024-04-09 19:00 +0200
Re: finally end single-person maintainership Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-04-09 19:50 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-04-09 20:10 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-04-09 20:10 +0200
Re: finally end single-person maintainership "Jose-Luis Rivas" <ghostbar@debian.org> - 2024-04-09 20:30 +0200
Re: finally end single-person maintainership Holger Levsen <holger@layer-acht.org> - 2024-04-09 20:40 +0200
Re: finally end single-person maintainership Scott Kitterman <debian@kitterman.com> - 2024-04-09 21:20 +0200
Re: finally end single-person maintainership "Jonathan Dowland" <jmtd@debian.org> - 2024-04-12 11:00 +0200
Re: finally end single-person maintainership Holger Levsen <holger@layer-acht.org> - 2024-04-12 13:20 +0200
Re: finally end single-person maintainership Mike Gabriel <mike.gabriel@das-netzwerkteam.de> - 2024-04-12 11:30 +0200
Re: finally end single-person maintainership Marc Haber <mh+debian-devel@zugschlus.de> - 2024-04-12 15:10 +0200
Re: finally end single-person maintainership Gioele Barabucci <gioele@svario.it> - 2024-04-12 15:20 +0200
Re: finally end single-person maintainership gregor herrmann <gregoa@debian.org> - 2024-04-14 02:00 +0200
Re: finally end single-person maintainership Marc Haber <mh+debian-devel@zugschlus.de> - 2024-04-12 15:00 +0200
Re: finally end single-person maintainership Bastian Blank <waldi@debian.org> - 2024-04-12 22:00 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-14 10:50 +0200
Re: finally end single-person maintainership Gioele Barabucci <gioele@svario.it> - 2024-04-09 21:00 +0200
Re: finally end single-person maintainership Marc Haber <mh+debian-devel@zugschlus.de> - 2024-04-12 15:10 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-05-21 03:10 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-05-21 03:50 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-05-21 04:20 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-05-21 12:20 +0200
Re: finally end single-person maintainership Otto Kekäläinen <otto@debian.org> - 2024-05-21 04:20 +0200
Re: finally end single-person maintainership Simon McVittie <smcv@debian.org> - 2024-05-21 12:20 +0200
Re: finally end single-person maintainership Russ Allbery <rra@debian.org> - 2024-05-21 04:30 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-10 22:50 +0200
Re: finally end single-person maintainership Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-04-10 23:20 +0200
Re: finally end single-person maintainership Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-05-22 07:00 +0200
Re: finally end single-person maintainership Marc Haber <mh+debian-devel@zugschlus.de> - 2024-04-12 17:20 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-04-12 18:20 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-04-12 19:30 +0200
Re: finally end single-person maintainership Salvo Tomaselli <tiposchi@tiscali.it> - 2024-04-13 11:20 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-04-13 12:20 +0200
Re: finally end single-person maintainership Andreas Tille <andreas@an3as.eu> - 2024-04-13 10:10 +0200
Re: finally end single-person maintainership Nilesh Patra <nilesh@debian.org> - 2024-04-13 10:40 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-04-13 10:40 +0200
Re: finally end single-person maintainership gregor herrmann <gregoa@debian.org> - 2024-04-10 22:50 +0200
Re: finally end single-person maintainership Bill Allombert <ballombe@debian.org> - 2024-04-07 23:20 +0200
Re: finally end single-person maintainership Gioele Barabucci <gioele@svario.it> - 2024-04-07 23:40 +0200
Re: finally end single-person maintainership Bill Allombert <ballombe@debian.org> - 2024-04-08 23:50 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-04-09 00:10 +0200
Re: finally end single-person maintainership Joerg Jaspert <joerg@debian.org> - 2024-04-09 00:30 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-04-09 01:20 +0200
Re: finally end single-person maintainership Bill Allombert <ballombe@debian.org> - 2024-04-09 20:50 +0200
Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Otto Kekäläinen <otto@debian.org> - 2024-05-19 05:30 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Jonas Smedegaard <jonas@jones.dk> - 2024-05-19 09:20 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Paul Gevers <elbrus@debian.org> - 2024-05-19 10:10 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Paul Gevers <elbrus@debian.org> - 2024-05-19 10:20 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Jonas Smedegaard <jonas@jones.dk> - 2024-05-19 10:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Mathias Behrle <mbehrle@debian.org> - 2024-05-19 11:30 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Jonas Smedegaard <jonas@jones.dk> - 2024-05-19 11:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Sean Whitton <spwhitton@spwhitton.name> - 2024-05-21 13:10 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Paul Gevers <elbrus@debian.org> - 2024-05-22 22:00 +0200
Re: dgit view of packages' history Simon McVittie <smcv@debian.org> - 2024-05-23 12:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Otto Kekäläinen <otto@debian.org> - 2024-05-19 21:40 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Jonas Smedegaard <jonas@jones.dk> - 2024-05-19 23:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Otto Kekäläinen <otto@debian.org> - 2024-05-20 00:40 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Simon Richter <sjr@debian.org> - 2024-05-20 04:10 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Sean Whitton <spwhitton@spwhitton.name> - 2024-05-21 13:10 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Sam Hartman <hartmans@debian.org> - 2024-05-21 17:20 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Andrey Rakhmatullin <wrar@debian.org> - 2024-05-21 09:00 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Simon Richter <sjr@debian.org> - 2024-05-21 13:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Andrey Rakhmatullin <wrar@debian.org> - 2024-05-21 14:00 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Luca Boccassi <bluca@debian.org> - 2024-05-21 15:30 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Holger Levsen <holger@layer-acht.org> - 2024-05-21 15:00 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Bill Allombert <ballombe@debian.org> - 2024-05-19 18:20 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Don Armstrong <don@debian.org> - 2024-05-20 05:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Otto Kekäläinen <otto@debian.org> - 2024-05-20 09:50 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Bill Allombert <ballombe@debian.org> - 2024-05-20 12:20 +0200
Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) Otto Kekäläinen <otto@debian.org> - 2024-05-21 22:10 +0200
Re: finally end single-person maintainership Johannes Schauer Marin Rodrigues <josch@debian.org> - 2024-04-09 00:20 +0200
Re: finally end single-person maintainership Bill Allombert <ballombe@debian.org> - 2024-04-12 01:00 +0200
Re: finally end single-person maintainership Matthias Urlichs <matthias@urlichs.de> - 2024-04-14 15:50 +0200
Re: finally end single-person maintainership Bill Allombert <ballombe@debian.org> - 2024-05-22 13:40 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-05-22 14:30 +0200
Re: finally end single-person maintainership Andrey Rakhmatullin <wrar@debian.org> - 2024-05-22 21:40 +0200
Re: finally end single-person maintainership Simon Richter <sjr@debian.org> - 2024-05-23 04:10 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-05-23 13:10 +0200
Re: finally end single-person maintainership Luca Boccassi <bluca@debian.org> - 2024-05-22 14:30 +0200
Re: finally end single-person maintainership Steve McIntyre <steve@einval.com> - 2024-04-08 12:30 +0200
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Don Armstrong <don@debian.org> |
|---|---|
| Date | 2024-05-20 05:50 +0200 |
| Subject | Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) |
| Message-ID | <IG2c9-ey15-1@gated-at.bofh.it> |
| In reply to | #111812 |
On Sun, 19 May 2024, Bill Allombert wrote: > Also debbugs is a special case: > The debbugs Debian package (as opposed to the debbugs software) have never been > really maintained. I am actually one of the very few users of this package > and I tried several times to get the maintainers to do a new upload but they > were clearly not interested. It's more that I'm prioritizing spending my (very) limited Debian time on keeping bugs.debian.org and debbugs itself working (and [very slowly] developing a new version of Debbugs with a more modern design in the hopes that others will contribute.) > Ideally debbugs should be made non-native so that some else could > maintain the Debian package. I'm happy to review patches that get the 2.6 branch of debbugs in shape where it can be released into Debian again if someone wants to take that effort. I've just assumed that anyone using that package was running unstable or running debbugs out of git. -- Don Armstrong https://www.donarmstrong.com A people living under the perpetual menace of war and invasion is very easy to govern. It demands no social reforms. It does not haggle over expenditures on armaments and military equipment. It pays without discussion, it ruins itself, and that is an excellent thing for the syndicates of financiers and manufacturers for whom patriotic terrors are an abundant source of gain. -- Anatole France
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2024-05-20 09:50 +0200 |
| Subject | Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) |
| Message-ID | <IG5Wp-eAj7-3@gated-at.bofh.it> |
| In reply to | #111822 |
> > Ideally debbugs should be made non-native so that some else could > > maintain the Debian package. > > I'm happy to review patches that get the 2.6 branch of debbugs in shape > where it can be released into Debian again if someone wants to take that > effort. I've just assumed that anyone using that package was running > unstable or running debbugs out of git. I did not notice the release_2.6 branch before. What is the intent with that branch? Do you want people to submit patches targeting 'master' or 'release_2.6'? How often do you plan to merge it to or from 'master'? The 'master' branch is still the default branch. The https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/README.md does not mention anything about release_2.6. Should it? I am a big fan of READMEs and recommend using them to convey guidance to contributors (assuming you want to have contributors).
[toc] | [prev] | [next] | [standalone]
| From | Bill Allombert <ballombe@debian.org> |
|---|---|
| Date | 2024-05-20 12:20 +0200 |
| Subject | Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) |
| Message-ID | <IG8hz-eBPq-7@gated-at.bofh.it> |
| In reply to | #111822 |
On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote: > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never been > > really maintained. I am actually one of the very few users of this package > > and I tried several times to get the maintainers to do a new upload but they > > were clearly not interested. > > It's more that I'm prioritizing spending my (very) limited Debian time > on keeping bugs.debian.org and debbugs itself working (and [very slowly] > developing a new version of Debbugs with a more modern design in the > hopes that others will contribute.) > > > Ideally debbugs should be made non-native so that some else could > > maintain the Debian package. > > I'm happy to review patches that get the 2.6 branch of debbugs in shape > where it can be released into Debian again if someone wants to take that > effort. But precisely, one should not need to wait for a new 'upstream release' to fix RC bugs that prevent the package to be part of a stable release. Making it non native would allow that without requiring more of your time. > I've just assumed that anyone using that package was running > unstable or running debbugs out of git. Perforce, since the package has not been in stable or testing for years. Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2024-05-21 22:10 +0200 |
| Subject | Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership) |
| Message-ID | <IGDY5-eUY4-5@gated-at.bofh.it> |
| In reply to | #111822 |
Hi! On Sun, 19 May 2024 at 20:48, Don Armstrong <don@debian.org> wrote: > > On Sun, 19 May 2024, Bill Allombert wrote: > > Also debbugs is a special case: > > The debbugs Debian package (as opposed to the debbugs software) have never been > > really maintained. I am actually one of the very few users of this package > > and I tried several times to get the maintainers to do a new upload but they > > were clearly not interested. > > It's more that I'm prioritizing spending my (very) limited Debian time > on keeping bugs.debian.org and debbugs itself working (and [very slowly] > developing a new version of Debbugs with a more modern design in the > hopes that others will contribute.) Everyone else has very limited time to contribute to Debian as well. Therefore we all need to think about what is the most efficient workflow. Perhaps you could consider how you can be a force multiplier and scale your work? You could for example add some of the recent contributors as developers or maintainers at https://salsa.debian.org/groups/debbugs-team/-/group_members so they can review/merge/push code, and you could review all submissions at https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and grow those contributors into co-maintainers instead of just ignoring them? Perhaps you can also consider optimizing your git workflows? For example in the case of https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you could have simply pressed "Merge" and everything would be good. Now you decided to not use any of the support Salsa/Salsa-CI provides, you did extra work to cherry-pick some commits (but not all), added your extra commit to break the build and now there is new follow-up work to be done for lapses that could have been easily avoided if Salsa-CI was enabled.. (I did submit MR!20 though, you can just merge it) I started this thread "Salsa - best thing in Debian in recent years?" by asking people who resist Salsa to at least try using it for a while before criticizing it so much. What happened in this episode is a case in point. You sit in a "local optima" of your current workflow and are not willing to invest a bit extra effort to get to a place where Salsa+Salsa-CI can benefit and decrease your extra work burden. Now both you and me ended up having to do extra work that could easily have been avoided.. Personally I like Salsa a lot, and collaboration with maintainers who embrace Salsa is a breeze, and I feel that my limited Debian time is relatively productive. That is all thanks to Salsa. I wish those who are not yet using it would give it a sincere try.
[toc] | [prev] | [next] | [standalone]
| From | Johannes Schauer Marin Rodrigues <josch@debian.org> |
|---|---|
| Date | 2024-04-09 00:20 +0200 |
| Message-ID | <Ir5vj-4YPu-1@gated-at.bofh.it> |
| In reply to | #111382 |
[Multipart message — attachments visible in raw view] — view raw
Quoting Bill Allombert (2024-04-08 23:49:05) > Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit : > > On 07/04/24 23:11, Bill Allombert wrote: > > > > What is your opinion about pushing logtool to Salsa? > > > > > > Not speaking for logtool obviously, but maintaining simple packages on salsa is > > > just useless bureaucracy. > > > > As a contributor, having a package on salsa is extremely useful, far from > > "useless". > > > > By clicking on "fork" (or running the equivalent CLI command) I get a copy > > of the package, with all its history, a Debian-specific CI, the ability to > > work on different features or bug fixes at the same time and independently > > from one another, the possibility to send a merge request, that can be > > annotate line-by-line by all other Debian contributors. > > > > A package with a repo on salsa is sending a clean message: go away, I don't > > want your contribution. > > I suppose you meant _without_. The message is not "your contribution is > not wanted" but rather "your contribution is not needed because there > nothing to do". > > They are hundred of other packages where your contribution would > make a difference. > > Simple packages need someone who is responsible and responsive for them > in the long run and know there history much more than needing sporadic > contributions. we need both. Domain specific knowledge is clearly very important and I'm not trying to argue against it. But doing packaging in a way such that it becomes easy for others to contribute is *also* every important. As the maintainer of a package with expert knowledge of it you might think that there is nothing to do but you while you are the expert for that package, you might not be the expert on topics like cross building, reproducible builds, multiarch, build profiles, merged-/usr, build hardening and many other topics which span the whole distribution. There are people who are heavily invested in these topics and who will want to touch very many packages to fix things. It should be made easy for them to make these contributions without them bit-rotting as a patch in the BTS for months or years. I'm not saying that *you* let these contributions bit-rot. This is meant as a general argument for making it easier to make large-scale changes to packages. Diversity in our packaging styles and strong package ownership sometimes work contrary to issues affecting very many packages across our distro. That you, as the expert on your specific package think that there is nothing to do, is not necessarily true in the larger scope of maintaining the distribution. Thanks! cheers, josch
[toc] | [prev] | [next] | [standalone]
| From | Bill Allombert <ballombe@debian.org> |
|---|---|
| Date | 2024-04-12 01:00 +0200 |
| Message-ID | <IsbyF-5ERz-9@gated-at.bofh.it> |
| In reply to | #111385 |
Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a écrit : > we need both. Domain specific knowledge is clearly very important and I'm not > trying to argue against it. But doing packaging in a way such that it becomes > easy for others to contribute is *also* every important. As the maintainer of a > package with expert knowledge of it you might think that there is nothing to do > but you while you are the expert for that package, you might not be the expert > on topics like cross building, reproducible builds, multiarch, build profiles, > merged-/usr, build hardening and many other topics which span the whole > distribution. There are people who are heavily invested in these topics and who > will want to touch very many packages to fix things. It should be made easy for > them to make these contributions without them bit-rotting as a patch in the BTS > for months or years. I'm not saying that *you* let these contributions bit-rot. > This is meant as a general argument for making it easier to make large-scale > changes to packages. Diversity in our packaging styles and strong package > ownership sometimes work contrary to issues affecting very many packages across > our distro. These contributions always need to be carefull reviewed before being accepted. As likely as not, they are either slightly incorrect or introducing subtle breakages in some case the submitter did not envision. This is where an expert maintainer is most needed. People heavily invested in some topic tend to forget the packages has other users, and often fix the symptom instead of fixing the problem. When a change leads to a RC bug a month or three after having be part of a package, fixing the problem falls on the maintainer and not on the change author. Even correct changes can trigger latent bugs in software. Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
[toc] | [prev] | [next] | [standalone]
| From | Matthias Urlichs <matthias@urlichs.de> |
|---|---|
| Date | 2024-04-14 15:50 +0200 |
| Message-ID | <It8p3-6ezx-1@gated-at.bofh.it> |
| In reply to | #111420 |
[Multipart message — attachments visible in raw view] — view raw
On 12.04.24 00:52, Bill Allombert wrote: > These contributions always need to be carefull reviewed before being > accepted. As likely as not, they are either slightly incorrect or > introducing subtle breakages in some case the submitter did not > envision. This is where an expert maintainer is most needed. Well that's your take. My take is that when contributions to packaging "always" need a careful review, that's not virtue, that's a symptom of underlying structural problems with package management. We should strive to fix the root cause instead of requiring maintainers to be packaging experts. That doesn't scale. -- -- regards -- -- Matthias Urlichs
[toc] | [prev] | [next] | [standalone]
| From | Bill Allombert <ballombe@debian.org> |
|---|---|
| Date | 2024-05-22 13:40 +0200 |
| Message-ID | <IGSu5-f3yI-1@gated-at.bofh.it> |
| In reply to | #111420 |
On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote: > On Thu, 2024-04-11 at 22:52 +0000, Bill Allombert wrote: > > > > When a change leads to a RC bug a month or three after having be > > part of a package, fixing the problem falls on the maintainer and not > > on the change author. Even correct changes can trigger latent bugs > > in software. > > Yet another reason why using Salsa and its CI *and having autopkg- > tests* is so important - contributors can test their changes before > even asking to merge them. You can run autopkgtests locally, you do not need Salsa for that. > And yes, its up to the 'expert' maintainer > of the package to ensure there are proper tests in place. Because even > that expert is a human only and we all make mistakes. Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in electricity and in carbon emission, that we cannot completely ignore. In any case, it is not realistic to expect tests to detect all kind of bugs, alas. Cheers, -- Bill. <ballombe@debian.org> Imagine a large red swirl here.
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2024-05-22 14:30 +0200 |
| Message-ID | <IGTgt-f43x-11@gated-at.bofh.it> |
| In reply to | #111892 |
Hi,
On 5/22/24 20:34, Bill Allombert wrote:
> You can run autopkgtests locally, you do not need Salsa for that.
Also, Debian runs autopkgtests on all packages that provide them, and
makes passing them on all supported architectures a requirement for
testing migration.
It could be argued that testing migration is a CI process.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Andrey Rakhmatullin <wrar@debian.org> |
|---|---|
| Date | 2024-05-22 21:40 +0200 |
| Message-ID | <IGZYB-f7YZ-7@gated-at.bofh.it> |
| In reply to | #111895 |
[Multipart message — attachments visible in raw view] — view raw
On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote: > > > You can run autopkgtests locally, you do not need Salsa for that. > > > > Also, Debian runs autopkgtests on all packages that provide them, and > > makes passing them on all supported architectures a requirement for > > testing migration. > > Uploading to check autopkgtests is an absolute waste of ressources. I > really hope nobody uploads a package without running the tests > somewhere else. > > > > > It could be argued that testing migration is a CI process. > > > > Its a CI process at a way too late stage. > Also, uploading to test a merge request is not the right thing to do. If the archive is a VCS then uploading an untested package to experimental to run tools is pushing a commit to run CI. *shrug* -- WBR, wRAR
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2024-05-23 04:10 +0200 |
| Message-ID | <IH641-fbIj-1@gated-at.bofh.it> |
| In reply to | #111902 |
Hi,
On 5/23/24 04:32, Andrey Rakhmatullin wrote:
>>> It could be argued that testing migration is a CI process. >> Its a CI process at a way too late stage.
>> Also, uploading to test a merge request is not the right thing to do.
> If the archive is a VCS then uploading an untested package to experimental
> to run tools is pushing a commit to run CI.
> *shrug*
Yes, but unironically: experimental is a side branch, unstable is a MR,
and testing is the main branch.
It is entirely valid to be dissatisfied with the turnaround time of the
existing CI, but what we're seeing here is the creation of a parallel
structure with as-of-yet unclear scope.
Can we define the scope as "quick-turnaround unofficial validation",
because that's the niche that is currently underserved?
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-05-23 13:10 +0200 |
| Message-ID | <IHeuB-fgOV-9@gated-at.bofh.it> |
| In reply to | #111904 |
On Thu, 23 May 2024 at 03:01, Simon Richter <sjr@debian.org> wrote: > > Hi, > > On 5/23/24 04:32, Andrey Rakhmatullin wrote: > > >>> It could be argued that testing migration is a CI process. >> Its a CI process at a way too late stage. > >> Also, uploading to test a merge request is not the right thing to do. > > > If the archive is a VCS then uploading an untested package to experimental > > to run tools is pushing a commit to run CI. > > *shrug* > > Yes, but unironically: experimental is a side branch, unstable is a MR, > and testing is the main branch. > > It is entirely valid to be dissatisfied with the turnaround time of the > existing CI, but what we're seeing here is the creation of a parallel > structure with as-of-yet unclear scope. > > Can we define the scope as "quick-turnaround unofficial validation", > because that's the niche that is currently underserved? The main problem is not turnaround (it's terrible ofc), it's that a broken upload to unstable affects _everybody_, while a CI run on Salsa is private and doesn't get in the way of other developers.
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-05-22 14:30 +0200 |
| Message-ID | <IGTgt-f43x-3@gated-at.bofh.it> |
| In reply to | #111892 |
On Wed, 22 May 2024 at 12:35, Bill Allombert <ballombe@debian.org> wrote: > > On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote: > > On Thu, 2024-04-11 at 22:52 +0000, Bill Allombert wrote: > > > > > > When a change leads to a RC bug a month or three after having be > > > part of a package, fixing the problem falls on the maintainer and not > > > on the change author. Even correct changes can trigger latent bugs > > > in software. > > > > Yet another reason why using Salsa and its CI *and having autopkg- > > tests* is so important - contributors can test their changes before > > even asking to merge them. > > You can run autopkgtests locally, you do not need Salsa for that. It can, but it's really a massive pain. git push and go make a cup of tea is so much nicer. Nowadays I run locally only when debugging complex issues, otherwise it's all delegated to Salsa. > > And yes, its up to the 'expert' maintainer > > of the package to ensure there are proper tests in place. Because even > > that expert is a human only and we all make mistakes. > > Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in electricity > and in carbon emission, that we cannot completely ignore. > > In any case, it is not realistic to expect tests to detect all kind of bugs, alas. The cost of running those same builds and tests locally is pushed onto the developer though, and their electricity bill. By using Salsa, the cost is pushed to the project and our sponsors - which seems the right thing to me.
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2024-04-08 12:30 +0200 |
| Message-ID | <IqUqd-4Sg6-7@gated-at.bofh.it> |
| In reply to | #111364 |
Bill Alombert wrote: >On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote: >> Hi Wouter, >> >> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst: >> > [Feel free to quote any part of this email which I wrote outside of this >> > mailinglist] >> >> OK, moving the discussion to debian-devel where it should belong. >> >> > Debian packages need to be well maintained. In some cases, having >> > multiple maintainers on a package improves the resulting quality of >> > packages. But in some other cases, it does not; one example for this >> > second case is my package "logtool", which I'm going to upload to fix >> > #1066251 soon and for which by the simple act of doing that I will >> > double the amount of uploads it's seen in the past five years (and the >> > number of uploads in the past 10 can still be counted on the fingers of >> > a single hand). >> > >> > This is not because it's not well maintained; it's because the package >> > just *does not require* a lot of work to be kept up to date: upstream >> > has not been active for over 20 years, but it still performs the job it >> > was designed to do, as it was designed to, and I see no need to have it >> > removed from the archive. >> >> What is your opinion about pushing logtool to Salsa? > >Not speaking for logtool obviously, but maintaining simple packages on salsa is >just useless bureaucracy. So that's OK for *you* only in this case. Now consioder for the project as a whole. Every package that differs from the norm is more effort for anybody else to maintain/bugfix/NMU/whatever. We have a history of this (in so many ways), and it's a significant drain. Please consider the bigger picture. -- Steve McIntyre, Cambridge, UK. steve@einval.com Can't keep my eyes from the circling sky, Tongue-tied & twisted, Just an earth-bound misfit, I...
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | linux.debian.devel
csiph-web