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

#111883

Salvo Tomaselli <tiposchi@tiscali.it> writes:

> If the debian/ directory is on salsa, but the rest of the project is
> somewhere else, then this no longer works, I have to tag in 2 different
> places, I have 2 different repositories to push to and so on.

For what it's worth, what I do for the packages for which I'm also
upstream is that I just add Salsa as another remote and, after I upload
a new version of the Debian package, I push to Salsa as well (yes,
including all the upstream branches; why not, the Debian branches are
based on that anyway, so it's not much more space).  One of these days
I'll get CI set up properly, and then it will be worthwhile to push to
Salsa *before* I upload the package and let it do some additional
checking.

It's still an additional step, and I still sometimes forget to do it, but
after some one-time setup, it's a fairly trivial amount of work.

It's more work to accept a merge request on Salsa and update the
repositories appropriately, since there are two repositories in play, but
in that case I'm getting a contribution out of it that I might not have
gotten otherwise, so to me that seems worth it.

I used to try to keep the debian directory in a separate repository or try
to keep the Debian Git branches in a separate repository, and all of that
was just annoying and tedious and didn't feel like it accomplished much.
Just pushing the same branches everywhere is easy and seems to accomplish
the same thing.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

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

#111885

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

On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. 
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out what workflow does the repo imply
- if it's an unfamiliar one then somehow learn it
- check if there are no commits on top of the previous upload and if there
  are any then how to merge them with the NMU changes
- check that your commit builds correctly
at least when doing more than one NMU per week or whatever.
The nmudiff(1) interface is standardized, one command does everything, you
are still required to use it, and you need to remember that MRs don't give
notifications so you have an additional reason to use it, and importing a
nmudiff should be easy for the maintainer.

> At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.
Sending the nmudiff to the bugreport is mandatory per the devref NMU
procedure (though of course that procedure itself is not a policy and not
everyone follows it).

-- 
WBR, wRAR

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

#111890

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

On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote:
> IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
> Salsa we could require the NMUer to add at least a MR.  

those are two things:

- mandating salsa (for git)
- mandating to have MRs enabled on salsa for that project.
 

-- 
cheers,
	Holger

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

Very hard to relate to those who think the first three years of the pandemic
were bad because they couldn’t go to bars for a while, as opposed to because
25 million people died, 400 million were disabled, and many more continue to
be unable to access public space.

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

#111897

Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli:
> 
> And what's the advantage? When an nmu happens the person doing it normally 
> doesn't bother to push to salsa anyway. At most I get a patch in the 
> bugreport, or I have to diff the packages and import the diff.

IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
Salsa we could require the NMUer to add at least a MR.  I personally
would prefer permissions to push even to the default branch and tag
accordingly.  The current situation of not having some default VCS at
some default place makes injecting NMUs into the VCS impossible and it
does not help to blame NMUers about this.

Kind regards
    Andreas.

-- 
https://fam-tille.de

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

#111361

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

On 2024-04-07 16:04 +0200, Andreas Tille wrote:
> 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.

Good plan.

> > 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;
<snip example>

> > I am all for reducing the barrier to doing NMUs. Let's look at
> > that; it's ridiculous that we need to ask permission to help
> > someone else with maintaining packages if it's clear that they can
> > use it. Debian as a whole is a team, and we maintain the
> > distribution together. So when I do an NMU for your stuff, I'm
> > here to help. You should be happy when I'm offering to help; and
> > that's even enshrined in the code of conduct:

> > [...] offers for help should be seen in the context of our shared
> > goal of improving Debian

> > The fact that a package is listed as maintained by a person rather
> > than a team does not mean the person is the only person who is
> > responsible for that package. Debian as a whole is. And the
> > release team is, in the context of deciding what happens with a
> > package that has outstanding RC bugs. And the QA team is, when
> > they run full-archive test rebuilds for new things. And our users
> > are, when they file bugs.

So I agree with everything Wouter said in this mail. I'm keen on
changing the _culture_ to make it easier to just fix things.

But Andreas seems to have taken this idea of 'we should make it easier
to help people maintain packages', and conflated it with 'everyone has
to use salsa' and 'everything should be team maintained'.

I think that's a mistake, and I'm not a fan. Because so far as I can
tell 'use salsa' actually means 'maintain your packages in git'. So
far as I can see it is not possible to use our existing 'uscan, patch,
sbuild, dupload' type workflows with Salsa. And that's why I'm not
using it, and don't want to be made to use it.

But I am _not_ against people helping me fix my stuff - I'm on the
'just NMU my packages - I won't bite' list.

As I said elsewhere:
For me Salsa is just one more thing to deal with. It is useful if you
need to share a package _before_ it is uploaded, but mostly it's just
a load of extra stuff I didn't want or need (git, web-interfaces,
certificates). And when I _do_ have to deal with it it takes a lot of
extra time and effort I would prefer to have spent elsewhere.

