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

#111354 — Re: finally end single-person maintainership

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?
 
> A second good example is my package "nbd".

Which is maintained on Salsa which I personally consider nice.

> Similarly, the fact that a package has a "team" listed as its maintainer
> not in any wayimply that the team has more than zero members.

ACK,

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

I was sometimes confronted with those barriers.

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

Kind regards
   Andreas.

-- 
https://fam-tille.de

[toc] | [next] | [standalone]

#111355

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?

I did that as part of my latest upload :)

https://salsa.debian.org/wouter/logtool

(I realize now that I forgot to add VCS headers... ah well, next time
I'm sure)

[...]
> > 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.
> 
> I was sometimes confronted with those barriers.

And that's not good, and we should work on those.

I just don't think that mandating team maintenance drops those barriers.

-- 
     w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}

I will have a Tin-Actinium-Potassium mixture, thanks.

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

#111356

Hi again,

Am Sun, Apr 07, 2024 at 04:10:15PM +0200 schrieb Wouter Verhelst:
> > 
> > What is your opinion about pushing logtool to Salsa?
> 
> I did that as part of my latest upload :)
> 
> https://salsa.debian.org/wouter/logtool

Great.
 
> (I realize now that I forgot to add VCS headers... ah well, next time
> I'm sure)

This happens.  I was seeking Salsa before asking - if people do so
they'll find it.

> And that's not good, and we should work on those.
> 
> I just don't think that mandating team maintenance drops those barriers.

Do you think that mandating Salsa is a sensible step in this direction?

Kind regards
   Andreas. 

-- 
https://fam-tille.de

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

#111842

On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz <bernd@bzed.de> wrote:
>Hi,
>
>On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>> 
>> Do you think that mandating Salsa is a sensible step in this
>> direction?
>
>
>Absolutely.
>
>Also I think requiring a common git layout and the usage of recent
>versions of dh should be required. Using merge requests instead of
>sending patches should be recommended, or at least we could have a
>service that creates and maintains merge requests based on patches
>found in bug reports.
>
>All these things should make it much more easy for other people or
>automated tools to send merge requests or keep maintaining a package in
>case the original maintainer becomes MIA.


Mandating a specific git layout is a big jump from not requiring a VCS at all.  Do you really think we should remove packages from Debian which don't conform to a specific layout (in my mind, that's the implication of mandating it)?

Scott K

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

#111853

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

On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote:
> > > All these things should make it much more easy for other people or
> > > automated tools to send merge requests or keep maintaining a
> > > package in
> > > case the original maintainer becomes MIA.
> > 
> > 
> > Mandating a specific git layout is a big jump from not requiring a
> > VCS at all. 
> 
> yes, its a big jump, but we are in 2024 and a modern workflow should be
> expected from a modern distribution.
People will resign.

-- 
WBR, wRAR

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

#111855

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

Bernd Zeimetz <bernd@bzed.de> writes:

> On Mon, 2024-05-20 at 20:47 +0000, Scott Kitterman wrote:
>> > 
>> > All these things should make it much more easy for other people or
>> > automated tools to send merge requests or keep maintaining a
>> > package in
>> > case the original maintainer becomes MIA.
>> 
>> 
>> Mandating a specific git layout is a big jump from not requiring a
>> VCS at all. 
>
> yes, its a big jump, but we are in 2024 and a modern workflow should be
> expected from a modern distribution.

Attempts at top-down imposition of new methods on Debian strike me as
being unlikely to induce joy in anyone involved.

After all, We're a self-selecting group of people who are prone to
repeatedly walking the road less travelled.

Do we even have a consensus on which layout is "best"?

DEP-14 exists, but that is still candidate status, and even if it were
accepted, it has a section "When to not follow the above recommendations"

I suspect that there's a decent chunk of developers who generally just
follow the status quo of every package they work on, without fuss.

I rather like dgit for reducing the extent I have to think about this
sort of thing, but I note that at least one person in this thread seems
vexed by it, so we cannot even agree on the merits of that, apparently.

