Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #111354 > unrolled thread

Re: finally end single-person maintainership

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.

Contents

  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 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

#111796 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Hi all,

In this discussion about mandating things, I've been wondering....

On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
>   * mandate VCS-tracking
>     * Yes
>   * mandate the use of one specific VCS
>     * Yes: git

What do people think this should mean, a *should* or *must* in policy? 
That the package has a RC bug if the packaging isn't tracked in git? And 
if the packaging is in git but I forgot to push my latest changes to the 
documented git server (this happens regularly to me as I do most uploads 
with dgit)? RC? In all suites where the packaging version isn't pushed 
for? And how about NMU's? (I just checked a random package without git: 
aspell-am, last non-NMU upload was in 2013)?

If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the 
person that did the changes, (and has nice local commits) somehow isn't 
available, will the package (if not key) be auto-removed? Or can 
everybody fix the repo? What if you don't have write access to the 
existing repo? And then what if the uploader comes back and tries to 
push the real history? What if my harddisk with local changes crashes 
before I push (again, I forget that sometimes, but for me luckily dgit 
will mostly have the commits).

Or is this "just a bug", maybe even at level important, but no other 
consequences. Than I think this discussion is going to be moot. I don't 
think there's much forcing possible and I think most already agree that 
stuff *should* be in VCS, so this isn't going to change for those in 
favor. And does it really add enough value if those that are forced are 
just going to do "gbp import-dsc" for each upload to the archive on a 
./debian only repository? Because that (or better) we could already 
automate (see also my PS).

I'm against mandating ("must"). I think there's a large majority (maybe 
even consensus) that believe you *should* have the packaging in VCS (and 
I agree with that). Most packages already are (hopefully maintained) in 
git (93% for testing) [1] on salsa (86%) [2], so I propose we stop the 
discussion. I think what pere did [3] changed more than this whole 
discussion: already 45 *orphaned* packages converted to git by 25 April, 
which means my numbers above are on the low side. The remaining 438 QA 
maintained (!!??) packages constitute close to 20% of the packages not 
in git.

Paul

PS: I've always wondered if the dgit server shouldn't track history, 
even if uploads don't happen via it. A dgit clone could (should?) 
already provide available history, even if no upload happened via it yet.

[1] https://trends.debian.net/vcs_testing-stacked.png
[2] https://trends.debian.net/vcs-hosting_testing-stacked.png

[toc] | [prev] | [next] | [standalone]

#111797 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Two mistakes spotted ....

On 19-05-2024 10:05 a.m., Paul Gevers wrote:
> I think there's a large majority (maybe 
> even consensus) that believe you *should* have the packaging in VCS

I meant "at least should", as in "should or must".

> I think what pere did [3]

[3] 
https://people.skolelinux.org/pere/blog/45_orphaned_Debian_packages_moved_to_git__391_to_go.html

Paul

[toc] | [prev] | [next] | [standalone]

#111799 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Quoting Paul Gevers (2024-05-19 10:05:38)
> In this discussion about mandating things, I've been wondering....
> 
> On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
> >   * mandate VCS-tracking
> >     * Yes
> >   * mandate the use of one specific VCS
> >     * Yes: git
> 
> What do people think this should mean, a *should* or *must* in policy? 
> That the package has a RC bug if the packaging isn't tracked in git? And 
> if the packaging is in git but I forgot to push my latest changes to the 
> documented git server (this happens regularly to me as I do most uploads 
> with dgit)? RC? In all suites where the packaging version isn't pushed 
> for? And how about NMU's? (I just checked a random package without git: 
> aspell-am, last non-NMU upload was in 2013)?
> 
> If *must* and thus RC, can the issue be fixed by "NMU"? I.e. if the 
> person that did the changes, (and has nice local commits) somehow isn't 
> available, will the package (if not key) be auto-removed? Or can 
> everybody fix the repo? What if you don't have write access to the 
> existing repo? And then what if the uploader comes back and tries to 
> push the real history? What if my harddisk with local changes crashes 
> before I push (again, I forget that sometimes, but for me luckily dgit 
> will mostly have the commits).
> 
> Or is this "just a bug", maybe even at level important, but no other 
> consequences. Than I think this discussion is going to be moot. I don't 
> think there's much forcing possible and I think most already agree that 
> stuff *should* be in VCS, so this isn't going to change for those in 
> favor. And does it really add enough value if those that are forced are 
> just going to do "gbp import-dsc" for each upload to the archive on a 
> ./debian only repository? Because that (or better) we could already 
> automate (see also my PS).