I have a workflow I am quite happy with (uscan, meld, quilt, sbuild,
dupload). I've tried various fancy new things (salsa, git, dgit) but
mostly I've found they got in the way (and delayed uploads/wasted
time) rather than made my life easier, so I keep going back to the old
way because it just works.

I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
enjoy seeing 'packages must be in Salsa' made a requirement, for
example.

Dgit almost solves this problem but is backwards from my POV. It lets
the git people pretend that they still use quilt and tarballs so the
interface remains compatible (excellent). But it doesn't let the
tarball people expose an interface to keep the git people happy (SFAIK
- you can't do a dgit upload unless you have a git repo) which is a
pity - I'd be fine doing doing 'dgit upload' instead of 'dupload' for
compatibility purposes.

> > If there are stupid barriers to helping people out by doing NMUs or
> > taking over packages, then by all means let's break down those barriers.

Right, but this is (or should be) quite separate from 'make everyone
use git/salsa, i.e. stop them using the existing workflows'.

If 'use salsa' means that when I do 'dupload' a copy ends up in salsa
too, and when I do 'dget' it actually gets the dsc+tarball from salsa
then that's fine. But if it means 'your package is a git repo, you
have to use git to work with it', then no, I strongly object. I don't
want to change all my workflows and tools.

Perhaps there is some tool I am not aware of that can solve this
problem? Like I say, dgit is so close, but exactly the opposite of
what I need.

> > But let's not try to "fix" a problem by introducing a rule that is, at
> > best, affecting something only very weakly related to the problem that
> > we are trying to solve.
>
> I would be happy to talk about rules that might help solving problems
> (as well as droping rules that are creating barriers).

Me too. Please let us improve the culture around NMUs, collaboration and fixes
without making people (OK, duffers like me) change all their tooling.

I am all for more Matrix over IRC though - that's a genuine
improvement (and they are easy to bridge).

Wookey
--
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

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

#111363

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

On Apr 07, Wookey <wookey@wookware.org> wrote:

> I think that's a mistake, and I'm not a fan. Because so far as I can
> tell 'use salsa' actually means 'maintain your packages in git'. So
> far as I can see it is not possible to use our existing 'uscan, patch,
> sbuild, dupload' type workflows with Salsa. And that's why I'm not
> using it, and don't want to be made to use it.
I started using git quite late and spent really a lot of time trying to 
understand how it fit in my quilt workflow (I loved quilt), but in the 
end I figured out that it maps well to a patch unapplied gbp-like 
workflow:

If no changes to the packaging are needed then it's just:

uscan --rename
gbp import-orig ../package_*.tar.xz
dch -v $(cat VERSION)-1 'New upstream release.'
git add debian/changelog
git commit
git tag ...
dpkg-source --build .
pbuilder build $(ls -1tr ../*.dsc | tail -1)
dupload ...

Check the rpki-client repository for an example.

(Using gbp is not mandatory, but it allows to import with just one 
command the upstream tar archive or git tree reference.)

And now having the full git history of my packages is invaluable when 
trying to understand what has changed and when.

-- 
ciao,
Marco

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

#111367

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

Hi,

Quoting Wookey (2024-04-07 22:42:34)
> On 2024-04-07 16:04 +0200, Andreas Tille wrote:
> > 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.
> Good plan.

finally! Thank you!! <3

My personal take on the general discussion: can we first agree on a
non-mandatory packaging workflow before we talk about reducing strong package
ownership? Or at least add a way for a package to declare the used workflow?
I'm not feeling comfortable doing more than opening merge requests or sending
patches via the BTS to any package (even if the package is in the low threshold
nmu list) without this knowledge.

> > > The fact that a package is listed as maintained by a person rather than a
> > > team does not mean the person is the only person who is responsible for
> > > that package. Debian as a whole is. And the release team is, in the
> > > context of deciding what happens with a package that has outstanding RC
> > > bugs. And the QA team is, when they run full-archive test rebuilds for
> > > new things. And our users are, when they file bugs.
> 
> So I agree with everything Wouter said in this mail. I'm keen on
> changing the _culture_ to make it easier to just fix things.
> 
> But Andreas seems to have taken this idea of 'we should make it easier
> to help people maintain packages', and conflated it with 'everyone has
> to use salsa' and 'everything should be team maintained'.
> 
> I think that's a mistake, and I'm not a fan. Because so far as I can
> tell 'use salsa' actually means 'maintain your packages in git'. So
> far as I can see it is not possible to use our existing 'uscan, patch,
> sbuild, dupload' type workflows with Salsa. And that's why I'm not
> using it, and don't want to be made to use it.
> 
> But I am _not_ against people helping me fix my stuff - I'm on the
> 'just NMU my packages - I won't bite' list.
> 
> As I said elsewhere:
> For me Salsa is just one more thing to deal with. It is useful if you
> need to share a package _before_ it is uploaded, but mostly it's just
> a load of extra stuff I didn't want or need (git, web-interfaces,
> certificates). And when I _do_ have to deal with it it takes a lot of
> extra time and effort I would prefer to have spent elsewhere.
> 
> I have a workflow I am quite happy with (uscan, meld, quilt, sbuild,
> dupload). I've tried various fancy new things (salsa, git, dgit) but
> mostly I've found they got in the way (and delayed uploads/wasted
> time) rather than made my life easier, so I keep going back to the old
> way because it just works.
> 
> I don't mind what other people do, but I worry that conversations like
> this seem to take the new thing as so self-evidently better that
> no-one can reasonably complain about them being made a
> requirement. Well, we don't all think it's better, and I wouldn't
> enjoy seeing 'packages must be in Salsa' made a requirement, for
> example.
> 
> Dgit almost solves this problem but is backwards from my POV. It lets
> the git people pretend that they still use quilt and tarballs so the
> interface remains compatible (excellent). But it doesn't let the
> tarball people expose an interface to keep the git people happy (SFAIK - you
> can't do a dgit upload unless you have a git repo) which is a pity - I'd be
> fine doing doing 'dgit upload' instead of 'dupload' for compatibility
> purposes.

Personally, I cannot imagine myself maintaining my packages without them being
in a VCS like git. I want to be able to "git log" a file to see which changes
touched it. I want to be able to "git blame" a file to see which change
modified a certain line. I want to "git revert" changes or "git rebase" local
feature branches. Even without any contributors, I don't mind the overhead of
using git for packaging as it helps *me* in the end.

Then there is salsa... I have mixed feelings about it. On the one hand, it's
this big beast with tons of javascript and apparently we are not even
dog-fooding gitlab as packaged in Debian to overseves. I'd like our
infrastructure to be based on the things we offer in our distro. And it's just
so much javascript...  I cannot open a build log in the browser without it just
vanishing before my eyes with an error message in red at the top. My computer
is slow (ARM Cortex A53) and this does not play well with it. I wish there was
a way to interact with it from my terminal instead of having to click on
buttons in a very slow web interface.

On the other hand, salsa has enabled me to have confidence in what I upload as
I haven't had before. I really like that I can "git push" my changes and then
another computer can tell me whether autopkgtest, piuparts, reprotest and
friends are happy. I could set all this up locally but due to the limitations
of my machine I like that I can just trigger another computer to do this work
for me while I use that time to work on other stuff. I like that salsa gives me
a lot of confidence in my package actually not being half broken before I
"dput" it into the archive. I also like to receive contributions through salsa
which (in contrast to contributions via the BTS) will show me via a green icon
that the change does not break something. In contrast to email communication on
the BTS, merge requests and issues on salsa allow me to easily amend or change
existing messages, automatically hide resolved conversations not only on my end
but also for other people viewing a merge request, have in-line comments on a
code diff which I know not only my own special e-mail client will display that
way but will look the same for other people in their browser. I can click links
to cross-referenced issues, receive automatic improvements from jelmer's
janitor or manage several experiments that I have in multiple branches not just
locally for me but publicly for everybody to see and comment upon and then
others see those comments organized for each of these merge requests. Using
just the BTS does not allow this level of collaboration. It doesn't integrate
this tightly into the code itself and does not display the information that
clearly.

In summary, I understand people for whom having their packaging in git is
"self-evidently better". I really struggle to see the benefits of the "uscan,
meld, quilt, sbuild, dupload" workflow you describe over one that involves a
local git repository. It just helps me so much to have things in git. I don't
want to tell you that your approach is wrong. It clearly is working fine for
you. But I have just too often thought "drats, I wish I now could look up what
changed when in which file" that having everything in git is a no-brainer for
me and maybe I was able to motivate you a bit to give git another try. It
really revolutionized how I work with files on my computer, including Debian
packaging. As for salsa: I understand the ups and downs I think. I like to use
it but I've also cursed at it enough times to understand the dislike. But I
think the benefits outweigh the costs for me, so I ended up using it. I'm not
feeling entirely comfortable with making its use mandatory.

Thanks!

cheers, josch

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

#111368

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

> Then there is salsa... I have mixed feelings about it. On the one hand, it's
> this big beast with tons of javascript and apparently we are not even
> dog-fooding gitlab as packaged in Debian to overseves. I'd like our
> infrastructure to be based on the things we offer in our distro. And it's just
> so much javascript...  I cannot open a build log in the browser without it just
> vanishing before my eyes with an error message in red at the top. My computer
> is slow (ARM Cortex A53) and this does not play well with it. I wish there was
> a way to interact with it from my terminal instead of having to click on
> buttons in a very slow web interface.

We actually have `glab`[0] packaged in Debian Sid, Trixie and Bookworm-backports now, so there is a relatively easy to use way of accessing it from the CLI.

[0] https://packages.debian.org/sid/glab

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

#111373

Hi,

On 4/8/24 05:42, Wookey wrote:

> I don't mind what other people do, but I worry that conversations like
> this seem to take the new thing as so self-evidently better that
> no-one can reasonably complain about them being made a
> requirement. Well, we don't all think it's better, and I wouldn't
> enjoy seeing 'packages must be in Salsa' made a requirement, for
> example.

What people seem to be missing is that the Debian archive *is* a version 
control system.

Stacking another VCS on top of it leads to a lot of annoying artifacts, 
because there is no sensible metadata mapping between them -- what is 
metadata in Debian becomes data in git, and another metadata layer is 
added on top of that, and what is data in Debian must be run through a 
filter to make it accessible to git for efficient handling, so part of 
it gets converted to metadata.

The result is... not ideal, because the resulting workflow is neither a 
Debian nor a git workflow, but a mix that requires users to be aware of 
the state of two systems at the same time. Testing a package requires me 
to commit everything into git first, so I have to remember to squash all 
these commits later.

As long as there is no clear benefit, for example in a team maintained 
package where multiple team members regularly collaborate on pre-release 
states without uploading a Debian package in between, it mostly adds to 
my workload -- especially if no upload is made for a change, whoever 
does the upload will need to remember to review all of these changes. In 
the context of the xz debate, I'd expect this to increase, not decrease 
attack surface.

The web interface presented by salsa also does not have the necessary 
data<->metadata filters to provide an actual insight into what is really 
happening in the repository.

Because metadata is stored as data, building such filters would also be 
nontrivial. The existing gbp repositories pretty much all use a merge 
commit to integrate a new upstream version, but do not update 
debian/changelog in the same commit, so any tool analyzing this commit 
would see all the upstream changes for the new version as Debian 
specific changes against the old. Practically the only commits that are 
safe to analyze in this way are the tagged releases.

What would make sense would be a git based format that is designed 
around the requirements for package maintenance, and where internal 
consistency can be enforced by upload hooks -- for example by storing 
metadata out-of-band in a separate branch.

    Simon

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

#111374

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

On Mon, Apr 08, 2024 at 09:44:55PM +0900, Simon Richter wrote:
> > I don't mind what other people do, but I worry that conversations like
> > this seem to take the new thing as so self-evidently better that
> > no-one can reasonably complain about them being made a
> > requirement. Well, we don't all think it's better, and I wouldn't
> > enjoy seeing 'packages must be in Salsa' made a requirement, for
> > example.
> 
> What people seem to be missing is that the Debian archive *is* a version
> control system.
We are not missing it.

> Stacking another VCS on top of it leads to a lot of annoying artifacts,
> because there is no sensible metadata mapping between them -- what is
> metadata in Debian becomes data in git, and another metadata layer is added
> on top of that, and what is data in Debian must be run through a filter to
> make it accessible to git for efficient handling, so part of it gets
> converted to metadata.
> 
> The result is... not ideal, because the resulting workflow is neither a
> Debian nor a git workflow, but a mix that requires users to be aware of the
> state of two systems at the same time.
We know, and we are sad about this, but we see the benefits it brings so
we tolerate the rough edges and data duplication and hope for a better
future when the workflows are improved.
Some of us make proposals for better workflows from time to time but this
is Debian.

> Testing a package requires me to commit everything into git first, so I
> have to remember to squash all these commits later.\
At least gbp doesn't require anything like this (unless your "testing"
requires Salsa CI which is another story).

> What would make sense would be a git based format that is designed around
> the requirements for package maintenance, and where internal consistency can
> be enforced by upload hooks -- for example by storing metadata out-of-band
> in a separate branch.
We know. It was rejected as Debian doesn't want to store random data as a
part of a repo history because of DFSG, or something like that.

-- 
WBR, wRAR

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

#111375

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

Hi

Le lun. 8 avr. 2024, 14:45, Simon Richter <sjr@debian.org> a écrit :

> The web interface presented by salsa also does not have the necessary
> data<->metadata filters to provide an actual insight into what is really
> happening in the repository.
>

It's been several times already some people complain about salsa because of
its web interface.

I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
- What does that web interface have that people don't like?

Cheers,

J.Puydt

>

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

#111376

Hi Julien,

On 4/8/24 22:45, Julien Puydt wrote:

> I only use salsa's git. That begs two questions:
> - What do I miss by not using the web interface?
 > - What does that web interface have that people don't like?

It's a normal GitLab install. For anything that is a normal software 
project (like dpkg), you get all the features of a normal forge.

But: forges do not map packaging workflows, so in practice you can only 
browse the source code.

    Simon

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

#111396

Hi Julien,

Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
> 
> I only use salsa's git. That begs two questions:
> - What do I miss by not using the web interface?

If you are owner of a team repository you need to manage members.  As
far as I know this is only possible via web interface (I did not checked
glab since I just learned in this thread about is existence.)  This is
sometimes a bit slow but acceptable for me since I need to deal with it
once or twice a month.

When intending to package something new I do not only fire up wnpp-check
to look for some ITP bug but also seek on Salsa for some preliminary work
done on this project without filing some ITP.  I like this web search
and in case you do some duplicated work you might miss it (see above
for possible replacement by glab).

For me Salsa CI is one of the greatest things we have.  Its not "pure"
Salsa but I'd say you are missing something if you are not using it.
(Thanks a lot to those who are running Salsa CI!)

> - What does that web interface have that people don't like?

I confirm that logs from Salsa CI are sometimes a bit slow but I'm not
sure whom to blame about this.  For me it does not cross the borderline
to "not like it" - but in Johannes Schauer wrote in this thread that
slow clients might fail to show log files at all.

For me the two biggest argument for using Salsa consequently are:
  - It enables more than one person to work on one package effectively
  - I've met lots of potential young contributors who expect somehow a
    modern collaboration tool and we are risking that young blood
    moves to other distros if we do not use it consequently

Kind regards
   Andreas.

-- 
https://fam-tille.de

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

#111410

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

On Tue, 09 Apr 2024 16:07:20 +0200, Andreas Tille wrote:

> Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
> > I only use salsa's git. That begs two questions:
> > - What do I miss by not using the web interface?
> If you are owner of a team repository you need to manage members.  As
> far as I know this is only possible via web interface (I did not checked
> glab since I just learned in this thread about is existence.)

Managing team membership also works via the API, which is used by
salsa(1) in devtools (also dpt-salsa(1) in pkg-perl-tools and
probably other helpers).


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]

#111398

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

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. But I
don't know that until I've made a whole set of changes and it builds.

So now I've got a pile of changes which should really be separate
commits and logically separate things often affect the same files, and
even the same lines, so really I need to commit some chunks and not
others and tidy it all up. Yes this makes a nice set of commits but
it's _so_ much work in comparison to just editing the damn files, and
then effectively doing one fat 'commit' when I dupload. Often
something ends up stalled for weeks or months or years because I've
got some chunks in the wrong places and sorting it out is painful, so
I go do something else and lose all my state. You all know how that
goes...

Sometimes git is useful - I do use it quite intensively for things
where it actually helps (complicated cave survey datasets with
hundreds of entangled commits that need re-ordering). For the vast
majority of my debian packaging it's just makework.

I realise this (like my previous message) will result in a load of
people telling me git _is_ better and I'm just doing it wrong, or
should learn better tools. And they may even be right, (and I will
probably learn some things from this thread), but I don't believe the
goal we agree on (fixing other people's packages should be culturally
accepted) _requires_ this change in tooling (which is a heavy cost for
at least some of us).

The point here is that 'requiring salsa' is actually code for 'no,
you can't just use the tarball-based VCS any more - you have to use
git'.  Removing that interface is a very big deal - it has served
quite well for 30 years. Yes it old-fashioned and crufty and
(presumably) only a minority still use it as the primary interface,
but any GR on this should acknowledge what we are requiring of people
still using it, not just frame this as 'and add salsa'. It's more
fundamental than that (or I am misunderstanding)..

Also what do you git people do to replace uscan? Currently I go to my
existing version, or a newly-acquired apt get or dget source. I do
'uscan' and if there is a new upstream version I have a nice separate
directly that is easy to dirdiff (then fixup any packaging and
dupload). If there isn't I can move on. 

git world seems to make this way more complicated. I have to set up
two different repos - one for salsa one for upstream, then pull them,
maybe into different branches, and fight the diff config to let me
dirdiff two different commits. And the upstream pull will always pull
changes, not just only do it is there is an actual release (tag).

None of that feels like an improvement over 'uscan'. One word for the
standard process of updating to a new version. And if the patches
still apply it's probably all done (I always do a meld review too to
see what changed).

And I do just prefer having two directories rather than multiple
version on top of each other. My simple brain finds it a lot easier to
keep track of a version directory to diff between, rather than finding
the right runes to get git to give meld faked-up directories pointing
at revisions or branches.

If someone can make a tool so that this workflow still works, but a
copy gets dumped into salsa, then I don't mind this new
requirement. But otherwise it seems like a big imposition.

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.

Josch's suggestion that just recording the workflow in metadata would
be useful is a good one. Then at least you know what other maintainers
are doing. And dgit's approach of unifying the archive representation
and the git representation is definitely progress in the right
direction. I was very sad to find that it didn't help us 'tarball
people' directly at all (except I guess to reduce exactly this
pressure to stop doing it and use git).

So why mandate salsa rather than make dgit more official? That lets
the people that want to use git use it for everything - even the
packages that were just uploaded as tarballs. And explicitly _doesn't_
remove the archive VCS interface. And it supports all the git-based
workflows. (someone should probably tell IWJ this conversation is
occuring as he's taken a bit intererest in it, but no longer reads
debian-devel). Does than not solve a good chunk of this 'make it easy
to fix other packages using your standard tools' desire?

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/

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

#111401

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

Hi Wookey and all,

Quoting Wookey (2024-04-09 18:52:43)
> 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. But I don't know that until I've
> made a whole set of changes and it builds.

if what I want to do is more complicated, what I do is indeed to create a stack
of commits which I squash in the end. I see this as a feature because it allows
me to always go back to an earlier stage of my changes. If the code is complex
I'm unable to keep in my head what I changed when and why. I use git commits to
keep track of that as I work towards the final result. Because every meaningful
change is in a git commit I can always go back to an earlier stage if it turns
out I messed something up. Yes, running "git add ... && git commit" is overhead
but I in my experience I waste more time with forgetting what file I changed
how the last time I tested something than with running these git commands.

> So now I've got a pile of changes which should really be separate commits and
> logically separate things often affect the same files, and even the same
> lines, so really I need to commit some chunks and not others and tidy it all
> up. Yes this makes a nice set of commits but it's _so_ much work in
> comparison to just editing the damn files, and then effectively doing one fat
> 'commit' when I dupload. Often something ends up stalled for weeks or months
> or years because I've got some chunks in the wrong places and sorting it out
> is painful, so I go do something else and lose all my state. You all know how
> that goes...

I manage these "piles of changes" in git branches and oftentimes, those
branches end up as "merge requests" against another repo or my own repo. By
doing it like that I not only allow others to see my work and potentially
contribute as I'm working on it but I also keep a record of all the stuff I'm
working on for future-me as I come back to work on a bug or feature. The extra
data I am storing in git commit messages, that extra work, allows me to
organize myself so it helps me even assuming that nobody else is contributing.

> I realise this (like my previous message) will result in a load of people
> telling me git _is_ better and I'm just doing it wrong, or should learn
> better tools. And they may even be right, (and I will probably learn some
> things from this thread), but I don't believe the goal we agree on (fixing
> other people's packages should be culturally accepted) _requires_ this change
> in tooling (which is a heavy cost for at least some of us).

Personally, I think the project would be better off with more standardization
of our workflows. The more different workflows we have, the harder it is to
make archive-wide changes or for newcomers to learn the ropes. Speaking of
newcomers: if I talk to my students, then for them, using git and workflows
involving branches, tags and pull/merge requests is natural to them. So one can
also argue the other way round and say: we deter younger contributors by not
embracing the git workflow more.

Sadly, there is probably no way to make everybody happy. I'd also not like to
force you to switch your workflows. Of course ideally, I'd like to convince you
that embracing git for packaging not only helps others but can also help you.
:)

> Also what do you git people do to replace uscan? Currently I go to my
> existing version, or a newly-acquired apt get or dget source. I do 'uscan'
> and if there is a new upstream version I have a nice separate directly that
> is easy to dirdiff (then fixup any packaging and dupload). If there isn't I
> can move on.

Personally, I run:

    $ uscan --verbose
    $ gbp import-orig ../source.orig.tar.gz

> And I do just prefer having two directories rather than multiple
> version on top of each other. My simple brain finds it a lot easier to
> keep track of a version directory to diff between, rather than finding
> the right runes to get git to give meld faked-up directories pointing
> at revisions or branches.

I found this paragraph really interesting because reading your other emails I
was wondering "well but how else do you do it then??" :D Maybe this is just
muscle memory? Your directories are just my git branches. Instead of "cd
../source-verX" I'd do "git switch verX". Personally, I find git branches
superior to directories because the git commit messages in each branch allow me
to describe what this feature-branch is doing much better than a directory name
could. A stack of commits in a branch allows me to trace back what changes I
did in what order when I worked on a feature. By pushing the branches to salsa,
I enable collaboration on my work by doing not much more than running "git push
--set-upstream origin myfeature".

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

Yes: https://wiki.debian.org/GitPackagingSurvey

> Josch's suggestion that just recording the workflow in metadata would be
> useful is a good one. Then at least you know what other maintainers are
> doing. And dgit's approach of unifying the archive representation and the git
> representation is definitely progress in the right direction. I was very sad
> to find that it didn't help us 'tarball people' directly at all (except I
> guess to reduce exactly this pressure to stop doing it and use git).
> 
> So why mandate salsa rather than make dgit more official? That lets the
> people that want to use git use it for everything - even the packages that
> were just uploaded as tarballs. And explicitly _doesn't_ remove the archive
> VCS interface. And it supports all the git-based workflows. (someone should
> probably tell IWJ this conversation is occuring as he's taken a bit
> intererest in it, but no longer reads debian-devel). Does than not solve a
> good chunk of this 'make it easy to fix other packages using your standard
> tools' desire?

Personally, I'd not like to *mandate* git or salsa or whatnot. What I'd
personally like to see would be one standard documented default workflow. I
think that'd already get us a long way into easier collaboration. It would not
even need to be an instance of https://xkcd.com/927/ (Standards). Just pick one
established workflow, deem it *the thing*, document it and call it a day.
Personally I don't care which of the above 12 workflows is picked. I rather
prefer to use the thing that everybody else is using than doing what I *hope*
is familiar for others...

Thanks!

cheers, josch

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

#111402

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

On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues wrote:
> > And I do just prefer having two directories rather than multiple
> > version on top of each other. My simple brain finds it a lot easier to
> > keep track of a version directory to diff between, rather than finding
> > the right runes to get git to give meld faked-up directories pointing
> > at revisions or branches.
> 
> I found this paragraph really interesting because reading your other emails I
> was wondering "well but how else do you do it then??" :D Maybe this is just
> muscle memory? Your directories are just my git branches. Instead of "cd
> ../source-verX" I'd do "git switch verX". Personally, I find git branches
> superior to directories because the git commit messages in each branch allow me
> to describe what this feature-branch is doing much better than a directory name
> could. A stack of commits in a branch allows me to trace back what changes I
> did in what order when I worked on a feature. By pushing the branches to salsa,
> I enable collaboration on my work by doing not much more than running "git push
> --set-upstream origin myfeature".
And of course git can emulate the other workflow using git-worktree.

-- 
WBR, wRAR

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

#111403

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

On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote:
> 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. But I
> don't know that until I've made a whole set of changes and it builds.
> 
> So now I've got a pile of changes which should really be separate
> commits and logically separate things often affect the same files, and
> even the same lines, so really I need to commit some chunks and not
> others and tidy it all up. Yes this makes a nice set of commits but
> it's _so_ much work in comparison to just editing the damn files, and
> then effectively doing one fat 'commit' when I dupload. Often
> something ends up stalled for weeks or months or years because I've
> got some chunks in the wrong places and sorting it out is painful, so
> I go do something else and lose all my state. You all know how that
> goes...
Again, you don't need to commit anything to test it, so you can use
whatever commit style is fine, including one fat commit before dupload.
You may mean that doing this provides no benefit over not using git, which
isn't really true.

> Also what do you git people do to replace uscan? 
gbp import-orig --uscan

> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream, then pull them,
> maybe into different branches, and fight the diff config to let me
> dirdiff two different commits. And the upstream pull will always pull
> changes, not just only do it is there is an actual release (tag).
You don't need to do that, you can't do that with upstreams that don't use
git and some (probably all?) teams forbid that.

-- 
WBR, wRAR

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

#111404

On Tue Apr 9, 2024 at 1:52 PM -03, 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. But I
> don't know that until I've made a whole set of changes and it builds.

Use gbp-buildpackage --git-ignore-new. By default checks for uncommited,
so you don't ship to Debian things that are not commited. If you use
this flag, the burden of checking this lands on you.

Yet, you can still use the regular workflow to build stuff, just
dpkg-buildpackage -us -uc.

> So now I've got a pile of changes which should really be separate
> commits and logically separate things often affect the same files, and
> even the same lines, so really I need to commit some chunks and not
> others and tidy it all up. Yes this makes a nice set of commits but
> it's _so_ much work in comparison to just editing the damn files, and
> then effectively doing one fat 'commit' when I dupload. Often
> something ends up stalled for weeks or months or years because I've
> got some chunks in the wrong places and sorting it out is painful, so
> I go do something else and lose all my state. You all know how that
> goes...

Use git commit -p, I tend to throw -v as well, so when I am writing the
commit description I also get the diff of that commit. With -p you
basically select by blocks what goes into your commit with simple y and
n. You can also split blocks.

If you prefer to just make a bunch of small commits and then combine
them all into one big-fat commit, just use git rebase -i HEAD~N with N
being how many commits you want to rebase.

This will give you a file text where you decide which commits are
squashed onto the top one, you can also re-arrange. After you save that
file, it'll allow you to modify the commit.

So you can do a bunch of git commit -m 'random' and with git rebase -i
create a proper commit message from a bunch of commits.

> I realise this (like my previous message) will result in a load of
> people telling me git _is_ better and I'm just doing it wrong, or
> should learn better tools. And they may even be right, (and I will
> probably learn some things from this thread), but I don't believe the
> goal we agree on (fixing other people's packages should be culturally
> accepted) _requires_ this change in tooling (which is a heavy cost for
> at least some of us).

Git is the default tooling in the whole open-source ecosystem. Maybe a
poll would be good to know how much people actually is against using Git
as default, after so many years with proper git tooling in Debian. I
would not be surprised if the loud bunch in the mailing lists end-up
being very very small.

I understand is hard to have your workflows changed, but IMO it's been
too many years that Git is the default VCS everywhere. There's no other
workflow you need to change, if you use Git.

> The point here is that 'requiring salsa' is actually code for 'no,
> you can't just use the tarball-based VCS any more - you have to use
> git'.  Removing that interface is a very big deal - it has served
> quite well for 30 years. Yes it old-fashioned and crufty and
> (presumably) only a minority still use it as the primary interface,
> but any GR on this should acknowledge what we are requiring of people
> still using it, not just frame this as 'and add salsa'. It's more
> fundamental than that (or I am misunderstanding)..

This is untrue. All the git tooling depends on non-git tooling for the
build. I actually have a setup for building everything on docker and
does not use any git tooling, because that's just sugar-coating for the
non-git tools.

> Also what do you git people do to replace uscan? Currently I go to my
> existing version, or a newly-acquired apt get or dget source. I do
> 'uscan' and if there is a new upstream version I have a nice separate
> directly that is easy to dirdiff (then fixup any packaging and
> dupload). If there isn't I can move on. 

You can use uscan.

> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream, then pull them,
> maybe into different branches, and fight the diff config to let me
> dirdiff two different commits. And the upstream pull will always pull
> changes, not just only do it is there is an actual release (tag).
>
> None of that feels like an improvement over 'uscan'. One word for the
> standard process of updating to a new version. And if the patches
> still apply it's probably all done (I always do a meld review too to
> see what changed).

I see, you are confusing two things here. Having the source from Git vs
using tarballs. And using Salsa does not requires you to have the source
from a Git and not a tarball.

> If someone can make a tool so that this workflow still works, but a
> copy gets dumped into salsa, then I don't mind this new
> requirement. But otherwise it seems like a big imposition.

You don't need more than to learn how to use git commit and git rebase,
TBH. Having packages in Git doesn't means you have to use gbp-*.

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

This is part of my workflow for actual builds:
https://github.com/resnullius/deb-build-pkg/blob/master/deb-build-pkg
https://github.com/resnullius/docker-deb-devel/blob/master/base/scripts/entrypoint.sh

And it handles packages on Git. The first is just an interface for
docker and the Docker entrypoint. The entrypoint is where the actual
packaging happens and as you can see, they are the regular:
dpkg-buildpackage, uscan, mk-build-deps.

> Josch's suggestion that just recording the workflow in metadata would
> be useful is a good one. Then at least you know what other maintainers
> are doing. And dgit's approach of unifying the archive representation
> and the git representation is definitely progress in the right
> direction. I was very sad to find that it didn't help us 'tarball
> people' directly at all (except I guess to reduce exactly this
> pressure to stop doing it and use git).
>
> So why mandate salsa rather than make dgit more official? That lets
> the people that want to use git use it for everything - even the
> packages that were just uploaded as tarballs. And explicitly _doesn't_
> remove the archive VCS interface. And it supports all the git-based
> workflows. (someone should probably tell IWJ this conversation is
> occuring as he's taken a bit intererest in it, but no longer reads
> debian-devel). Does than not solve a good chunk of this 'make it easy
> to fix other packages using your standard tools' desire?

Salsa as default only means you have to make commits, not use any
different tooling. Just git commit and git push, nothing else.

Maybe there's a misunderstanding here where workflows need to change,
but that's not true.

There are workflows possible thanks to branches on Git, yes, but that
does not mean you have to use them in order to use Git.

Kind regards,
Jose

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

#111405

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

hi,

just adding some random data points to this thread:

- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
  where I can.
- I like salsa. (though I think for many new contributors this is rather
  a barrier "why not use github" directly. Also salsa is Debian only,
  which also is a barrier for some.)
- I love autopkgtests. 
- I hardly every look at the autopkgs logs on salsaci, cause I find
  them incomprehensible and the javascript "UX" makes me wanna chop wood.
- I also think disallowing single-person maintainership would be very unwise,
  though I agree team maintenance in general is probably better than
  single-person maintainership. Still disallowing single-person maintainership
  doesnt make a team and motivation lost is often motivation lost forever.


-- 
cheers,
	Holger

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

The era of global warming has ended, the era of global boiling has arrived.
The heat is unbearable, and the level of fossil fuel profits & climate inaction
is unacceptable. Humanity has unleashed destruction. This must not inspire
despair, but action." — UNSG @AntonioGuterres

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

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

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

csiph-web