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

#111413

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

Quoting Andreas Tille (2024-04-10 22:44:25)
> > 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

or teach gbp about DEP14. See this git-buildpackage bug from *six* years ago:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444

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

#111900

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

Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Quoting Andreas Tille (2024-04-10 22:44:25)
> > > > 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
> > 
> > or teach gbp about DEP14. See this git-buildpackage bug from *six*
> > years ago:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
> 
> DEP14 is a candidate, I can't see that there was any consensus to accept it.
> Just because there is a DEP there is no need to implement it without having
> any consensus on it.

the current gbp defaults were also implemented without any consensus on them,
so in that regard, embracing DEP14 would not make the situation worse.

What is improved by DEP14 is that in contrast to the current gbp defaults, it
is backed up by a write-up of advice, best-practices and recommendations. We
should have more of these write-ups for the things we do. This would also make
it easier for new contributors to get into Debian.

Thanks!

cheers, josch

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

#111434

On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille <andreas@an3as.eu>
wrote:
>'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. 

That does not only apply to young contributors. I am an old fart and I
still shy back from packages where I need to familiarize myself with
an uncommon packaging toolchain.

>> 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 not (any more?) default in the tools, thus easily forgotten.

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]

#111435

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

Hi,

On 13.04.24 00:19, Marc Haber wrote:

>> '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.

> That does not only apply to young contributors. I am an old fart and I
> still shy back from packages where I need to familiarize myself with
> an uncommon packaging toolchain.

We cannot help people who want Debian packaging to work like Git, 
because Git is not a packaging tool, and neither are the forges.

We're not even doing anyone a favour by introducing the git based 
workflows first, because about half of the techniques people know from 
git will conflict with something git-buildpackage or dgit does, and 
without a mental model of how Debian packaging is supposed to work 
standalone, they have no chance of solving even the simplest problem.