With "mandate" I do not mean kick out if non-compliant.  Same as we (as
far as I am aware) mandate declaring Poilcy version followed by a
package, but don't kick out packages having mismatching declaration or
not following latest policy.

I think there is a big difference between saying that Salsa (or git, og
Debbugs, or public-wide WNPP work tracking) is an optional addon to
Debian, to saying that it is expected of everyone (i.e. you are being
asocial if you don't, and can expect your behavior being discussed as a
public-wide issue for the project).

So I disagree that tool-use severity of "important" makes progress moot.

I have met developers who have the view that we are already at the point
of non-use of Salsa being asocial behavior, and had at least one very
interested (and calm) exchange of such differing views at Debconf in
Kosovo.  Deciding project-wide where we are on that scale do help, I
think.


> PS: I've always wondered if the dgit server shouldn't track history, 
> even if uploads don't happen via it. A dgit clone could (should?) 
> already provide available history, even if no upload happened via it yet.

All the points that I listed are all about optional/expected/required
*contributor* streamlining.

If I understand your comment above about dgit correctly, it is about
automation of history tracking, which is (mostly) orthogonal to
*contributor* streamlining.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#111800 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
  finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200):


> i.e. you are being
> asocial if you don't, and can expect your behavior being discussed as a
> public-wide issue for the project).

I very much agree with all what you say, however could we rather say instead

-> i.e. you are not being collaborator friendly, and can expect your behavior be
frowned upon...

I am not a native english speaker, I think we can avoid to trap in a can of
worms with problematic terms like 'asocial, unsocial, anti-social...' which
could have quite special meanings in different cultures.

Best,
Mathias

-- 

    Mathias Behrle
    PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
    AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6

[toc] | [prev] | [next] | [standalone]

#111801 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Quoting Mathias Behrle (2024-05-19 11:08:58)
> * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
>   finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200):
> 
> 
> > i.e. you are being
> > asocial if you don't, and can expect your behavior being discussed as a
> > public-wide issue for the project).
> 
> I very much agree with all what you say, however could we rather say instead
> 
> -> i.e. you are not being collaborator friendly, and can expect your behavior be
> frowned upon...
> 
> I am not a native english speaker, I think we can avoid to trap in a can of
> worms with problematic terms like 'asocial, unsocial, anti-social...' which
> could have quite special meanings in different cultures.

Thanks for raising awareness to this.  I was unaware that "asocial" was
disruptive to the conversation, but indeed danish dictionaries (I am no
native english speaker either) flag that word as condescending.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#111859 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote:

>
> PS: I've always wondered if the dgit server shouldn't track history, even if
> uploads don't happen via it. A dgit clone could (should?) already provide
> available history, even if no upload happened via it yet.

Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
history.  So it sort of does this.  We could make it do more.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#111903 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Hi

On 21-05-2024 1:08 p.m., Sean Whitton wrote:
>> PS: I've always wondered if the dgit server shouldn't track history, even if
>> uploads don't happen via it. A dgit clone could (should?) already provide
>> available history, even if no upload happened via it yet.
> 
> Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
> history.  So it sort of does this.  We could make it do more.

Huh. Than my workflow hides this. All I'm often seeing is just the tar 
content represented in a commit, the latest Debian packing in another 
and the merge of these two (if I recall and describe what I recall 
correctly). I always thought that dgit clone generated that on my 
computer if there was no git content on the dgit server. I'll try to 
remember this next time I run my no-changes-source-only upload script.

Paul

[toc] | [prev] | [next] | [standalone]

#111909 — Re: dgit view of packages' history

On Wed, 22 May 2024 at 21:55:15 +0200, Paul Gevers wrote:
> On 21-05-2024 1:08 p.m., Sean Whitton wrote:
> > > PS: I've always wondered if the dgit server shouldn't track history, even if
> > > uploads don't happen via it. A dgit clone could (should?) already provide
> > > available history, even if no upload happened via it yet.
> > 
> > Well, 'dgit clone' adds a vcs-git remote pointing at the maintainer's
> > history.  So it sort of does this.  We could make it do more.
> 
> Huh. Than my workflow hides this. All I'm often seeing is just the tar
> content represented in a commit, the latest Debian packing in another and
> the merge of these two (if I recall and describe what I recall correctly). I
> always thought that dgit clone generated that on my computer if there was no
> git content on the dgit server. I'll try to remember this next time I run my
> no-changes-source-only upload script.

