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 | 20 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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Scott Kitterman <debian@kitterman.com> |
|---|---|
| Date | 2024-04-09 21:20 +0200 |
| Message-ID | <IrpaF-5bvI-7@gated-at.bofh.it> |
| In reply to | #111405 |
On April 9, 2024 6:37:23 PM UTC, Holger Levsen <holger@layer-acht.org> wrote: >hi, > >just adding some random data points to this thread: > >- I love git. >- I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. >- I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) >- I love autopkgtests. >- I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. >- I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. Specifically to your last point, absolutely. Saying everyone must do a certain thing has an inverse that is we would rather you not contribute at all than do it without that thing. I would rather we make that list as short as possible. I have all my packages in git on salsa. Mostly I find it not that helpful to me, but I know others value it, so I do it (and for the occasional benefits it provides me). I think I would feel pretty strongly about not continuing to do so if someone told me I had to. Scott K
[toc] | [prev] | [next] | [standalone]
| From | "Jonathan Dowland" <jmtd@debian.org> |
|---|---|
| Date | 2024-04-12 11:00 +0200 |
| Message-ID | <IskVj-5KM6-1@gated-at.bofh.it> |
| In reply to | #111405 |
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: > - I love git. > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. > - I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) > - I love autopkgtests. > - I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. I agree with everything you say here! Wrt git-buildpackage, I'd like to add that personally, I respect the gbp authors and maintainers and it's a very useful tool to bring together some complex workflows and in particular successfully move a lot of people over from svn-buildpackage. I do however agree that there's too much magic. Some of that is inherited from the Debian-specific tooling it sits on top of: I also think there's too much magic and/or complexity in debuild and dpkg-buildpackage. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎ jmtd@debian.org 🔗 https://jmtd.net
[toc] | [prev] | [next] | [standalone]
| From | Holger Levsen <holger@layer-acht.org> |
|---|---|
| Date | 2024-04-12 13:20 +0200 |
| Message-ID | <Isn6N-5Mge-1@gated-at.bofh.it> |
| In reply to | #111422 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote: > On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote: [...] > I agree with everything you say here! :) > Wrt git-buildpackage, I'd like to add that personally, I respect the gbp > authors and maintainers and it's a very useful tool to bring together > some complex workflows and in particular successfully move a lot of > people over from svn-buildpackage. absolutly. > I do however agree that there's too much magic. Some of that is > inherited from the Debian-specific tooling it sits on top of: I also > think there's too much magic and/or complexity in debuild and > dpkg-buildpackage. absolutly. Thanks for these additions! -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me.... No fear.” (Nina Simone)
[toc] | [prev] | [next] | [standalone]
| From | Mike Gabriel <mike.gabriel@das-netzwerkteam.de> |
|---|---|
| Date | 2024-04-12 11:30 +0200 |
| Message-ID | <Islol-5LaI-1@gated-at.bofh.it> |
| In reply to | #111405 |
Hi all, hi Holger, On Di 09 Apr 2024 18:37:23 UTC, Holger Levsen wrote: > hi, > > just adding some random data points to this thread: > > - I love git. > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. > - I like salsa. (though I think for many new contributors this is rather > a barrier "why not use github" directly. Also salsa is Debian only, > which also is a barrier for some.) > - I love autopkgtests. > - I hardly every look at the autopkgs logs on salsaci, cause I find > them incomprehensible and the javascript "UX" makes me wanna chop wood. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person > maintainership > doesnt make a team and motivation lost is often motivation lost forever. Very well summarized, fully agreeing with the above, esp. the part about single-person maintainership (let's simply keep it and, at the same time, encourage people to work in teams). Also regarding gbp, my packaging workflow does not require it (debian/-folder-only in Git). Being enforced to use some other pkg'ing style would reduce my fun and end up with less productivity, I fear. The gbp workflow has its pros, but for me it is a too complex overhead without much gain to the end result (the uploaded package). Debian is about freedom, so let's apply that to free choice of the tooling to be usable. light+love, Mike -- DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2024-04-12 15:10 +0200 |
| Message-ID | <IsoPf-5NoY-7@gated-at.bofh.it> |
| In reply to | #111423 |
On Fri, 12 Apr 2024 09:26:10 +0000, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> wrote: >Also regarding gbp, my packaging workflow does not require it >(debian/-folder-only in Git). Being enforced to use some other pkg'ing >style would reduce my fun and end up with less productivity, I fear. >The gbp workflow has its pros, but for me it is a too complex overhead >without much gain to the end result (the uploaded package). The debian/-only layout was quite common in the svn days and back then we had adequate tooling to support that but those tools have rotted away, it feels unnatural to me, and, frankly, exim's debian/-only layout (that I introduced myself fifteen^wtwenty years ago) is the main reason why I am a mostly inactive member on the exim team since I still don't know any more how to properly build the package. Greetings Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Gioele Barabucci <gioele@svario.it> |
|---|---|
| Date | 2024-04-12 15:20 +0200 |
| Message-ID | <IsoYV-5Nsr-3@gated-at.bofh.it> |
| In reply to | #111430 |
On 12/04/24 15:00, Marc Haber wrote: > On Fri, 12 Apr 2024 09:26:10 +0000, Mike Gabriel > <mike.gabriel@das-netzwerkteam.de> wrote: >> Also regarding gbp, my packaging workflow does not require it >> (debian/-folder-only in Git). Being enforced to use some other pkg'ing >> style would reduce my fun and end up with less productivity, I fear. >> The gbp workflow has its pros, but for me it is a too complex overhead >> without much gain to the end result (the uploaded package). > > The debian/-only layout was quite common in the svn days and back then > we had adequate tooling to support that but those tools have rotted > away, it feels unnatural to me, and, frankly, exim's debian/-only > layout (that I introduced myself fifteen^wtwenty years ago) is the > main reason why I am a mostly inactive member on the exim team since I > still don't know any more how to properly build the package. This is not an endorsement of debian/-only repos, but building debian/-only packages using gbp is not hard: $ git clone https://salsa.debian.org/exim-team/exim4.git $ cd exim4 $ cat <<EOF > debian/gbp.conf [DEFAULT] export-dir = ../ overlay = True debian_branch = master EOF $ origtargz $ gbp buildpackage --git-ignore-new --git-no-create-orig (This is more a praise of gbp rather than a defense of debian/-only repos.) -- Gioele Barabucci
[toc] | [prev] | [next] | [standalone]
| From | gregor herrmann <gregoa@debian.org> |
|---|---|
| Date | 2024-04-14 02:00 +0200 |
| Message-ID | <IsVrP-66LV-7@gated-at.bofh.it> |
| In reply to | #111423 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 12 Apr 2024 09:26:10 +0000, Mike Gabriel wrote: > Debian is about freedom, so let's apply that to free choice of the tooling > to be usable. I disagree. "Freedom" is about Free Software, so-called freedom in packaging has high costs as people (who look at more than their "own" favourite packages) need to known and learn a plethora of packaging helper and styles and modes etc. This causes energy drains and slows down the whole project. Let's please stop this. 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 `-
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2024-04-12 15:00 +0200 |
| Message-ID | <IsoFz-5N2b-7@gated-at.bofh.it> |
| In reply to | #111405 |
On Tue, 9 Apr 2024 18:37:23 +0000, Holger Levsen <holger@layer-acht.org> wrote: >- I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Agreed. > Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. Agreed. It is too easy for three singel maintainers to form a pro forma team where everyone works on their packages and not on the others'. You cannot enforce team work. Greetings Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2024-04-12 22:00 +0200 |
| Message-ID | <Isve1-5QZd-1@gated-at.bofh.it> |
| In reply to | #111405 |
On Tue, Apr 09, 2024 at 06:37:23PM +0000, Holger Levsen wrote: > - I very much dislike git-buildpackage, too much magic. I try to avoid it > where I can. We still like those VCS-in-VCS workflows over everything else. Those debian/patches, where you need to call something special and can't just re-use upstreams CI tests. And which conflict outside of git with the next upstream version. I just stopped that and use git alone. > - I also think disallowing single-person maintainership would be very unwise, > though I agree team maintenance in general is probably better than > single-person maintainership. Still disallowing single-person maintainership > doesnt make a team and motivation lost is often motivation lost forever. What would that even mean? What is a team anyway? Bastian -- Beam me up, Scotty, there's no intelligent life down here!
[toc] | [prev] | [next] | [standalone]
| From | Andreas Tille <andreas@an3as.eu> |
|---|---|
| Date | 2024-04-14 10:50 +0200 |
| Message-ID | <It3IJ-6bQ4-7@gated-at.bofh.it> |
| In reply to | #111437 |
Am Fri, Apr 12, 2024 at 09:36:25PM +0200 schrieb Bastian Blank: > > - I also think disallowing single-person maintainership would be very unwise, > > though I agree team maintenance in general is probably better than > > single-person maintainership. Still disallowing single-person maintainership > > doesnt make a team and motivation lost is often motivation lost forever. > > What would that even mean? What is a team anyway? It means you motivate others to do the work you might not be able to do by helping them in the first place. I gave other answers in several talks page[1]. Kind regards Andreas. [1] https://people.debian.org/~tille/talks/ -- https://fam-tille.de
[toc] | [prev] | [next] | [standalone]
| From | Gioele Barabucci <gioele@svario.it> |
|---|---|
| Date | 2024-04-09 21:00 +0200 |
| Message-ID | <IroRj-5b9X-1@gated-at.bofh.it> |
| In reply to | #111398 |
On 09/04/24 18:52, Wookey wrote: > So why mandate salsa rather than make dgit more official? Independently from whether salsa should be mandated, "git", "salsa" and "dgit" are three different things and should not be used as replacement of one another. Asking maintainers "to use git" means: please push your changes, even those unreleased to a public git repository (salsa, github, codeberg, your own domain...), so other people can contribute 1) knowing that they are working against the same sources the maintainer has on their hard drive, and 2) using git-based workflows. dgit is both a Web interface to browse git repositories as wells as a system to access the Debian archive as if it were a git repository, so you can "dgit push" a branch and have the resulting binary uploaded to the archive. (Yes, I'm simplifying here, but that's the gist.) Salsa is a forge, i.e. a combination of a Web interface, a git server, and a set of integrated features. In comparison to dgit, salsa has, like most forges: * Merge requests: where people can suggest changes and discuss them with line-based comments (accessible via email, no need to use the Web interface) * Continuous integration pipelines: as soon as you push a commit, Salsa-CI will try to build a package, cross build it, test it against piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI developers). * Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, but funnily enough not BTS). * Project specific wikis, snippets, Docker images. * And with tag2upload salsa fulfills 50% of dgit functionality. Regards, -- Gioele Barabucci
[toc] | [prev] | [next] | [standalone]
| From | Marc Haber <mh+debian-devel@zugschlus.de> |
|---|---|
| Date | 2024-04-12 15:10 +0200 |
| Message-ID | <IsoPf-5NoY-1@gated-at.bofh.it> |
| In reply to | #111407 |
On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci <gioele@svario.it> wrote: >Asking maintainers "to use git" means: please push your changes, even >those unreleased to a public git repository (salsa, github, codeberg, >your own domain...), so other people can contribute 1) knowing that they >are working against the same sources the maintainer has on their hard >drive, and 2) using git-based workflows. To have this actually work, I'd like to have published best-practice things such like "branches with a 'wip-' prefix can have their history rewritten any time" so that I can use git rebase --autosquash --interactive to fix my commit errors even on branches that I have already pushed without feeling bad for doing so. >dgit is both a Web interface to browse git repositories as wells as a >system to access the Debian archive as if it were a git repository, so >you can "dgit push" a branch and have the resulting binary uploaded to >the archive. (Yes, I'm simplifying here, but that's the gist.) It is also not well documented for a beginner. I think that the dgit docs are fine for someone who is already familiar with the tool and has been using it for some time, but I have tried to read myself into dgit multiple times and utterly failed with that. >Salsa is a forge, i.e. a combination of a Web interface, a git server, >and a set of integrated features. In comparison to dgit, salsa has, like >most forges: > >* Merge requests: where people can suggest changes and discuss them with >line-based comments (accessible via email, no need to use the Web interface) > >* Continuous integration pipelines: as soon as you push a commit, >Salsa-CI will try to build a package, cross build it, test it against >piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI >developers). > >* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, >but funnily enough not BTS). > >* Project specific wikis, snippets, Docker images. > >* And with tag2upload salsa fulfills 50% of dgit functionality. And, a web interface which make the learning curve a lot less steep. Greetings Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2024-05-21 03:10 +0200 |
| Message-ID | <IGmaR-eKcQ-5@gated-at.bofh.it> |
| In reply to | #111407 |
Hi,
On 5/21/24 07:43, Bernd Zeimetz wrote:
> Also its a gitlab instance. There are all kinds of documentation,
> tutorials, videos and software for/about gitlab, including lots of
> beginner friendly options. There is a whole ecosystem around gitlab, it
> does not depend on a few (two?) developers.
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. We would
not even save effort in onboarding, because we'd still need to explain
the Debian specific aspects, only we would now also need to explain
which parts of the git workflow we can keep and which parts don't work
for us.
The workflows of GitHub (more deployment focused) and GitLab (more
development focused) are already different enough that I have seen
organizations struggle after making the wrong choice.
git-buildpackage is not a good mapping of packages to git, but the best
you can do without modifying git itself. Actually using it requires more
than beginner-level knowledge of git and suspension of any previously
held convictions that every single commit should be buildable (because
gbp likes to generate ones that aren't).
A better approach would not treat Debian metadata as git data. Even the
most vocal advocate of switching everything to Salsa writes in his MR
that the changelog should not be touched in a commit, because it creates
conflicts, and instead a manual step will need to be performed later.
At the very least, GitLab integration would allow me to automate such a
simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-05-21 03:50 +0200 |
| Message-ID | <IGmNz-eKpl-3@gated-at.bofh.it> |
| In reply to | #111845 |
On Tue, 21 May 2024 at 02:08, Simon Richter <sjr@debian.org> wrote: > > Hi, > > On 5/21/24 07:43, Bernd Zeimetz wrote: > > > Also its a gitlab instance. There are all kinds of documentation, > > tutorials, videos and software for/about gitlab, including lots of > > beginner friendly options. There is a whole ecosystem around gitlab, it > > does not depend on a few (two?) developers. > > The ecosystem, however, does not support our workflows, and adapting it > to do that is even more effort than maintaining our own tools. We would > not even save effort in onboarding, because we'd still need to explain > the Debian specific aspects, only we would now also need to explain > which parts of the git workflow we can keep and which parts don't work > for us. That's a problem of our workflows, which are horrible. The solution is not to double down on them. Simply due to demographics, the number of people who can actually stomach them, let alone maintain them, is only ever going to shrink. > The workflows of GitHub (more deployment focused) and GitLab (more > development focused) are already different enough that I have seen > organizations struggle after making the wrong choice. Most large organizations and most distributions have additional tooling on top of git to perform certain tasks, that's really not a problem nor surprising, because it's still git and everyone understands it. Going from git push to gbp push when importing new releases is really not that disruptive. > git-buildpackage is not a good mapping of packages to git, but the best > you can do without modifying git itself. Actually using it requires more > than beginner-level knowledge of git and suspension of any previously > held convictions that every single commit should be buildable (because > gbp likes to generate ones that aren't). Only when importing new releases, so not really an issue. "Every commit builds" is a good aspiration but it is incredibly rare that it is 100% the case with no exception ever at any point in the history of a repo. > A better approach would not treat Debian metadata as git data. Even the > most vocal advocate of switching everything to Salsa writes in his MR > that the changelog should not be touched in a commit, because it creates > conflicts, and instead a manual step will need to be performed later. > > At the very least, GitLab integration would allow me to automate such a > simple thing as changelog handling in a more comfortable way than > displaying instructions how to download the conflicting branch into > local git, resolve the conflicts manually, and force-push the branch to > solve the problem. gbp dch --commit --release
[toc] | [prev] | [next] | [standalone]
| From | Simon Richter <sjr@debian.org> |
|---|---|
| Date | 2024-05-21 04:20 +0200 |
| Message-ID | <IGngB-eKU4-3@gated-at.bofh.it> |
| In reply to | #111846 |
Hi,
On 5/21/24 10:43, Luca Boccassi wrote:
>> The ecosystem, however, does not support our workflows, and adapting it
>> to do that is even more effort than maintaining our own tools. [...]
> That's a problem of our workflows, which are horrible. The solution is
> not to double down on them.
Our workflows are largely influenced by what we do here: we maintain
packages. This is different from "developing software", or "operating
infrastructure."
If we can improve the workflows, then I'm all for it. What does not
work, however, is to replace them with workflows from a different task.
All we are doing here is providing a mapping of the packaging workflow
onto a git software development workflow. It still remains a packaging
workflow, because the *goal* of the workflow is the completion of
packaging tasks.
Providing an implementation layer does not change the goal layer, and
GitLab does not provide any tools on the goal layer.
If we had buttons in GitLab "import new upstream release" or "show
issues affecting the stable release branch", I would consider that as
support for a packaging workflow. As it is now, GitLab only supports the
workflows that the implementation layer below the goal layer typically
uses, including workflows that break the upper layer.
>> At the very least, GitLab integration would allow me to automate such a
>> simple thing as changelog handling in a more comfortable way than
>> displaying instructions how to download the conflicting branch into
>> local git, resolve the conflicts manually, and force-push the branch to
>> solve the problem.
> gbp dch --commit --release
Where is that button in GitLab?
That's my point: GitLab is a step *back* from the commandline tools for
git integration.
Simon
[toc] | [prev] | [next] | [standalone]
| From | Luca Boccassi <bluca@debian.org> |
|---|---|
| Date | 2024-05-21 12:20 +0200 |
| Message-ID | <IGuL7-ePpi-3@gated-at.bofh.it> |
| In reply to | #111848 |
On Tue, 21 May 2024 at 03:16, Simon Richter <sjr@debian.org> wrote: > > Hi, > > On 5/21/24 10:43, Luca Boccassi wrote: > > >> The ecosystem, however, does not support our workflows, and adapting it > >> to do that is even more effort than maintaining our own tools. [...] > > > That's a problem of our workflows, which are horrible. The solution is > > not to double down on them. > > Our workflows are largely influenced by what we do here: we maintain > packages. This is different from "developing software", or "operating > infrastructure." Not really, our workflows are mainly influenced by whatever was available in the late 90s and has just kept chugging along on life support - hence FTP uploads, GPG signing tarballs, sending commands via emails. There are plenty of ways to maintain packages that do not involve any of that - see SUSE's OBS, etc. > If we can improve the workflows, then I'm all for it. What does not > work, however, is to replace them with workflows from a different task. > > All we are doing here is providing a mapping of the packaging workflow > onto a git software development workflow. It still remains a packaging > workflow, because the *goal* of the workflow is the completion of > packaging tasks. > > Providing an implementation layer does not change the goal layer, and > GitLab does not provide any tools on the goal layer. > > If we had buttons in GitLab "import new upstream release" or "show > issues affecting the stable release branch", I would consider that as > support for a packaging workflow. As it is now, GitLab only supports the > workflows that the implementation layer below the goal layer typically > uses, including workflows that break the upper layer. There's factually no need for any of that. As per https://trends.debian.net/ most packages today are on Salsa despite the lack of these buttons. The goal is to have an actual source code management system that allows forking, branching, rebasing, merging, navigating history, running integration tests. The fact that at some point one has to interact with crufty old ftp servers and dusty tarballs is not really relevant. Having a pipeline stage at the end of salsa-ci that does an upload for you would be a nice improvement, but it's by no means necessary to use Salsa effectively and productively, as the vast majority of cases are already showing in reality. > >> At the very least, GitLab integration would allow me to automate such a > >> simple thing as changelog handling in a more comfortable way than > >> displaying instructions how to download the conflicting branch into > >> local git, resolve the conflicts manually, and force-push the branch to > >> solve the problem. > > > gbp dch --commit --release > > Where is that button in GitLab? If that is needed, why isn't there a button on the ftp server instead of dput?
[toc] | [prev] | [next] | [standalone]
| From | Otto Kekäläinen <otto@debian.org> |
|---|---|
| Date | 2024-05-21 04:20 +0200 |
| Message-ID | <IGngB-eKU4-5@gated-at.bofh.it> |
| In reply to | #111846 |
Hi Simon! > > A better approach would not treat Debian metadata as git data. Even the > > most vocal advocate of switching everything to Salsa writes in his MR > > that the changelog should not be touched in a commit, because it creates > > conflicts, and instead a manual step will need to be performed later. Not exactly, I said it is unnecessary work and doing it will just cause more work. Exact quote: "These commits have intentionally no debian/changelog updates as it causes every single rebase or cherry-pick of a commit to always have a merge conflict. It is much better to have all commits as-is, and then right before upload just run gbp-dch --auto to automatically generate the changelog." Thus better not to inject debian/changelog changes in every single patch and instead.. > > At the very least, GitLab integration would allow me to automate such a > > simple thing as changelog handling in a more comfortable way than > > displaying instructions how to download the conflicting branch into > > local git, resolve the conflicts manually, and force-push the branch to > > solve the problem. > > gbp dch --commit --release ..just let automation handle it, like Luca and many others already know. Personally I prefer the variant `gbp dch --verbose --auto --release` but essentially it does the same thing. Anyway, thanks Simon for doing a review on https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19, at least I know you have tried using Salsa and are speaking from a point of some experience when criticising it (unlike apparently many others). Back on-topic of single-person maintainership - has anyone made a list of which packages have only *one* maintainer/git committer and are in the set of top-1000 or top-5000 Debian packages? We should perhaps ask those people why they don't have co-maintainership, and why they resist sharing the development work. Debbugs is one example - it has multiple open MRs and patches in the bug tracker but somehow the sole active maintainer does not see value in granting more people commit permissions. If we learn how these maintainers think, perhaps we can come up with a model to facilitate having more co-maintenance that can apply to the exact cases where co-maintenance is missing. - Otto
[toc] | [prev] | [next] | [standalone]
| From | Simon McVittie <smcv@debian.org> |
|---|---|
| Date | 2024-05-21 12:20 +0200 |
| Message-ID | <IGuL7-ePpi-1@gated-at.bofh.it> |
| In reply to | #111849 |
On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote:
> Exact quote: "These commits have intentionally no debian/changelog
> updates as it causes every single rebase or cherry-pick of a commit to
> always have a merge conflict. It is much better to have all commits
> as-is, and then right before upload just run gbp-dch --auto to
> automatically generate the changelog."
This is not unique to Debian packaging: upstream projects that maintain
a GNU-style ChangeLog and/or NEWS file have the same problem, for the
same reasons.
In the projects where I'm an upstream maintainer, we've generally solved
this by having the detailed ChangeLog either auto-generated from `git log`
at release time or not existing at all, and writing a more user-facing
summary of changes into the NEWS file periodically during development
(generally pushed directly by a maintainer rather than going via a merge
request, because adding text to NEWS hopefully can't cause regressions),
and in particular ensuring NEWS is up-to-date as part of the release
procedure (a maintainer/release manager responsibility).
Using `gbp dch` to maintain debian/changelog is analogous to that
technique - the version auto-generated from `git log` acts as a first
draft, and if a contributor wants to adjust the wording used in
debian/changelog to be less about fine-grained technical details and
more user-facing, they can use `gbp dch` to summarize all changes up
to now, make the desired adjustments, `git commit -m 'Update changelog'`
and push. Next time the changelog needs to be updated, `gbp dch` will
start from just after the most recent change that touched
debian/changelog.
smcv
[toc] | [prev] | [next] | [standalone]
| From | Russ Allbery <rra@debian.org> |
|---|---|
| Date | 2024-05-21 04:30 +0200 |
| Message-ID | <IGnqh-eKXS-1@gated-at.bofh.it> |
| In reply to | #111845 |
Simon Richter <sjr@debian.org> writes: > A better approach would not treat Debian metadata as git data. Even the > most vocal advocate of switching everything to Salsa writes in his MR > that the changelog should not be touched in a commit, because it creates > conflicts, and instead a manual step will need to be performed later. This is not a Debian-specific problem and has nothing to do with any special properties of our workflows or differences between packaging and other software maintenance tasks. It's a common issue faced by everyone who has ever maintained a software package in Git and wanted to publish a change log. There are oodles of tools and workflows to handle this problem, ranging from writing the change log based on the Git commits when you're making the release to accumulating fragments of release notes in separate files and using a tool to merge them. dch's approach of using the Git commit messages is one of the standard solutions, one that will be familiar to many people who have faced this same problem in other contexts. The hard part with these sorts of problems is agreeing on the tool and workflow to use to solve it, something Debian struggles with more than most software projects because we lack a decision-making body that can say things like "we're going to use scriv" and make it stick. But that isn't because packaging is a special problem unsuited to Git. Git has a rich ecosystem with many effective solutions to problems of this sort. It's because we've chosen a governance model that intentionally makes central decision-making and therefore consistency and coordination difficult, in exchange for other perceived benefits. -- Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
[toc] | [prev] | [next] | [standalone]
| From | Andreas Tille <andreas@an3as.eu> |
|---|---|
| Date | 2024-04-10 22:50 +0200 |
| Message-ID | <IrN3j-5pSd-3@gated-at.bofh.it> |
| In reply to | #111398 |
Hi Wookey,
Am Tue, Apr 09, 2024 at 05:52:43PM +0100 schrieb Wookey:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow.
I started packaging with VCS in 2007i. Thanks to some Debian Med team
members (mainly Charles Plessy) I was convinced to us SVN first and
later I was moved to Git (yes, I *was* moved ;-) ). I'm extremely happy
that I followed my team mates and could not imagine to move back.
> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it after I'm satisfied that it works. But I
> don't know that until I've made a whole set of changes and it builds.
Seems like a matter of style. My team mates are accepting commits that
are not perfect and fixed later in another commit. The great thing is
that I get some proof whether my commits are working after pushing to
Salsa thanks to Salsa CI.
> So now I've got a pile of changes which should really be separate
> commits and logically separate things often affect the same files, and
> even the same lines, so really I need to commit some chunks and not
> others and tidy it all up. Yes this makes a nice set of commits but
> it's _so_ much work in comparison to just editing the damn files, and
> then effectively doing one fat 'commit' when I dupload.
I do not think everybody expects you to follow the gold standard if Git
commits. If it makes you more productive nobody will blame you about
some fat commits.
> Sometimes git is useful - I do use it quite intensively for things
> where it actually helps (complicated cave survey datasets with
> hundreds of entangled commits that need re-ordering). For the vast
> majority of my debian packaging it's just makework.
It might be that your debian packaging is different to what I'm doing
but I do not share this experience.
> I realise this (like my previous message) will result in a load of
> people telling me git _is_ better and I'm just doing it wrong, or
> should learn better tools. And they may even be right, (and I will
> probably learn some things from this thread), but I don't believe the
> goal we agree on (fixing other people's packages should be culturally
> accepted) _requires_ this change in tooling (which is a heavy cost for
> at least some of us).
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git. We simply have no idea what amount
of new contributors we might scare away due to sticking to habits that
feel old fashioned to those people.
> The point here is that 'requiring salsa' is actually code for 'no,
> you can't just use the tarball-based VCS any more - you have to use
> git'. Removing that interface is a very big deal - it has served
> quite well for 30 years. Yes it old-fashioned and crufty and
> (presumably) only a minority still use it as the primary interface,
> but any GR on this should acknowledge what we are requiring of people
> still using it, not just frame this as 'and add salsa'. It's more
> fundamental than that (or I am misunderstanding)..
I'm using a workflow based on git-buildpackage with pristine-tar. This
is a great wrapper for the tarball-based workflow.
> Also what do you git people do to replace uscan?
Nothing. I'm using uscan. When I realised that I'm doing always the
same for new upstream versions I wrote some semi-automated tool
routine-update which calls uscan, cme, janitor tools and is possibly the
reason why I was able to maintain the majority of packages of R pkg team
alone. Sometimes I have 4-6 xterms open with running routine-update at
the same time. Doing things semi-automated is dangerous to some extend
- thus I consider Salsa CI a great second pair of eye-balls. Without
this toolset I could not manage all this.
> Currently I go to my
> existing version, or a newly-acquired apt get or dget source. I do
> 'uscan' and if there is a new upstream version I have a nice separate
> directly that is easy to dirdiff (then fixup any packaging and
> dupload). If there isn't I can move on.
I usually keep copies of most of my packaging git repositories on my
local disk. So my workflow is checking some list of packages that need
an upgrade (we update such lists in some teams twice a day). Than I move
to the local repository, run
routine-update
(works without interaction in about >80%, depending from the team)
dput
> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream,
No. There are tag based workflows (as far as I know in openstack team)
which I personally do not understand. I'm exclusively using tarball
based workflow. When creating a new package starting with importing an
upstream tarball as first commit in a fresh repository (as I've shown in
several live packaging workshops for instance at DebConf23). I create a
local repository and a script that moves this to Salsa.
> then pull them,
> maybe into different branches,
git-buildpackage maintains two or three branches: The main packaging
branch and an upstream branch. The pristine-tar branch is optional (but
default in the teams I'm working in) and just keeps the needed
metainformation to create a byte identical tarball as downloaded by
upstream. Maintaining these are no-brainers and done automatically by
git-buildpackage (wrapped by routine-update).
> and fight the diff config to let me
> dirdiff two different commits. And the upstream pull will always pull
> changes, not just only do it is there is an actual release (tag).
I need to admit I do not understand what you mean since I never had
to deal with those things.
> None of that feels like an improvement over 'uscan'. One word for the
> standard process of updating to a new version. And if the patches
> still apply it's probably all done (I always do a meld review too to
> see what changed).
As I said routine-update is using `uscan` and checks whether patches
apply cleanly. If not it stops and tells me I need to adjust patches.
It also detects if there is just fuzz in patches, tells me to unfuzz
this in some separate terminal and continues once I confirm this is
done.
> And I do just prefer having two directories rather than multiple
> version on top of each other. My simple brain finds it a lot easier to
> keep track of a version directory to diff between, rather than finding
> the right runes to get git to give meld faked-up directories pointing
> at revisions or branches.
That's probably a matter of taste. For me its definitely not
outweighting the advantages I mentioned above.
> If someone can make a tool so that this workflow still works, but a
> copy gets dumped into salsa, then I don't mind this new
> requirement. But otherwise it seems like a big imposition.
You can simply unpack your old and the new upstream tarball and do
dirdiff as you want. Or am I missing something?
> I do understand the argument that lots of different workflows adds
> friction. But I'm just still using what used to be _the_ standard one
> (insofar as we ever had such a thing). Putting everything in salsa/git
> doesn't standardise workflows in itself. I think Ian/Sean identified 12
> different git-based methods in their dgit review.
I agree that different workflows are not helpful. We have DEP14[1]
... but we have no efficient processes to
a) accept DEPs
b) dedicate to accepted DEPs
> Josch's suggestion that just recording the workflow in metadata would
> be useful is a good one. Then at least you know what other maintainers
> are doing. And dgit's approach of unifying the archive representation
> and the git representation is definitely progress in the right
> direction. I was very sad to find that it didn't help us 'tarball
> people' directly at all (except I guess to reduce exactly this
> pressure to stop doing it and use git).
I need to admit I'm not actively using dgit thus can't comment on this.
But I consider myself a member of the group of 'tarball people'. I'm
old enough to stick to conservative habits. The good thing of mentoring
lots of newbies is that I learned a lot from them myself how to make
my workflow way more efficient.
> So why mandate salsa rather than make dgit more official? That lets
> the people that want to use git use it for everything - even the
> packages that were just uploaded as tarballs. And explicitly _doesn't_
> remove the archive VCS interface. And it supports all the git-based
> workflows. (someone should probably tell IWJ this conversation is
> occuring as he's taken a bit intererest in it, but no longer reads
> debian-devel). Does than not solve a good chunk of this 'make it easy
> to fix other packages using your standard tools' desire?
As I said I'm lacking the expertise to compare my Salsa -
gbp-buildpackage - workflow to some workflow with dgit. Refusing some
common hosting platform simply does not work for Debian wide changes
(Janitor and potential other tools which might help in transitions), no
Salsa CI and other things that are simply not possible for packages
outside Salsa.
As last remark I'd like to say again thank you to my team mates who
convinced me in 2007 (according to team metrics) to start with some VCS
based workflow which finally enabled me to become as productive as I am
now (despite I was arguing probably for 2-3 years the very same way as
you did above. ;-) ).
Kind regards
Andreas.
[1] https://dep-team.pages.debian.net/deps/dep14/
--
https://fam-tille.de
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | linux.debian.devel
csiph-web