Could it be that we mostly hear from the people at the extremities of
opinion on issues like this?  If so, I don't see how we're going to
establish a consensus, and without that it's not going to be easy (or
worthwhile) to pick a layout, nor to try and impose that on others.

For anyone with an opinion, I'd suggest that you should try to make sure
that DEP-14 reflects your opinion, and then work on getting people to
adopt the use of DEP-14 and/or get DEP-14 accepted.

That way, you'll be able to work towards consistency without having a
massive and pointless fight, that will be sure to harden some people's
opinion against you, making your wished-for outcome that much less
likely.

Cheers, Phil.

P.S. I don't really give a damn about this issue, and am happy to use
DEP-14 in general, or follow the current state of a particular package.
If DEP-14 were to change radically, I'd be willing to switch to new
recommendations, so if you care, please make it better if you can.
-- 
Philip Hands -- https://hands.com/~phil

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

#111858

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

On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote:
> >> > All these things should make it much more easy for other people or
> >> > automated tools to send merge requests or keep maintaining a
> >> > package in
> >> > case the original maintainer becomes MIA.
> >> 
> >> 
> >> Mandating a specific git layout is a big jump from not requiring a
> >> VCS at all. 
> >
> > yes, its a big jump, but we are in 2024 and a modern workflow should be
> > expected from a modern distribution.
> 
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.
> 
> After all, We're a self-selecting group of people who are prone to
> repeatedly walking the road less travelled.
> 
> Do we even have a consensus on which layout is "best"?
Definitely no.
Also all of them are bad in some way, which is expected when you wrap
incompatible workflows.

> For anyone with an opinion, I'd suggest that you should try to make sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
How do you envision this for people who are against storing upstream
sources in the repo? Having two mutually exclusive options in DEP-14?


-- 
WBR, wRAR

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

#111870

Hi Philip (2024.05.21_10:05:59_+0000)
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.

Yeah, that doesn't fly in community projects like Debian at all.

However, there is a gap between getting a DEP approved and getting the
rest of the project to fully embrace it. That's something that takes
some leadership in the project. DPLs are in a great position to help
drive these changes forward.

> I suspect that there's a decent chunk of developers who generally just
> follow the status quo of every package they work on, without fuss.

Yeah, probably most.

> I rather like dgit for reducing the extent I have to think about this
> sort of thing, but I note that at least one person in this thread seems
> vexed by it, so we cannot even agree on the merits of that, apparently.

On the other hand, dgit is only useful if you have a certain view of the
world, that hasn't aligned with how I've done Debian packaging. I mean,
an entirely git-centric view where you let go of trying to maintain your
patch stack. So, I've only very briefly played with it. I imagine many
in the project have similarly little experience using it.

The tricky thing with tools like this is that you need to invest a lot
of time using the tool to really get a feel for what it's good / bad at.
You probably need to use it to maintain a complex package, for a while.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

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

#111876

Stefano Rivera <stefanor@debian.org> writes:

> On the other hand, dgit is only useful if you have a certain view of the
> world, that hasn't aligned with how I've done Debian packaging. I mean,
> an entirely git-centric view where you let go of trying to maintain your
> patch stack.

dgit has no problems with you maintaining your patch stack, at least as I
understand that statement.  I personally use the dgit-maint-debrebase(7)
workflow, which is a fancy way of maintaining your patch stack using an
equivalent of git rebase, since I love git rebase and use it all the time.
But I used the dgit-maint-gbp(7) workflow, which is basically just the
normal git-buildpackage workflow, for years and still use it for some of
my packages and it works fine.

Maybe you mean something different by this than I think you meant.

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

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

#111899

Hi Stefano,

Am Tue, May 21, 2024 at 02:36:47PM +0000 schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+0000)
> > Attempts at top-down imposition of new methods on Debian strike me as
> > being unlikely to induce joy in anyone involved.
> 
> Yeah, that doesn't fly in community projects like Debian at all.

ACK.
 
> However, there is a gap between getting a DEP approved and getting the
> rest of the project to fully embrace it. That's something that takes
> some leadership in the project. DPLs are in a great position to help
> drive these changes forward.