I believe the 3-commit orig + packaging + merge (vaguely similar to what
you would get from `gbp import-dsc` into an empty repository) is what you
get if the most recent upload was not made with dgit, and therefore does
not have the Dgit field in its `apt-cache showsrc` record.

This means that dgit might know what repository the maintainer uses to
store their idea of the packaging (it can get this from Vcs-Git), but it
does not know which specific commit in that repository is the equivalent
of what's in the archive, or which of the various possible workflows
the maintainer uses to get from that commit to an uploadable .dsc - and
therefore it doesn't have a particularly good way to glue the maintainer's
git history into the ancestry of the commit that it generates.

If you look at GNOME team packages, packages that were most recently
uploaded by me generally do have a Dgit field[1], and packages that were
most recently uploaded by another team member often do not. At the time
of writing, gtk4/unstable was uploaded with dgit, but gtk4/experimental
was not - that might make a useful comparison?

I use the dgit-maint-gbp workflow myself, so the dgit history contains a
transformation from the format used in our team VCS, which dgit calls the
"maintainer view" (in the GNOME team this is gbp-style patches-unapplied)
to dgit's canonicalized view (which is patches-applied, because that's
what the designers of dgit have chosen to canonicalize into).

A nice thing about dgit-maint-gbp is that my co-maintainers don't need
to agree with me, and can continue to use gbp + debsign + dput, or
quilt + debsign + dput, or construct patches in any other compatible way:
as long as we agree on the desired source tree, we can interoperate.

    smcv

[1] except for -security uploads

[toc] | [prev] | [next] | [standalone]

#111815 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
>
> I agree, that's the key problem.

I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.

> > ...instead of lumping all those discussions into a discussion of ease of
> > user interface for a single catch-all code forge that maybe make all those
> > other complications go away by affecting all those questions and that way
> > implicitly provides *some* answer to them all.
>
> Also, there is a difference between ease of use and intuitivity. GitLab
> does not provide any tools that really make packaging easier. It is
> initially more accessible to non-maintainers, because of familiarity,
> but actual work happens outside of it.

Would you be kind and try to understand the opposing viewpoint by
trying it for one day?

You could go to
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
conduct a code review?

You might discover that GitLab is useful and is not duplicating
Debbugs or anything else in Debian - it is currently the only platform
to conduct code reviews on in a way that has automatic testing and
comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.

If you try it out, and still think Salsa is bad for Debian, then I am
more willing to accept your stanze.


- Otto

[toc] | [prev] | [next] | [standalone]

#111816 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Quoting Otto Kekäläinen (2024-05-19 21:32:36)
> > > My concern about Gitlab is not its *additions* to existing services, but
> > > its *duplications* of core services already in Debian.
> >
> > I agree, that's the key problem.
> 
> I agree that duplication is bad - but I disagree that use of version
> control duplicates the use of the Debian archive for source code
> storage, or that use of GitLab for code reviews would duplicate
> Debbugs.
> 
> > > ...instead of lumping all those discussions into a discussion of ease of
> > > user interface for a single catch-all code forge that maybe make all those
> > > other complications go away by affecting all those questions and that way
> > > implicitly provides *some* answer to them all.
> >
> > Also, there is a difference between ease of use and intuitivity. GitLab
> > does not provide any tools that really make packaging easier. It is
> > initially more accessible to non-maintainers, because of familiarity,
> > but actual work happens outside of it.
> 
> Would you be kind and try to understand the opposing viewpoint by
> trying it for one day?
> 
> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?
> 
> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian - it is currently the only platform
> to conduct code reviews on in a way that has automatic testing and
> comment-response-resolved -tracking. Doing code reviews patches
> attached in email does not have that.
> 
> If you try it out, and still think Salsa is bad for Debian, then I am
> more willing to accept your stanze.

But it *is* duplicating Debbugs: None of your valuable contributions
posted as part of your code review appears on Debbugs.