For example, any repository that does not list debian/files and 
debian/*.substvars in the gitignore will fail to build twice in a row, 
because these files are created and are subsequently untracked. Only 
Debian packaging knowledge can tell you that these should never be 
checked in and can be ignored -- or we make people reliant on a magic 
tool to set it up properly for them.

Once people are familiar with how Debian packaging works, we can 
introduce the git interfaces on top. Before that, git is more of a 
hindrance than a benefit to new contributors, precisely because it looks 
familiar, but the knowledge is not transferable.

    Simon

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

#111436

On Fri, 12 Apr 2024 at 17:17, Simon Richter <sjr@debian.org> wrote:
>
> Hi,
>
> On 13.04.24 00:19, Marc Haber wrote:
>
> >> '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.
>
> > That does not only apply to young contributors. I am an old fart and I
> > still shy back from packages where I need to familiarize myself with
> > an uncommon packaging toolchain.
>
> We cannot help people who want Debian packaging to work like Git,
> because Git is not a packaging tool, and neither are the forges.
>
> We're not even doing anyone a favour by introducing the git based
> workflows first, because about half of the techniques people know from
> git will conflict with something git-buildpackage or dgit does, and
> without a mental model of how Debian packaging is supposed to work
> standalone, they have no chance of solving even the simplest problem.
>
> For example, any repository that does not list debian/files and
> debian/*.substvars in the gitignore will fail to build twice in a row,
> because these files are created and are subsequently untracked. Only
> Debian packaging knowledge can tell you that these should never be
> checked in and can be ignored -- or we make people reliant on a magic
> tool to set it up properly for them.
>
> Once people are familiar with how Debian packaging works, we can
> introduce the git interfaces on top. Before that, git is more of a
> hindrance than a benefit to new contributors, precisely because it looks
> familiar, but the knowledge is not transferable.

New contributors won't start in a vacuum, most will start contributing
first to existing projects on Salsa, which are already set up and
configured to do what is needed, if it is needed. Git is the bare
minimum these days, and has been for years. Salsa is the best thing
that has happened to Debian the past decade, and the Salsa team will
forever have my gratitude for the great job they have done and
continue to do.

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

#111442

> New contributors won't start in a vacuum, most will start contributing
> first to existing projects on Salsa

Or maybe they start with an ITP+RFS… was that an informed statement or a 
supposition?

-- 
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
                -- Galileo Galilei

https://ltworf.codeberg.page/

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

#111443

On Sat, 13 Apr 2024 at 10:11, Salvo Tomaselli <tiposchi@tiscali.it> wrote:
>
> > New contributors won't start in a vacuum, most will start contributing
> > first to existing projects on Salsa
>
> Or maybe they start with an ITP+RFS… was that an informed statement or a
> supposition?

It is my experience in receiving patches from non-project members. It
is also my experience that every such contributor I talked to rated
the ITP/RFS and other mail-based bug reporting on a range from
hilarious (in a bad way, as in: "it's 202x and you still do that?
seriously?") to infuriatingly frustrating and confusing.

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

#111439

Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
> 
> For example, any repository that does not list debian/files and
> debian/*.substvars in the gitignore will fail to build twice in a row,
> because these files are created and are subsequently untracked.

Sorry, no.  We should teach people to build in a chroot which does
not leave this stuff inside local debian/ dir.

> Once people are familiar with how Debian packaging works, we can introduce
> the git interfaces on top. Before that, git is more of a hindrance than a
> benefit to new contributors, precisely because it looks familiar, but the
> knowledge is not transferable.

>From my mentoring work I can confirm this sequence is not necessary for
everyone.  You might have different experience, but I would not subscribe
this as a general rule.

Kind regards
    Andreas.

-- 
https://fam-tille.de

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

#111440

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

On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
> > 
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these files are created and are subsequently untracked.
> 
> Sorry, no.  We should teach people to build in a chroot which does
> not leave this stuff inside local debian/ dir.

True. Or add relevant files and stash (which is what I do for non-chroot
builds).

> > Once people are familiar with how Debian packaging works, we can introduce
> > the git interfaces on top. Before that, git is more of a hindrance than a
> > benefit to new contributors, precisely because it looks familiar, but the
> > knowledge is not transferable.
> 
> >From my mentoring work I can confirm this sequence is not necessary for
> everyone.  You might have different experience, but I would not subscribe
> this as a general rule.

To add in more perspective to it -- I started contributing to debian in 2019. I
don't think I would have the motivation to contribute further had it not been
for a git based workflow and salsa. In the sense that it'd have made it an
uphill journey for me to know how to send patches. Git was something I was
familiar with so I did not have to spend time struggling with basic things.

Like Andreas, I have mentored many new comers too, advocated them to be DMs/DDs
and I never found any of them complaining about git workflow so what is quoted
above is not true as a general rule.

People who did debian packaging without git for a long time and then had to
switch/use a git based workflow might find it a little counter-intuitive which
also stems from the fact that people generally resist change. But the same is
not necessarily true for new contributors.

On Sat, Apr 13, 2024 at 01:16:37AM +0900, Simon Richter wrote:
> We're not even doing anyone a favour by introducing the git based workflows
> first, because about half of the techniques people know from git will
> conflict with something git-buildpackage or dgit does, and without a mental
> model of how Debian packaging is supposed to work standalone, they have no
> chance of solving even the simplest problem.

I did not have a solid understanding of how debian packaging works standalone,
and had only very little idea about most of the things when I started -- it only
gets better with time.
But I believe I did solve at least some simple problems to qualify for
becoming a DD :-)

Best,
Nilesh

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

#111441

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

On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these files are created and are subsequently untracked.
> 
> Sorry, no.  We should teach people to build in a chroot which does
> not leave this stuff inside local debian/ dir.
I was afraid that's what "or we make people reliant on a magic tool to set
it up properly for them" means.
(technically, the way to not touch the workdir at all is gbp's
--export-dir, which *is* a magic mode of a magic tool in the world where
neither are parts of the default workflow but at the same time it's so
much better than not doing this)

-- 
WBR, wRAR

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

#111412

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

On Tue, 09 Apr 2024 17:52:43 +0100, Wookey wrote:

> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to
> > commit everything into git first, so I have to remember to squash all these
> > commits later.
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow. I want to make changes and
> 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.

In my git workflow I never make a commit when I first want to try
something out; specifically with git-buildpackage:

% cat ~/.gbp.conf 
…

[buildpackage]
…
export = WC


("WC" as in "working copy", i.e. the directory as it is right now).

> 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'.

Currently many people and teams still start from tarballs even when
using git, via the pristine-tar tool and a pristine-tar branch.

> Josch's suggestion that just recording the workflow in metadata would
> be useful is a good one.

Here I disagree because I remember that we (pkg-perl) had to put
hundreds of README.source files into packages saying "This package
uses quilt, quilt documentation is $over_there" because policy
mandated it; and a few years later we removed them again after a
policy change (or was it the switch to source format "3.0 (quilt)"?).
So please no README.source with "This package used gbp with
patches-unapplied and yadda yadda".


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]

#111364

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

On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
> 
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
> 
> OK, moving the discussion to debian-devel where it should belong.
> 
> > Debian packages need to be well maintained. In some cases, having
> > multiple maintainers on a package improves the resulting quality of
> > packages. But in some other cases, it does not; one example for this
> > second case is my package "logtool", which I'm going to upload to fix
> > #1066251 soon and for which by the simple act of doing that I will
> > double the amount of uploads it's seen in the past five years (and the
> > number of uploads in the past 10 can still be counted on the fingers of
> > a single hand).
> > 
> > This is not because it's not well maintained; it's because the package
> > just *does not require* a lot of work to be kept up to date: upstream
> > has not been active for over 20 years, but it still performs the job it
> > was designed to do, as it was designed to, and I see no need to have it
> > removed from the archive.
> 
> What is your opinion about pushing logtool to Salsa?

Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.

Forcing people to waste time creating a salsa project, a git repository etc.
to maintain what is effectively a debian/rules that can be summarised by "dh:"
does not serve any purpose. 'git log' is just redundant with debian/changelog.
If you want the source of a package, 'apt-get source' should suffice.

Most of the actual packager work is not reflected in the source package.
Testing that the package integrates well with the rest of Debian,
replying to bug reports, communicating with upstream etc.
The more we waste time with bureaucracy the less we have time for actual
work.

For some of my packages I have a tool that generates the debian directory
from the upstream metadata, so all packages debian/ are similar looking.
Storing the output of this tool in separate git repo for each packages would be 
a absolute waste of resources.

Also on a large timescale, our infrastructure change. We move from one VCS to
another, to one service to another etc. and then repository need to be moved.
It takes time.

I maintain a number of packages. Some are on Salsa, some are not, some are team
maintained, some are not, some use dh, some use debhelper etc.  
This is a matter of efficiency, one size does not fit all.

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

Imagine a large red swirl here. 

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

#111365

On 07/04/24 23:11, Bill Allombert wrote:
>> What is your opinion about pushing logtool to Salsa?
> 
> Not speaking for logtool obviously, but maintaining simple packages on salsa is
> just useless bureaucracy.

As a contributor, having a package on salsa is extremely useful, far 
from "useless".

By clicking on "fork" (or running the equivalent CLI command) I get a 
copy of the package, with all its history, a Debian-specific CI, the 
ability to work on different features or bug fixes at the same time and 
independently from one another, the possibility to send a merge request, 
that can be annotate line-by-line by all other Debian contributors.

A package with a repo on salsa is sending a clean message: go away, I 
don't want your contribution.

> Most of the actual packager work is not reflected in the source
> package. Testing that the package integrates well with the rest of
> Debian,

That time is better invested writing autopkgtests and letting Salsa-CI 
and debci run the tests. Having autopkgtests also lowers the barrier to 
contribute because the contributors can now be more confident of the 
fact that their changes did not cause any issue.

> replying to bug reports,

Not affected by having a repo on salsa.

> communicating with upstream etc.

Upstream that in 99% of the cases uses a git repo.

> I maintain a number of packages. Some are on Salsa, some are not, some are team
> maintained, some are not, some use dh, some use debhelper etc.
> This is a matter of efficiency, one size does not fit all.

The lack of a standardized sanctioned workflow is the main reason 
(together with unresponsive maintainers) why big cross-distro changes 
are nigh impossible to carry out. I would not classify it as a big 
advantage.

Regards,

-- 
Gioele Barabucci

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

#111382

Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> On 07/04/24 23:11, Bill Allombert wrote:
> > > What is your opinion about pushing logtool to Salsa?
> > 
> > Not speaking for logtool obviously, but maintaining simple packages on salsa is
> > just useless bureaucracy.
> 
> As a contributor, having a package on salsa is extremely useful, far from
> "useless".
> 
> By clicking on "fork" (or running the equivalent CLI command) I get a copy
> of the package, with all its history, a Debian-specific CI, the ability to
> work on different features or bug fixes at the same time and independently
> from one another, the possibility to send a merge request, that can be
> annotate line-by-line by all other Debian contributors.
> 
> A package with a repo on salsa is sending a clean message: go away, I don't
> want your contribution.

I suppose you meant _without_. The message is not "your contribution is
not wanted" but rather "your contribution is not needed because there
nothing to do".

They are hundred of other packages where your contribution would
make a difference.

Simple packages need someone who is responsible and responsive for them
in the long run and know there history much more than needing sporadic
contributions.

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

Imagine a large red swirl here.

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

#111384

On Mon, 8 Apr 2024 at 22:49, Bill Allombert <ballombe@debian.org> wrote:
>
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining simple packages on salsa is
> > > just useless bureaucracy.
> >
> > As a contributor, having a package on salsa is extremely useful, far from
> > "useless".
> >
> > By clicking on "fork" (or running the equivalent CLI command) I get a copy
> > of the package, with all its history, a Debian-specific CI, the ability to
> > work on different features or bug fixes at the same time and independently
> > from one another, the possibility to send a merge request, that can be
> > annotate line-by-line by all other Debian contributors.
> >
> > A package with a repo on salsa is sending a clean message: go away, I don't
> > want your contribution.
>
> I suppose you meant _without_. The message is not "your contribution is
> not wanted" but rather "your contribution is not needed because there
> nothing to do".
>
> They are hundred of other packages where your contribution would
> make a difference.
>
> Simple packages need someone who is responsible and responsive for them
> in the long run and know there history much more than needing sporadic
> contributions.

...right up until the point where that "bus factor of 1" moves
on/changes priorities/changes job/etc and the package is abandoned.
Fortunately that never happens, though!

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

#111386

On 17194 March 1977, Luca Boccassi wrote:
>> Simple packages need someone who is responsible and responsive for 
>> them
>> in the long run and know there history much more than needing 
>> sporadic
>> contributions.
> ...right up until the point where that "bus factor of 1" moves
> on/changes priorities/changes job/etc and the package is abandoned.
> Fortunately that never happens, though!

And interestingly, this does NOT need required team maintainance. It
does NOT need "package must be in git". It does NOT need "package must
be on salsa".

It "only" needs good procedures in taking over maintainership of
abandoned packages. And hey, for clearly abandoned packages, we have
that, and it works.


The problem is with people who are *not* clearly gone. Who are around
and block changes to "my package, my way, i ignore all outside wishes".
Or who are around and work against project wishes, in some way. And no
amount of "force a team on everyone" and no amount of "you must use
salsa" will solve this problem. While creating problems elsewhere.

-- 
bye, Joerg

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

#111387

On Mon, 8 Apr 2024 at 23:23, Joerg Jaspert <joerg@debian.org> wrote:
>
> On 17194 March 1977, Luca Boccassi wrote:
> >> Simple packages need someone who is responsible and responsive for
> >> them
> >> in the long run and know there history much more than needing
> >> sporadic
> >> contributions.
> > ...right up until the point where that "bus factor of 1" moves
> > on/changes priorities/changes job/etc and the package is abandoned.
> > Fortunately that never happens, though!
>
> And interestingly, this does NOT need required team maintainance. It
> does NOT need "package must be in git". It does NOT need "package must
> be on salsa".

True, they are not strictly needed - however, all of those things do
make everything orders of magnitude easier and more streamlined for
most contributors, especially new ones.

> It "only" needs good procedures in taking over maintainership of
> abandoned packages. And hey, for clearly abandoned packages, we have
> that, and it works.

And yet abandoned packages are still a thing, and there is still an
enormous amount of bureaucracy in the way.

> The problem is with people who are *not* clearly gone. Who are around
> and block changes to "my package, my way, i ignore all outside wishes".
> Or who are around and work against project wishes, in some way. And no
> amount of "force a team on everyone" and no amount of "you must use
> salsa" will solve this problem. While creating problems elsewhere.

I don't know, it seems counter-intuitive to me to suggest that "team
maintenance" and "my package, my way" are unrelated.

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

#111406

On Mon, Apr 08, 2024 at 11:00:52PM +0100, Luca Boccassi wrote:
> ...right up until the point where that "bus factor of 1" moves
> on/changes priorities/changes job/etc and the package is abandoned.
> Fortunately that never happens, though!

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.

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

Imagine a large red swirl here. 

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

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

Hi Bill and Wookey!

In a recent long thread on debian-devel you had somewhat negative
sentiments towards the usefulness of Salsa. 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

1. If the package was not on git and Salsa, I would have no way to see
what the maintainers have been doing in the years 2018-2023 (Debian
repos had last upload in 2018)

2. If the package was not on Salsa, and had the MR feature active, I
would not be able to submit a MR to fix the issues. Now the MR is up
there, and anybody can review and comment it - thus we are not even
dependent on the original maintainers alone.

3. The UI is easy and useful. I invite you to read my MR and add your
review. I made have some extra instructions to make this very
welcoming for people who do not "like" Salsa/GitLab and might feel
that something is unintuitive

4. If you don't want to use the web UI, you can also download my patch
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch
and review by email. Or you can click in the UI once to subscribe the
MR and then continue review/comments by email.


Personally I fully agree with the people stating that "Salsa is the
best thing in Debian in the past 20 years". So far everyone I talked
to who initially had reservations regarding using Salsa have started
liking it after they learned a bit more how it works, and have seen
things like Salsa-CI in action saving the Debian archive from needless
widespread failures.

Thanks,

Otto

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

#111795 — 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 05:25:10)
> In a recent long thread on debian-devel you had somewhat negative
> sentiments towards the usefulness of Salsa. 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
> 
> 1. If the package was not on git and Salsa, I would have no way to see
> what the maintainers have been doing in the years 2018-2023 (Debian
> repos had last upload in 2018)

With git (or another VCS) but *without Salsa, you would certainly not be
blind to existing development.

I agree with striving towards VCS tracking of all code in Debian, and
striving towards the use of a single VCS, and I think it is reasonable
to separate the discussion about that from the discussion about the
relevancy of Salsa.


> 2. If the package was not on Salsa, and had the MR feature active, I
> would not be able to submit a MR to fix the issues. Now the MR is up
> there, and anybody can review and comment it - thus we are not even
> dependent on the original maintainers alone.

With git but without Salsa, you would post a patch to Debbugs, that
would be up there for anybody to review and comment on.

Sure, you would not be able to specifically use a Gitlab routine without
having a Gitlab instance to do it on.  And reviewers and commenters
would need to be bothered with using email, which is different but not
inherently worse than having to be bothered with using Gitlab UIs.

Did you also post your MR as a patch in Debbugs?


> 3. The UI is easy and useful. I invite you to read my MR and add your
> review. I made have some extra instructions to make this very
> welcoming for people who do not "like" Salsa/GitLab and might feel
> that something is unintuitive

The UI of my email program is easy and useful.

You don't need to agree with me, you can pick another email system that
is more to your liking.  It is much harder with Gitlab to provide room
for different personal ways of working.  Please note, that I am here,
like yourself, not talking about different ways of structuring code in a
VCS, but about how the UI affects how you personally are able to
interact.

You and I quite likely use different text editor, and different email
application, and possibly also different web browser.  That affects how
easy and useful the personal end of collaboration is. The collective end
of collaboration must involve how (if at all) code is tracked in a VCS,
but it need not dictate UI at all.


> 4. If you don't want to use the web UI, you can also download my patch
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19.patch
> and review by email. Or you can click in the UI once to subscribe the
> MR and then continue review/comments by email.

If you don't want to use a command-line or a scripted or a GUI-based
email application for receiving patches shared at Debbugs, you can use a
web-based email application - locally hosted or through a provider.

I already subscribe to Debbugs for the packages and teams I am most
interested in tracking contributions for.


> Personally I fully agree with the people stating that "Salsa is the
> best thing in Debian in the past 20 years". So far everyone I talked
> to who initially had reservations regarding using Salsa have started
> liking it after they learned a bit more how it works, and have seen
> things like Salsa-CI in action saving the Debian archive from needless
> widespread failures.

Debian is *not* helped by spreading issue tracking across multiple
independent data and communication networks.

My concern about Gitlab is not its *additions* to existing services, but
its *duplications* of core services already in Debian.

Please, let us separately discuss if we should...

 * mandate VCS-tracking
 * mandate the use of one specific VCS
 * mandate one specific VCS workflow
 * mandate collaborative packaging
 * mandate project-wide issue tracking
 * mandate a single project-wide issue-tracker

...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.

Personally, my current opinion on each of the above is this:

 * mandate VCS-tracking
   * Yes
 * mandate the use of one specific VCS
   * Yes: git
 * mandate one specific VCS workflow
   * Not yet, but require unusual workflow flagged and documented
 * mandate collaborative packaging
   * Not yet, but 
 * mandate project-wide issue tracking
   * Yes: personal/team issues like WNPP work are project issues
 * mandate a single project-wide issue-tracker
   * Yes: Debbugs (for now: open to switch but not to duplicate)


 - 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]

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

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

csiph-web