I confirm I see myself in the "help to get something happening"
position.  I'm fully aware that we can't push anything top-down.  I see
a big step forward in permitting some progress in the first place since
I assume we have quite some volunteers who would implement this progress
which is just not permitted by some rules we have.
 
(My current challenge is to even find out what is broken first as
I'm currently learning in the lintian case.)

Kind regards
   Andreas. 

-- 
https://fam-tille.de

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

#111879

> I would rather see a small but very stable base distribution, with the
> option to add features on top.

Doesn't this conflict with debian being universal?


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

#111889 — broad goals (Re: finally end single-person maintainership)

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

On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote:
> > I would rather see a small but very stable base distribution, with the
> > option to add features on top.
> Doesn't this conflict with debian being universal?
 
for some it surely does, while for others it's needed to make Debian the
universal OS.

fun! ;)


-- 
cheers,
	Holger

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

Only change is constant.

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

#111869

> Do you think that mandating Salsa is a sensible step in this direction?

No. It would increase my workload for all the stuff where I am also upstream.


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

#111880

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

> Could you explain that? I do similar things (just that not everything
> of it is published for $reasons), and I can't see how its increasing my
> workload as git and CIs are doing these things for me.
> 
> So I'm always curious on why workloads increase just by maintining a
> package on salsa.

It doesn't increase because of salsa. It increases because instead of being 
maintained on once place it goes in 2 places, where I still have to maintain 
both (by myself, mostly).

I normally run "make deb-pkg" which creates a .orig.tar.gz, signs it, then 
puts the debian/ directory somewhere suitable and builds it with dpkg-
buildpackage.

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.

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.

So, extra complications for no actual advantage, from my experience.

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

#111882

On Wed, 22 May 2024 at 00:40, Russ Allbery <rra@debian.org> wrote:
>
> 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.

Yeah I am doing the same, and gradually switching all my packages that
used to have a separate upstream/downstream history to a single merged
tree. This can be done post-facto with some one-time git rocket
surgery, doesn't have to be the case from day one. It's a huge
improvement, and with gpp patch-queue I can just cherry-pick upstream
commits directly, with no hassle whatsoever. It works really nicely,
and gbp supports it just fine as a workflow, even while still checking
in upstream release tarballs in pristine-tar.

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

#111884 — Re: Documenting packaging workflows (was: finally end single-person maintainership)

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

Salvo Tomaselli <tiposchi@tiscali.it> writes:

> I'm also annoyed at the default ci configuration for salsa, because importing a 
> project makes a CI start to run, then fail. Then I have to one by one point 
> the CI file to something else, but the project will forever be "CI failing" and 
> will be reported forever as such in my status page.

If you go to the individual pipeline that you never wanted to run (e.g.
click on the red 'X' in the overview, or the pipelines view), then
you'll see a 'Delete' button in the top-right corner.

If you delete all the pipelines in a repo, it reverts to thinking CI is
not setup, and you'll no longer be told that the repo is 'CI failing'.

BTW I just confirmed that by setting up a new repo for the purpose, and
was surprised to find that I also needed to configure CI in order to get
it to fail, so I think you may be right that it was once doing the
annoying thing you describe, but it didn't do it to me just now.

HTH

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

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

#111887 — Re: Documenting packaging workflows (was: finally end single-person maintainership)

My standard workflow

I use gbp and dgit

gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild  (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa result if everythings is ok
... if not work and push commits to salsa
... then relase with
dch -r
dgit --gbp build-source
dgit --gbp push-source
gbp push


I like the way dgit help for the upload.

Cheers

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

#111888 — Re: Documenting packaging workflows

Johannes Schauer Marin Rodrigues <josch@debian.org> writes:

> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes
> them better than the alternatives.

> Personally, I start packaging something without git, once I'm satisfied
> I use "gbp import-dsc" to create a packaging git with pristine-tar (and
> that will *not* have DEP14 branches and it will use "master" instead of
> "main") and then I push that to salsa and do more fixes until the
> pipeline succeeds and lintian is happy. My patches are managed using
> quilt in d/patches and upstream git is not part of my packaging git. I
> upload using "dgit --quilt=gbp push-source".

> Would another workflow make me more happy? Probably! But how would I get
> to know them or get convinced that they are better? Maybe I'm missing
> out on existing write-ups or video recordings which explain how others
> do their packaging and why it is superior?

One of the lesser-known things found in the dgit package is a set of man
pages describing several packaging workflows.  These certainly aren't
exhaustive of the packaging workflows that people use (for one thing, they
are designed to explain how to use dgit in each workflow, and thus of
course assume that you want to do that), but they're both succinct and
fairly thorough and I found reading them very helpful.  dgit(1) has a list
at the start.

dgit-maint-debrebase(7) is the workflow that I now use, pretty much
exactly as described.  The primary thing that I like about it is that I
never have to deal with the externalized patches or with quilt (I used
quilt for years, and I have developed a real dislike for it and its odd
quirks -- I would rather only deal with Git's odd quirks), and I can use a
git-rebase-like command in much the same way that I use it routinely for
feature branches when doing upstream development.  Then some Git magic
happens behind the scenes to make this safe, and while I don't understand
the details, it has always worked fine, so I don't really care how it
works.  :)

I like having a Git history from as early in the process as possible and I
want the upstream Git history to refer to while I work on packaging (and
want to be able to cherry-pick upstream commits), so I generally start
with a tagged release from the upstream Git repository, create a branch
based on it, and start writing and committing debian/* files.

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

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

#111891 — Re: Documenting packaging workflows (was: finally end single-person maintainership)

> I would be *very* interested in more in-depth write-ups of the workflows
> other DDs prefer to use, how they use them and what they think makes them
> better than the alternatives.


Packages of which I am not the creator:

salsa project and gbp

UNLESS they are qt/kde stuff

in which case

salsa project and debian/ directory kept on salsa, because that's how the team 
does it.

Packages of which I am the creator:

debian/ directory kept in the same tree as the rest of the project, then a 
Makefile to pretend that they are separate entities, that generates a .orig and 
then builds the whole thing extrating the .orig and placing the debin/ 
directory appropriately.

It is for this case that I would be annoyed by having to use salsa. Because 
the projects are not on salsa to begin with.

I'm also annoyed at the default ci configuration for salsa, because importing a 
project makes a CI start to run, then fail. Then I have to one by one point 
the CI file to something else, but the project will forever be "CI failing" and 
will be reported forever as such in my status page.

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

#111898 — Documenting packaging workflows (was: finally end single-person maintainership)

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

Quoting Luca Boccassi (2024-05-22 01:45:54)
> On Wed, 22 May 2024 at 00:40, Russ Allbery <rra@debian.org> wrote:
> > 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.
> 
> Yeah I am doing the same, and gradually switching all my packages that
> used to have a separate upstream/downstream history to a single merged
> tree. This can be done post-facto with some one-time git rocket
> surgery, doesn't have to be the case from day one. It's a huge
> improvement, and with gpp patch-queue I can just cherry-pick upstream
> commits directly, with no hassle whatsoever. It works really nicely,
> and gbp supports it just fine as a workflow, even while still checking
> in upstream release tarballs in pristine-tar.

I would be *very* interested in more in-depth write-ups of the workflows other
DDs prefer to use, how they use them and what they think makes them better than
the alternatives.

Personally, I start packaging something without git, once I'm satisfied I use
"gbp import-dsc" to create a packaging git with pristine-tar (and that will
*not* have DEP14 branches and it will use "master" instead of "main") and then
I push that to salsa and do more fixes until the pipeline succeeds and lintian
is happy. My patches are managed using quilt in d/patches and upstream git is
not part of my packaging git. I upload using "dgit --quilt=gbp push-source".

Would another workflow make me more happy? Probably! But how would I get to
know them or get convinced that they are better? Maybe I'm missing out on
existing write-ups or video recordings which explain how others do their
packaging and why it is superior?

Any hints or future debconf workshop invitations welcome. :)

Thanks!

cheers, josch

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

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

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

csiph-web