The developers of FreedomBox (which is a Debian Pure Blend, i.e. a
project fully within Debian) has embraced Salsa, and when I asked about
an issue with network instability for certain hardware, I was told that
it was in the issue tracker - which meant it was missing from Debbugs
while actively discussed in Salsa.

Salsa is *great* if you fully embrace it. Salsa is not good if you want
single features without fully embracing it.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/
 * Sponsorship: https://ko-fi.com/drjones

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

#111818 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Thanks for reply Jonas,

> > You could go to
> > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> > conduct a code review?
> >
> > You might discover that GitLab is useful and is not duplicating
> > Debbugs or anything else in Debian - it is currently the only platform
> > to conduct code reviews on in a way that has automatic testing and
> > comment-response-resolved -tracking. Doing code reviews patches
> > attached in email does not have that.
> >
> > If you try it out, and still think Salsa is bad for Debian, then I am
> > more willing to accept your stanze.
>
> But it *is* duplicating Debbugs: None of your valuable contributions
> posted as part of your code review appears on Debbugs.

Actually some of them are in Debbugs as patches, but hard to find as
there are 200+ open bugs.
However, the bugs.debian.org system does not offer code testing or
review facilitation.

Again, I invite you to test out
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 for
_code review_ for the same reason I stated above.

[toc] | [prev] | [next] | [standalone]

#111821 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi,

On 5/20/24 04:32, Otto Kekäläinen wrote:

> I agree that duplication is bad - but I disagree that use of version
> control duplicates the use of the Debian archive for source code
> storage, or that use of GitLab for code reviews would duplicate
> Debbugs.

Outside of DM uploads, I'm not sure that there is much of a need for a 
code review on packaging -- really what we want is to reduce the amount 
of code for packaging, by moving it into declarative frameworks whenever 
possible, so the vast majority of packaging changes should be trivial 
ones like upgrading a dependency version.

> Would you be kind and try to understand the opposing viewpoint by
> trying it for one day?

I am using it for most of my packages. It has not made my life easier, 
it's just another layer that I need to communicate my intentions through.

I generally do test builds of my packages in a local pbuilder instance, 
with a hook script to drop me into a shell if the build fails, so the 
workspace is kept for my investigation. The only CI system that offers a 
similar feature is Jenkins, but even there I can only inspect the files 
through a clunky web interface, as soon as I need to look at a binary 
file or search for a string, I need to download it as a zipfile, and 
re-running commands inside the same environment to test them is 
completely out.

> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?

At first glance, looks good to me.

Looking at the changes:

1. The outdated build dependency is not in the package currently in 
Debian. If it was, it would have been spotted by Debian's archive 
analysis tools already, without the need for a build attempt.

This static analysis is cheaper than a rebuild, so to achieve the same 
level of coverage, Salsa would need to perform a full archive rebuild 
daily, and it would still not catch the broken Suggests: in the binary.

2. The missing file in debian/docs was already reported as #903413.

3. The other changes are "upstream" changes, which should have a 
separate CI that is more extensive than "still builds."

Native packages should only be used for things where it does not make 
sense to maintain a separate upstream package because they only exist 
within the package ecosystem, like the "menu" package. Debbugs should 
really be split into separate "upstream" and "packaging" efforts.

> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian

Well, there is an issue tracker (where tickets go unresponded for a 
year), that is certainly a duplication of debbugs. It would make sense 
to maybe track "upstream" bugs there and forward them from debbugs (a 
feature not present in GitLab's issues handling, but important for 
package maintenance).

  - it is currently the only platform
> to conduct code reviews on in a way that has automatic testing and
> comment-response-resolved -tracking. Doing code reviews patches
> attached in email does not have that.

Well, I take the diff, prepend each line with > and insert my comments, 
then send it back. The author then responds to that email, and once the 
discussion is over, I get a new proposed patch. Not much difference.

> If you try it out, and still think Salsa is bad for Debian, then I am
> more willing to accept your stanze.

It's not *bad*, but for a lot of our workflows, it's the wrong tool 
because the use cases it was designed for are different from ours, and 
there is little we can do to make them meet.

Debian's workflow for collaboration on things that are not yet 
release-ready is clunky to the point that almost no one uses it that 
way, but in principle it is there: one can always upload a package to 
experimental and get it autobuilt on the major architectures, and other 
DDs can download it from there if they want to take a look at it.

This workflow is what packaging in git mostly replaces: in 
pkg-electronics, we quite often have changes that are not ready for 
release that we want to distribute to the other team members. Quite 
often, these changes do not build straight away, and the reason they are 
shared is specifically so other people can take a look at them.

Git is a lot better for fostering this collaboration than uploads to 
experimental, because we get change tracking for individual files, which 
is invaluable when dealing with a behemoth like ghdl that takes a few 
hours to build and run tests.

The review process still takes place via mail here, because part of the 
process is that everyone involved needs to be able to build the package 
locally and investigate failures. We can quickly incorporate changes 
from others using git and do a minimal rebuild locally, that is useful, 
but this essentially means that we are pushing commits to an offside branch.

Attaching the discussion to individual changes is not that useful for us:

1. changing an annotated line in a commit hides the annotation when 
looking at another commit, so the entire discussion would need to take 
place in the "all changes" view, or we risk losing context.

2. a lot of the discussion is "things that will need to be changed", not 
"things that have been changed and we don't like it." GitLab does not 
have a workflow for discussing that as part of a MR.

In that process, CI would only tell us that the package fails to build, 
but we already know that: that's why we shared it in this way. If it 
worked, we would have uploaded it already. Trying to build it in CI is a 
waste of four hours of CPU time, and we iterate a lot faster than that 
usually because we do incremental builds in between, and a full build 
inside pbuilder only as part of the final upload procedure.

After an upload is done, the discussion and intermediate stages become 
less useful for us, so GitLab's approach of isolating them in the MR is 
acceptable from my point of view, even if other people would like to 
have them archived in the mailing list archive so it is easily 
accessible to search engines.

Also, we usually get build failures from ports, which is kind of 
unavoidable because CI testing everywhere is prohibitively expensive, 
and the high level of optimization we need to run means that we will get 
bitten by target specific bugs. We cannot avoid uploading "broken" 
packages, unless we integrate the autobuilder network into CI and wait 
four days for jobs to finish.

What Debian does instead is to filter broken packages from reaching 
testing -- this is way stricter than any CI process on Salsa can 
provide, although with a longer turnaround time, because the CI 
processes performed by the Debian archive software take a lot longer.

This, too, is something that Salsa cannot replicate because of the way 
GitLab is designed, so it cannot supplant this process, just duplicate 
some aspects of it, so we would end up with build failure reports from 
two sources, in two different places.

There is likely a spot where collaborating on packages through MRs is 
useful, but I'd argue that the majority of packages will either get only 
trivial MRs that don't require discussion, or require workflows that 
cannot be easily mapped to MRs, and attempting to make the workflow fit 
the tool rather than the other way around will create additional 
friction here.

    Simon

[toc] | [prev] | [next] | [standalone]

#111860 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote:

> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?
>
> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian - it is currently the only platform
> to conduct code reviews on in a way that has automatic testing and
> comment-response-resolved -tracking. Doing code reviews patches
> attached in email does not have that.
>
> If you try it out, and still think Salsa is bad for Debian, then I am
> more willing to accept your stanze.

I have tried it out, and am happy for those maintainers that like it to
use it, but I do not want to maintain most of my packages that way.
I want people to send me patches to the BTS / project ML.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#111871 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

>>>>> "Otto" == Otto Kekäläinen <otto@debian.org> writes:
    Otto> Would you be kind and try to understand the opposing viewpoint
    Otto> by trying it for one day?

    Otto> You could go to
    Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
    Otto> and conduct a code review?

I have not done a code review  of that particular patch on salsa.
I have done code reviews on salsa, many other gitlabs, and github.
I find doing a code review in a web page far more frustrating than in
email.
I appreciate other people have different experience.
Some of my experience but not all is  accessibility related.

I do find that   trying to put everyone into one user interface--whether
it is github or gitlab or whatever--means some people are going to be
left out.
Interfaces like email mean that people can develop their own tooling.
And for those who do and find tooling they really like that's superior
to a common UI like gitlab for *those people*.
But it's going to be inferior for people who do not spend significant
time on tooling; for those people a common web ui is going to be
superior.

And you can say that I can use my own tooling with gitlab.
That's sort of true.  But then you or people like you will get
frustrated  that I don't interact with your per-commit-line comments
entered in the website, or go to the website to resolve comments or
whatever.
And you'll say that if I just tried the website I'd like it.
And that won't be true, because I have, I do use it in my day job, and I
don't really like it that much.

Even so, I think it is enough better that Debian should move in that
direction.

But Otto, I would encourage you to have more compassion for people who
work with the world differently than you.
In this thread, and in the krb5 merge request we are discussing, you
really do seem to be jumping to an assumption that everyone approaches
code the same way.
And you don't appear to be taking the time to understand or value how
the people you are interacting with may deal with the world differently.

Rather than simply asking people  to try out your way, I'd encourage you
to ask me and others how they deal with code and what they like about
their work flow.
I'm not going to ask you to try it out, because it probably won't work
for you.
You've found something you  think is great.
But I am going to ask you to ask and listen.

I do think we should fall in on the salsa way.  I think it will
generally be better overall.
I do think some of us will suffer as a result.

But there appears to be an assumption here that if we just all tried
this new thing it would be great.
I would appreciate compassion for our differences and for how that's
just not true.
There will be trade offs.

--Sam

[toc] | [prev] | [next] | [standalone]

#111852 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
> 
> I agree, that's the key problem.
> 
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> mandated.
The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
in which areas it's poor, and it's bad e.g. because force pushes are
enabled, the history is periodically truncated (though there is no easy
way to get it anyway) etc.
It makes sense that some people want to replace it with a good VCS, but I
agree that adding a good VCS only gives us two VCSes because replacing
will never happen.


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#111862 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

Hi,

On 5/21/24 15:54, Andrey Rakhmatullin wrote:

>> The Debian archive itself is a VCS, so git-maintained packaging is also a
>> duplication, and keeping the official VCS and git synchronized is causing
>> additional work for developers, which is why people are opposed to having it
>> mandated.

> The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> in which areas it's poor, and it's bad e.g. because force pushes are
> enabled, the history is periodically truncated (though there is no easy
> way to get it anyway) etc.

All of these things are *also* explicit features. We need a way to 
unpublish things, and mirrors only want to keep a shallow subset.

Representing the Debian archive in git would probably look like a 
massive amount of submodules, because that's the only way to represent 
state across multiple projects without extending it -- and extending is 
a big no-no, because then we'd lose all the forge support. Submodules 
cannot represent the pristine-tar branch though.

> It makes sense that some people want to replace it with a good VCS, but I
> agree that adding a good VCS only gives us two VCSes because replacing
> will never happen.

There are two axes here -- "good" and "fits the use case."

What I'm arguing is that git does not fit our use case, despite being 
good, because it is designed for something else. We can make it fit our 
use case by wrapping it, but then we have a choice between a thin veneer 
that breaks easily as people use git commands inside a source tree, when 
they should only be using gbp commands, or a completely opaque wrapper 
that loses us all the git integration from third-party tools like forges.

Because git treats packaging metadata as data, no correctness of 
metadata is enforced at this level. We could add this in the form of 
upload hooks, but then people would start complaining that they want to 
use the tools like they want. They would be wrong, but that is what 
happens with leaky abstractions.

This is the exact opposite of the mandatory-debhelper debate: requiring 
declarative packaging (and therefore calcifying all custom sequences 
into debhelper plugins) is precisely the opposite of "using git because 
it is familiar" -- the benefit of using the abstraction comes from 
denying access to the layer below and therefore hiding its complexity.

    Simon

[toc] | [prev] | [next] | [standalone]

#111863 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
> 
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> 
> > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > duplication, and keeping the official VCS and git synchronized is causing
> > > additional work for developers, which is why people are opposed to having it
> > > mandated.
> 
> > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> > in which areas it's poor, and it's bad e.g. because force pushes are
> > enabled, the history is periodically truncated (though there is no easy
> > way to get it anyway) etc.
> 
> All of these things are *also* explicit features. We need a way to unpublish
> things, and mirrors only want to keep a shallow subset.
We don't have a way to unpublish things, and force pushes I meant are
uploading things without including all previous changes, like all those
NMUs silently not included in the next maintainer uploads.
But, sure, some of the problems we have are explicitly features.

> Representing the Debian archive in git would probably look like a massive
> amount of submodules, because that's the only way to represent state across
> multiple projects without extending it 
Sorry? I don't understand what you would use submodules for. Unless you
meant literally mapping archive-as-VCS to a single literal VCS repo?


-- 
WBR, wRAR

[toc] | [prev] | [next] | [standalone]

#111867 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin <wrar@debian.org> wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > > duplication, and keeping the official VCS and git synchronized is causing
> > > > additional work for developers, which is why people are opposed to having it
> > > > mandated.
> >
> > > The Debian archive itself is a *bad* and *poor* VCS. It should be obvious
> > > in which areas it's poor, and it's bad e.g. because force pushes are
> > > enabled, the history is periodically truncated (though there is no easy
> > > way to get it anyway) etc.
> >
> > All of these things are *also* explicit features. We need a way to unpublish
> > things, and mirrors only want to keep a shallow subset.
> We don't have a way to unpublish things, and force pushes I meant are
> uploading things without including all previous changes, like all those
> NMUs silently not included in the next maintainer uploads.
> But, sure, some of the problems we have are explicitly features.
>
> > Representing the Debian archive in git would probably look like a massive
> > amount of submodules, because that's the only way to represent state across
> > multiple projects without extending it
> Sorry? I don't understand what you would use submodules for. Unless you
> meant literally mapping archive-as-VCS to a single literal VCS repo?

Yeah, I don't understand that either. It seems there is some
misunderstanding, the suggestion to use Salsa doesn't mean that the
current ftp servers are retired. It just means that Salsa is used for
sources, like it is already used in ~90% of the packages today as per
trends.debian.net. Now, whether someone wants to make tarballs and ftp
uploads happen transparently behind the curtain in a salsa-ci job or
something like that is really orthogonal to the idea that sources need
to be stored in git.

[toc] | [prev] | [next] | [standalone]

#111866 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

[Multipart message — attachments visible in raw view] — view raw

On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
> mandated.

I don't follow this conclusion because the premise "the Debian archive itself is
a VCS" is as right or wrong as the statements "earth is clock" or an "ocean is a
washing machine".

Or, to put it differently, "vi $file ; cp $file $file.bak ; vi $file" is also 
a VCS, but an even poorer one than the Debian archive.

Just because something has some VCS like properties it doesn't make it a VCS
as in the sense as people understand it in 2024.

IMO (very few) people object using a(n official) VCS is because it would change
their workflows and/or because they believe their needs are more important than
our needs. And saying "the Debian archive is a VCS and that causes conflicts
with another VCS" is a red herring at best, because as dak+git or dak+vim+copy
shows (or gosh, using different git repos) that using several VCS is possible and
done by millions daily.


-- 
cheers,
	Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

It's not climate change nor climate crisis, it's climate disaster.

[toc] | [prev] | [next] | [standalone]

#111812 — Re: Salsa - best thing in Debian in recent years? (Re: finally end single-person maintainership)

On Sat, May 18, 2024 at 08:25:10PM -0700, Otto Kekäläinen wrote:
> Hi Bill and Wookey!
> 
> In a recent long thread on debian-devel you had somewhat negative
> sentiments towards the usefulness of Salsa.

I am not sure this characterize my position. I have no opposition to
Salsa (even though it is missing features Alioth had I relied on),
I am opposed to be forced to use it when it just increases
bureaucracy.

> I do see you doing good
> technical work for Debian and recently a MR from Bill too, so I was
> thinking that maybe you will change your mind when you read more
> in-depth arguments. This is my attempt to have you think about Salsa
> in a new light:
> 
> On Tue, 9 Apr 2024 at 11:41, Bill Allombert <ballombe@debian.org> wrote:
> > Having a repository on salsa or even "packaging team" does not prevent
> > a lack of maintainer, so this is not relevant.
> > Without a maintainer, no contribution will be merged in any case.
> 
> Consider this Merge Request to fix debbugs builds immediately, and to
> include Salsa-CI to keep the build from regressing again:
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19

debbugs is a Debian-native package. So of course it needs an upstream git
repository.  All my Debian-native packages are maintained on Salsa (and before
Salsa on Alioth).

The MR I did was for lintian which is also Debian-native.

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.
Ideally debbugs should be made non-native so that some else could maintain the
Debian package.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here. 

[toc] | [prev] | [next] | [standalone]

Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6  Next page →

Back to top | Article view | linux.debian.devel

csiph-web