Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-05-23 at 22:00 +0200, Sven Mueller wrote:
> 
> 
> Am 23.05.2024 20:16 schrieb Bernd Zeimetz :
> > On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> > > Yes, but unironically: experimental is a side branch, unstable is
> > a
> > > MR, 
> > > and testing is the main branch.
> > > 
> > > It is entirely valid to be dissatisfied with the turnaround time
> > of
> > > the 
> > > existing CI, but what we're seeing here is the creation of a
> > parallel
> > > structure with as-of-yet unclear scope.
> > 
> > You are wasting a lot of hardware resources we don't have by
> > abusing
> > experimental as a CI. Don't do that.
> 
> I have a string feeling that it is easier for Debian to set up more
> hardware (I'm thinking of the "how should we spend the money we have"
> mails) than it is to find more maintainers.

Yes, but I think its a very valid request not to waste buildd time for
CIing your packages.
And maintaining hardware also needs human resources, its not just done
by buying new hardware.


-- 
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Sven Mueller]

Am 23.05.2024 20:16 schrieb Bernd Zeimetz :On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Yes, but unironically: experimental is a side branch, unstable is a

> MR, 

> and testing is the main branch.

> 

> It is entirely valid to be dissatisfied with the turnaround time of

> the 

> existing CI, but what we're seeing here is the creation of a parallel

> structure with as-of-yet unclear scope.



You are wasting a lot of hardware resources we don't have by abusing

experimental as a CI. Don't do that.I have a string feeling that it is easier for Debian to set up more hardware (I'm thinking of the "how should we spend the money we have" mails) than it is to find more maintainers. Using the resources we have if that saves time on the developer side seems reasonable to me. But IMHO, it would be better to use Salsa CI für that, not experimental.

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Hi,
> 
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
> 
> > > > It could be argued that testing migration is a CI process. >>
> > > > Its a CI process at a way too late stage.
> > > Also, uploading to test a merge request is not the right thing to
> > > do.
> 
> > If the archive is a VCS then uploading an untested package to
> > experimental
> > to run tools is pushing a commit to run CI.
> > *shrug*
> 
> Yes, but unironically: experimental is a side branch, unstable is a
> MR, 
> and testing is the main branch.
> 
> It is entirely valid to be dissatisfied with the turnaround time of
> the 
> existing CI, but what we're seeing here is the creation of a parallel
> structure with as-of-yet unclear scope.

You are wasting a lot of hardware resources we don't have by abusing
experimental as a CI. Don't do that.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Luca Boccassi]

On Thu, 23 May 2024 at 03:01, Simon Richter  wrote:
>
> Hi,
>
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
>
> >>> It could be argued that testing migration is a CI process. >> Its a CI 
> >>> process at a way too late stage.
> >> Also, uploading to test a merge request is not the right thing to do.
>
> > If the archive is a VCS then uploading an untested package to experimental
> > to run tools is pushing a commit to run CI.
> > *shrug*
>
> Yes, but unironically: experimental is a side branch, unstable is a MR,
> and testing is the main branch.
>
> It is entirely valid to be dissatisfied with the turnaround time of the
> existing CI, but what we're seeing here is the creation of a parallel
> structure with as-of-yet unclear scope.
>
> Can we define the scope as "quick-turnaround unofficial validation",
> because that's the niche that is currently underserved?

The main problem is not turnaround (it's terrible ofc), it's that a
broken upload to unstable affects _everybody_, while a CI run on Salsa
is private and doesn't get in the way of other developers.

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/23/24 04:32, Andrey Rakhmatullin wrote:


It could be argued that testing migration is a CI process. >> Its a CI process 
at a way too late stage.

Also, uploading to test a merge request is not the right thing to do.



If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*


Yes, but unironically: experimental is a side branch, unstable is a MR, 
and testing is the main branch.


It is entirely valid to be dissatisfied with the turnaround time of the 
existing CI, but what we're seeing here is the creation of a parallel 
structure with as-of-yet unclear scope.


Can we define the scope as "quick-turnaround unofficial validation", 
because that's the niche that is currently underserved?


   Simon

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

[Paul Gevers]

Hi

On 21-05-2024 1:08 p.m., Sean Whitton wrote:

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


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


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


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote:
> > > You can run autopkgtests locally, you do not need Salsa for that.
> > 
> > Also, Debian runs autopkgtests on all packages that provide them, and
> > makes passing them on all supported architectures a requirement for 
> > testing migration.
> 
> Uploading to check autopkgtests is an absolute waste of ressources. I
> really hope nobody uploads a package without running the tests
> somewhere else.
> 
> > 
> > It could be argued that testing migration is a CI process.
> > 
> 
> Its a CI process at a way too late stage.
> Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to experimental
to run tools is pushing a commit to run CI.
*shrug*

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Wed, 2024-05-22 at 21:26 +0900, Simon Richter wrote:
> Hi,
> 
> On 5/22/24 20:34, Bill Allombert wrote:
> 
> > You can run autopkgtests locally, you do not need Salsa for that.
> 
> Also, Debian runs autopkgtests on all packages that provide them, and
> makes passing them on all supported architectures a requirement for 
> testing migration.

Uploading to check autopkgtests is an absolute waste of ressources. I
really hope nobody uploads a package without running the tests
somewhere else.

> 
> It could be argued that testing migration is a CI process.
> 

Its a CI process at a way too late stage.
Also, uploading to test a merge request is not the right thing to do.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/22/24 20:34, Bill Allombert wrote:


You can run autopkgtests locally, you do not need Salsa for that.


Also, Debian runs autopkgtests on all packages that provide them, and 
makes passing them on all supported architectures a requirement for 
testing migration.


It could be argued that testing migration is a CI process.

   Simon

Re: finally end single-person maintainership

[Luca Boccassi]

On Wed, 22 May 2024 at 12:35, Bill Allombert  wrote:
>
> On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > >
> > > When a change leads to a RC bug a month or three after having be
> > > part of a package, fixing the problem falls on the maintainer and not
> > > on the change author. Even correct changes can trigger latent bugs
> > > in software.
> >
> > Yet another reason why using Salsa and its CI *and having autopkg-
> > tests* is so important - contributors can test their changes before
> > even asking to merge them.
>
> You can run autopkgtests locally, you do not need Salsa for that.

It can, but it's really a massive pain. git push and go make a cup of
tea is so much nicer.
Nowadays I run locally only when debugging complex issues, otherwise
it's all delegated to Salsa.

> > And yes, its up to the 'expert' maintainer
> > of the package to ensure there are proper tests in place. Because even
> > that expert is a human only and we all make mistakes.
>
> Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in 
> electricity
> and in carbon emission, that we cannot completely ignore.
>
> In any case, it is not realistic to expect tests to detect all kind of bugs, 
> alas.

The cost of running those same builds and tests locally is pushed onto
the developer though, and their electricity bill. By using Salsa, the
cost is pushed to the project and our sponsors - which seems the right
thing to me.

Re: finally end single-person maintainership

[Bill Allombert]

On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > 
> > When a change leads to a RC bug a month or three after having be
> > part of a package, fixing the problem falls on the maintainer and not
> > on the change author. Even correct changes can trigger latent bugs
> > in software.
> 
> Yet another reason why using Salsa and its CI *and having autopkg-
> tests* is so important - contributors can test their changes before
> even asking to merge them. 

You can run autopkgtests locally, you do not need Salsa for that.

> And yes, its up to the 'expert' maintainer
> of the package to ensure there are proper tests in place. Because even
> that expert is a human only and we all make mistakes.

Indiscriminate use of Salsa CI is not free, there is a cost in hardware, in 
electricity
and in carbon emission, that we cannot completely ignore.

In any case, it is not realistic to expect tests to detect all kind of bugs, 
alas.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

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

[Holger Levsen]

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.


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Holger Levsen]

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.


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andreas Tille]

Hi Stefano,

Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+)
> > 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

Re: finally end single-person maintainership

[Andreas Tille]

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

Re: finally end single-person maintainership

[Johannes Schauer Marin Rodrigues]

Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > Quoting Andreas Tille (2024-04-10 22:44:25)
> > > > I do understand the argument that lots of different workflows
> > > > adds
> > > > friction. But I'm just still using what used to be _the_ standard
> > > > one
> > > > (insofar as we ever had such a thing). Putting everything in
> > > > salsa/git
> > > > doesn't standardise workflows in itself. I think Ian/Sean
> > > > identified 12
> > > > different git-based methods in their dgit review.
> > > 
> > > I agree that different workflows are not helpful.  We have DEP14[1]
> > > ... but we have no efficient processes to
> > >   a) accept DEPs
> > >   b) dedicate to accepted DEPs
> > 
> > or teach gbp about DEP14. See this git-buildpackage bug from *six*
> > years ago:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444
> 
> DEP14 is a candidate, I can't see that there was any consensus to accept it.
> Just because there is a DEP there is no need to implement it without having
> any consensus on it.

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

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

Thanks!

cheers, josch

signature.asc
Description: signature

Re: finally end single-person maintainership

[Luca Boccassi]

On Wed, 22 May 2024 at 00:40, Russ Allbery  wrote:
>
> Salvo Tomaselli  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.

Re: finally end single-person maintainership

[Russ Allbery]

Salvo Tomaselli  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 (r...@debian.org)  

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

[Bernd Zeimetz]

On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote:
> > > > > > "Otto" == Otto Kekäläinen  writes:
>     Otto> Would you be kind and try to understand the opposing
> viewpoint
>     Otto> by trying it for one day?
> 
>     Otto> You could go to
>     Otto>
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
>     Otto> and conduct a code review?
> 
> I have not done a code review  of that particular patch on salsa.
> I have done code reviews on salsa, many other gitlabs, and github.
> I find doing a code review in a web page far more frustrating than in
> email.

There are external paid integrations for gitlab which provide the
feature to send emails with full diffs for projects, so there should be
a way to add this feature to the Debian gitlab. I would guess by using
the API.
You can comment on merge requests by email already and you should even
be able to create a new one by mail (that feature exists in gitlab, no
idea if its enabled on salsa and I've never tried it anywhere else).

So I think if this is a feature more people are missing, find them and
spend some time together on creating an external service for salsa that
provides it would be well spent time.



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-05-21 at 12:05 +0200, Philip Hands wrote:
> 
> 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.
> 

To be honest: in my opinion the whole DEP process is flawed. I doubt
that even the first DEP that created DEPs was had enough consent to be
accepted in general. It did just not bother enough people to be against
it and it made some others happy, so it was accepted to exist.



With the future more and more being container and cloud driven, I would
indeed rather see a Debian that is completely maintained in one
location, with as much CI and testing as possible. Keeping everything
reproducible and maybe - in the future - having a rolling release,
which requires these things.
Even if that means that we loose packages and developers. Which would
be sad, but I think healthy for a long term future of Debian.

I would rather see a small but very stable base distribution, with the
option to add features on top. Which do not necessarily need to be
maintained at the same place as Debian, but could use Debian's
infrastructure as its done now. Each "feature" could have its own
release cycle as it fits. Sury's PHP packaging would be a prime example
for that. We run thousands of PHP driven websites and rarely anyone
wants to use what Debian ships as stable (or even from a still
supported oldstable).


The radical way would be to GR this into place with a *long* grace
period. Risky, but better than having a big slow distribution nobody
needs anymore at some point.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-05-21 at 15:50 +0200, Salvo Tomaselli wrote:
> > 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.

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.


Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Otto Kekäläinen]

Hi!

On Sun, 19 May 2024 at 20:48, Don Armstrong  wrote:
>
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never 
> > been
> > really maintained. I am actually one of the very few users of this package
> > and I tried several times to get the maintainers to do a new upload but they
> > were clearly not interested.
>
> It's more that I'm prioritizing spending my (very) limited Debian time
> on keeping bugs.debian.org and debbugs itself working (and [very slowly]
> developing a new version of Debbugs with a more modern design in the
> hopes that others will contribute.)

Everyone else has very limited time to contribute to Debian as well.
Therefore we all need to think about what is the most efficient
workflow.

Perhaps you could consider how you can be a force multiplier and scale
your work? You could for example add some of the recent contributors as
developers or maintainers at
https://salsa.debian.org/groups/debbugs-team/-/group_members so they
can review/merge/push code, and you could review all submissions at
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests and
grow those contributors into co-maintainers instead of just ignoring
them?

Perhaps you can also consider optimizing your git workflows? For
example in the case of
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 you
could have simply pressed "Merge" and everything would be good. Now
you decided to not use any of the support Salsa/Salsa-CI provides, you
did extra work to cherry-pick some commits (but not all), added your
extra commit to break the build and now there is new follow-up work to
be done for lapses that could have been easily avoided if Salsa-CI was
enabled.. (I did submit MR!20 though, you can just merge it)

I started this thread "Salsa - best thing in Debian in recent years?"
by asking people who resist Salsa to at least try using it for a while
before criticizing it so much.

What happened in this episode is a case in point. You sit in a "local
optima" of your current workflow and are not willing to invest a bit
extra effort to get to a place where Salsa+Salsa-CI can benefit and
decrease your extra work burden. Now both you and me ended up having
to do extra work that could easily have been avoided..

Personally I like Salsa a lot, and collaboration with maintainers who
embrace Salsa is a breeze, and I feel that my limited Debian time is
relatively productive. That is all thanks to Salsa. I wish those who
are not yet using it would give it a sincere try.

Re: finally end single-person maintainership

[Russ Allbery]

Stefano Rivera  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 (r...@debian.org)  

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

[Sam Hartman]

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

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

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

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

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

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

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

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

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

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

--Sam

Re: finally end single-person maintainership

[Stefano Rivera]

Hi Philip (2024.05.21_10:05:59_+)
> 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

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

[Luca Boccassi]

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

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

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

[Holger Levsen]

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

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

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

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

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


-- 
cheers,
Holger

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

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


signature.asc
Description: PGP signature

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

[Andrey Rakhmatullin]

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

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


-- 
WBR, wRAR


signature.asc
Description: PGP signature

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

[Simon Richter]

Hi,

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


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



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


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


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



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


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

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


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


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


   Simon

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

[Sean Whitton]

Hello,

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

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

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sean Whitton]

Hello,

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

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

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

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Simon McVittie]

On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote:
> Exact quote: "These commits have intentionally no debian/changelog
> updates as it causes every single rebase or cherry-pick of a commit to
> always have a merge conflict. It is much better to have all commits
> as-is, and then right before upload just run gbp-dch --auto to
> automatically generate the changelog."

This is not unique to Debian packaging: upstream projects that maintain
a GNU-style ChangeLog and/or NEWS file have the same problem, for the
same reasons.

In the projects where I'm an upstream maintainer, we've generally solved
this by having the detailed ChangeLog either auto-generated from `git log`
at release time or not existing at all, and writing a more user-facing
summary of changes into the NEWS file periodically during development
(generally pushed directly by a maintainer rather than going via a merge
request, because adding text to NEWS hopefully can't cause regressions),
and in particular ensuring NEWS is up-to-date as part of the release
procedure (a maintainer/release manager responsibility).

Using `gbp dch` to maintain debian/changelog is analogous to that
technique - the version auto-generated from `git log` acts as a first
draft, and if a contributor wants to adjust the wording used in
debian/changelog to be less about fine-grained technical details and
more user-facing, they can use `gbp dch` to summarize all changes up
to now, make the desired adjustments, `git commit -m 'Update changelog'`
and push. Next time the changelog needs to be updated, `gbp dch` will
start from just after the most recent change that touched
debian/changelog.

smcv

Re: finally end single-person maintainership

[Luca Boccassi]

On Tue, 21 May 2024 at 03:16, Simon Richter  wrote:
>
> Hi,
>
> On 5/21/24 10:43, Luca Boccassi wrote:
>
> >> The ecosystem, however, does not support our workflows, and adapting it
> >> to do that is even more effort than maintaining our own tools. [...]
>
> > That's a problem of our workflows, which are horrible. The solution is
> > not to double down on them.
>
> Our workflows are largely influenced by what we do here: we maintain
> packages. This is different from "developing software", or "operating
> infrastructure."

Not really, our workflows are mainly influenced by whatever was
available in the late 90s and has just kept chugging along on life
support - hence FTP uploads, GPG signing tarballs, sending commands
via emails. There are plenty of ways to maintain packages that do not
involve any of that - see SUSE's OBS, etc.

> If we can improve the workflows, then I'm all for it. What does not
> work, however, is to replace them with workflows from a different task.
>
> All we are doing here is providing a mapping of the packaging workflow
> onto a git software development workflow. It still remains a packaging
> workflow, because the *goal* of the workflow is the completion of
> packaging tasks.
>
> Providing an implementation layer does not change the goal layer, and
> GitLab does not provide any tools on the goal layer.
>
> If we had buttons in GitLab "import new upstream release" or "show
> issues affecting the stable release branch", I would consider that as
> support for a packaging workflow. As it is now, GitLab only supports the
> workflows that the implementation layer below the goal layer typically
> uses, including workflows that break the upper layer.

There's factually no need for any of that. As per
https://trends.debian.net/ most packages today are on Salsa despite
the lack of these buttons. The goal is to have an actual source code
management system that allows forking, branching, rebasing, merging,
navigating history, running integration tests. The fact that at some
point one has to interact with crufty old ftp servers and dusty
tarballs is not really relevant. Having a pipeline stage at the end of
salsa-ci that does an upload for you would be a nice improvement, but
it's by no means necessary to use Salsa effectively and productively,
as the vast majority of cases are already showing in reality.

> >> At the very least, GitLab integration would allow me to automate such a
> >> simple thing as changelog handling in a more comfortable way than
> >> displaying instructions how to download the conflicting branch into
> >> local git, resolve the conflicts manually, and force-push the branch to
> >> solve the problem.
>
> > gbp dch --commit --release
>
> Where is that button in GitLab?

If that is needed, why isn't there a button on the ftp server instead of dput?

Re: finally end single-person maintainership

[Philip Hands]

Bernd Zeimetz  writes:

> On Mon, 2024-05-20 at 20:47 +, 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


signature.asc
Description: PGP signature

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

[Andrey Rakhmatullin]

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


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Russ Allbery]

Simon Richter  writes:

> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be performed later.

This is not a Debian-specific problem and has nothing to do with any
special properties of our workflows or differences between packaging and
other software maintenance tasks.  It's a common issue faced by everyone
who has ever maintained a software package in Git and wanted to publish a
change log.

There are oodles of tools and workflows to handle this problem, ranging
from writing the change log based on the Git commits when you're making
the release to accumulating fragments of release notes in separate files
and using a tool to merge them.  dch's approach of using the Git commit
messages is one of the standard solutions, one that will be familiar to
many people who have faced this same problem in other contexts.

The hard part with these sorts of problems is agreeing on the tool and
workflow to use to solve it, something Debian struggles with more than
most software projects because we lack a decision-making body that can say
things like "we're going to use scriv" and make it stick.  But that isn't
because packaging is a special problem unsuited to Git.  Git has a rich
ecosystem with many effective solutions to problems of this sort.  It's
because we've chosen a governance model that intentionally makes central
decision-making and therefore consistency and coordination difficult, in
exchange for other perceived benefits.

-- 
Russ Allbery (r...@debian.org)  

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/21/24 10:43, Luca Boccassi wrote:


The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]



That's a problem of our workflows, which are horrible. The solution is
not to double down on them.


Our workflows are largely influenced by what we do here: we maintain 
packages. This is different from "developing software", or "operating 
infrastructure."


If we can improve the workflows, then I'm all for it. What does not 
work, however, is to replace them with workflows from a different task.


All we are doing here is providing a mapping of the packaging workflow 
onto a git software development workflow. It still remains a packaging 
workflow, because the *goal* of the workflow is the completion of 
packaging tasks.


Providing an implementation layer does not change the goal layer, and 
GitLab does not provide any tools on the goal layer.


If we had buttons in GitLab "import new upstream release" or "show 
issues affecting the stable release branch", I would consider that as 
support for a packaging workflow. As it is now, GitLab only supports the 
workflows that the implementation layer below the goal layer typically 
uses, including workflows that break the upper layer.



At the very least, GitLab integration would allow me to automate such a
simple thing as changelog handling in a more comfortable way than
displaying instructions how to download the conflicting branch into
local git, resolve the conflicts manually, and force-push the branch to
solve the problem.



gbp dch --commit --release


Where is that button in GitLab?

That's my point: GitLab is a step *back* from the commandline tools for 
git integration.


   Simon

Re: finally end single-person maintainership

[Otto Kekäläinen]

Hi Simon!

> > A better approach would not treat Debian metadata as git data. Even the
> > most vocal advocate of switching everything to Salsa writes in his MR
> > that the changelog should not be touched in a commit, because it creates
> > conflicts, and instead a manual step will need to be performed later.

Not exactly, I said it is unnecessary work and doing it will just
cause more work.

Exact quote: "These commits have intentionally no debian/changelog
updates as it causes every single rebase or cherry-pick of a commit to
always have a merge conflict. It is much better to have all commits
as-is, and then right before upload just run gbp-dch --auto to
automatically generate the changelog."

Thus better not to inject debian/changelog changes in every single
patch and instead..

> > At the very least, GitLab integration would allow me to automate such a
> > simple thing as changelog handling in a more comfortable way than
> > displaying instructions how to download the conflicting branch into
> > local git, resolve the conflicts manually, and force-push the branch to
> > solve the problem.
>
> gbp dch --commit --release

..just let automation handle it, like Luca and many others already
know. Personally I prefer the variant `gbp dch --verbose --auto
--release` but essentially it does the same thing.

Anyway, thanks Simon for doing a review on
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19, at
least I know you have tried using Salsa and are speaking from a point
of some experience when criticising it (unlike apparently many
others).

Back on-topic of single-person maintainership - has anyone made a list
of which packages have only *one* maintainer/git committer and are in
the set of top-1000 or top-5000 Debian packages? We should perhaps ask
those people why they don't have co-maintainership, and why they
resist sharing the development work. Debbugs is one example - it has
multiple open MRs and patches in the bug tracker but somehow the sole
active maintainer does not see value in granting more people commit
permissions. If we learn how these maintainers think, perhaps we can
come up with a model to facilitate having more co-maintenance that can
apply to the exact cases where co-maintenance is missing.

- Otto

Re: finally end single-person maintainership

[Luca Boccassi]

On Tue, 21 May 2024 at 02:08, Simon Richter  wrote:
>
> Hi,
>
> On 5/21/24 07:43, Bernd Zeimetz wrote:
>
> > Also its a gitlab instance. There are all kinds of documentation,
> > tutorials, videos and software for/about gitlab, including lots of
> > beginner friendly options. There is a whole ecosystem around gitlab, it
> > does not depend on a few (two?) developers.
>
> The ecosystem, however, does not support our workflows, and adapting it
> to do that is even more effort than maintaining our own tools. We would
> not even save effort in onboarding, because we'd still need to explain
> the Debian specific aspects, only we would now also need to explain
> which parts of the git workflow we can keep and which parts don't work
> for us.

That's a problem of our workflows, which are horrible. The solution is
not to double down on them. Simply due to demographics, the number of
people who can actually stomach them, let alone maintain them, is only
ever going to shrink.

> The workflows of GitHub (more deployment focused) and GitLab (more
> development focused) are already different enough that I have seen
> organizations struggle after making the wrong choice.

Most large organizations and most distributions have additional
tooling on top of git to perform certain tasks, that's really not a
problem nor surprising, because it's still git and everyone
understands it. Going from git push to gbp push when importing new
releases is really not that disruptive.

> git-buildpackage is not a good mapping of packages to git, but the best
> you can do without modifying git itself. Actually using it requires more
> than beginner-level knowledge of git and suspension of any previously
> held convictions that every single commit should be buildable (because
> gbp likes to generate ones that aren't).

Only when importing new releases, so not really an issue. "Every
commit builds" is a good aspiration but it is incredibly rare that it
is 100% the case with no exception ever at any point in the history of
a repo.

> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to be performed later.
>
> At the very least, GitLab integration would allow me to automate such a
> simple thing as changelog handling in a more comfortable way than
> displaying instructions how to download the conflicting branch into
> local git, resolve the conflicts manually, and force-push the branch to
> solve the problem.

gbp dch --commit --release

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 5/21/24 07:43, Bernd Zeimetz wrote:


Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.


The ecosystem, however, does not support our workflows, and adapting it 
to do that is even more effort than maintaining our own tools. We would 
not even save effort in onboarding, because we'd still need to explain 
the Debian specific aspects, only we would now also need to explain 
which parts of the git workflow we can keep and which parts don't work 
for us.


The workflows of GitHub (more deployment focused) and GitLab (more 
development focused) are already different enough that I have seen 
organizations struggle after making the wrong choice.


git-buildpackage is not a good mapping of packages to git, but the best 
you can do without modifying git itself. Actually using it requires more 
than beginner-level knowledge of git and suspension of any previously 
held convictions that every single commit should be buildable (because 
gbp likes to generate ones that aren't).


A better approach would not treat Debian metadata as git data. Even the 
most vocal advocate of switching everything to Salsa writes in his MR 
that the changelog should not be touched in a commit, because it creates 
conflicts, and instead a manual step will need to be performed later.


At the very least, GitLab integration would allow me to automate such a 
simple thing as changelog handling in a more comfortable way than 
displaying instructions how to download the conflicting branch into 
local git, resolve the conflicts manually, and force-push the branch to 
solve the problem.


   Simon

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> 
> When a change leads to a RC bug a month or three after having be
> part of a package, fixing the problem falls on the maintainer and not
> on the change author. Even correct changes can trigger latent bugs
> in software.


Yet another reason why using Salsa and its CI *and having autopkg-
tests* is so important - contributors can test their changes before
even asking to merge them. And yes, its up to the 'expert' maintainer
of the package to ensure there are proper tests in place. Because even
that expert is a human only and we all make mistakes.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Andreas Tille (2024-04-10 22:44:25)
> > > I do understand the argument that lots of different workflows
> > > adds
> > > friction. But I'm just still using what used to be _the_ standard
> > > one
> > > (insofar as we ever had such a thing). Putting everything in
> > > salsa/git
> > > doesn't standardise workflows in itself. I think Ian/Sean
> > > identified 12
> > > different git-based methods in their dgit review.
> > 
> > I agree that different workflows are not helpful.  We have DEP14[1]
> > ... but we have no efficient processes to
> >   a) accept DEPs
> >   b) dedicate to accepted DEPs
> 
> or teach gbp about DEP14. See this git-buildpackage bug from *six*
> years ago:
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829444


DEP14 is a candidate, I can't see that there was any consensus to
accept it. Just because there is a DEP there is no need to implement it
without having any consensus on it.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Tue, 2024-04-09 at 20:51 +0200, Gioele Barabucci wrote:
> 
> Salsa is a forge, i.e. a combination of a Web interface, a git
> server, 
> and a set of integrated features. In comparison to dgit, salsa has,
> like 
> most forges:
> 
> []

Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.

dgit is an overly complex niche software that should never ever become
a default. We should make it easier for new contributors, not harder.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Bernd Zeimetz]

On Mon, 2024-05-20 at 20:47 +, 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.

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

no, a grace period is absolutely needed of course. I would start with
rejecting NEW uploads and at some point move to automatic upload by git
tag only.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: finally end single-person maintainership

[Scott Kitterman]

On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz  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

Re: finally end single-person maintainership

[Bernd Zeimetz]

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.



Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

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

[Bill Allombert]

On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote:
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never 
> > been
> > really maintained. I am actually one of the very few users of this package
> > and I tried several times to get the maintainers to do a new upload but they
> > were clearly not interested.
> 
> It's more that I'm prioritizing spending my (very) limited Debian time
> on keeping bugs.debian.org and debbugs itself working (and [very slowly]
> developing a new version of Debbugs with a more modern design in the
> hopes that others will contribute.)
> 
> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
> 
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. 

But precisely, one should not need to wait for a new 'upstream release' to
fix RC bugs that prevent the package to be part of a stable release.
Making it non native would allow that without requiring more of your time.

> I've just assumed that anyone using that package was running
> unstable or running debbugs out of git.

Perforce, since the package has not been in stable or testing for years.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

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

[Otto Kekäläinen]

> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
>
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. I've just assumed that anyone using that package was running
> unstable or running debbugs out of git.

I did not notice the release_2.6 branch before. What is the intent
with that branch? Do you want people to submit patches targeting
'master' or 'release_2.6'? How often do you plan to merge it to or
from 'master'?

The 'master' branch is still the default branch. The
https://salsa.debian.org/debbugs-team/debbugs/-/blob/master/README.md
does not mention anything about release_2.6. Should it?

I am a big fan of READMEs and recommend using them to convey guidance
to contributors (assuming you want to have contributors).

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

[Don Armstrong]

On Sun, 19 May 2024, Bill Allombert wrote:
> Also debbugs is a special case:
> The debbugs Debian package (as opposed to the debbugs software) have never 
> been
> really maintained. I am actually one of the very few users of this package
> and I tried several times to get the maintainers to do a new upload but they
> were clearly not interested.

It's more that I'm prioritizing spending my (very) limited Debian time
on keeping bugs.debian.org and debbugs itself working (and [very slowly]
developing a new version of Debbugs with a more modern design in the
hopes that others will contribute.)

> Ideally debbugs should be made non-native so that some else could
> maintain the Debian package.

I'm happy to review patches that get the 2.6 branch of debbugs in shape
where it can be released into Debian again if someone wants to take that
effort. I've just assumed that anyone using that package was running
unstable or running debbugs out of git.

-- 
Don Armstrong  https://www.donarmstrong.com

A people living under the perpetual menace of war and invasion is very
easy to govern. It demands no social reforms. It does not haggle over
expenditures on armaments and military equipment. It pays without
discussion, it ruins itself, and that is an excellent thing for the
syndicates of financiers and manufacturers for whom patriotic terrors
are an abundant source of gain.
 -- Anatole France

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

[Simon Richter]

Hi,

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


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


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



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


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


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



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


At first glance, looks good to me.

Looking at the changes:

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


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


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

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


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



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


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


 - it is currently the only platform

to conduct code reviews on in a way that has automatic testing and
comment-response-resolved -tracking. Doing code reviews patches
attached in email does not have that.


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



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


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


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


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


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


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


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

1. changing an annotated line in a commit hides the annotation when 
looking at 

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

[Otto Kekäläinen]

Thanks for reply Jonas,

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

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

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

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

[Jonas Smedegaard]

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

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

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

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


 - Jonas

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

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

signature.asc
Description: signature

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

[Otto Kekäläinen]

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

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

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

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

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

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

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


- Otto

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

[Simon Richter]

Hi,

On 5/19/24 16:11, Jonas Smedegaard wrote:


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


I agree, that's the key problem.

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


The Debian archive is purpose-built for packaging, while git is 
general-purpose, and does not exactly fit our existing workflows. The 
main thing it adds is collaboration without releases.


It is quite obvious we want something like that, so we need to go back 
to the design of the Debian system and look if we can add flows to 
facilitate that.


The current debate feels a lot like "we need collaboration without 
releases as a feature, git provides that, let's use git", but we have 
more requirements than that, and my feeling is that these are falling by 
the wayside.



...instead of lumping all those discussions into a discussion of ease of
user interface for a single catch-all code forge that maybe make all those
other complications go away by affecting all those questions and that way
implicitly provides *some* answer to them all.


Also, there is a difference between ease of use and intuitivity. GitLab 
does not provide any tools that really make packaging easier. It is 
initially more accessible to non-maintainers, because of familiarity, 
but actual work happens outside of it.


   Simon


OpenPGP_0xEBF67A846AABE354.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Bill Allombert]

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

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

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

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

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

Also debbugs is a special case:
The debbugs Debian package (as opposed to the debbugs software) have never been
really maintained. I am actually one of the very few users of this package
and I tried several times to get the maintainers to do a new upload but they
were clearly not interested.
Ideally debbugs should be made non-native so that some else could maintain the
Debian package.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

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

[Jonas Smedegaard]

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

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


 - Jonas

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

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

signature.asc
Description: signature

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

[Mathias Behrle]

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


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

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

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

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

Best,
Mathias

-- 

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

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

[Jonas Smedegaard]

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

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

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

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

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


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

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

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

 - Jonas

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

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

signature.asc
Description: signature

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

[Paul Gevers]

Two mistakes spotted 

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


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


I think what pere did [3]


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


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Paul Gevers]

Hi all,

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

On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:

  * mandate VCS-tracking
* Yes
  * mandate the use of one specific VCS
* Yes: git


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


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


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


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


Paul

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


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


OpenPGP_signature.asc
Description: OpenPGP digital signature

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

[Jonas Smedegaard]

Quoting Otto Kekäläinen (2024-05-19 05:25:10)
> In a recent long thread on debian-devel you had somewhat negative
> sentiments towards the usefulness of Salsa. I do see you doing good
> technical work for Debian and recently a MR from Bill too, so I was
> thinking that maybe you will change your mind when you read more
> in-depth arguments. This is my attempt to have you think about Salsa
> in a new light:
> 
> On Tue, 9 Apr 2024 at 11:41, Bill Allombert  wrote:
> > Having a repository on salsa or even "packaging team" does not prevent
> > a lack of maintainer, so this is not relevant.
> > Without a maintainer, no contribution will be merged in any case.
> 
> Consider this Merge Request to fix debbugs builds immediately, and to
> include Salsa-CI to keep the build from regressing again:
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
> 
> 1. If the package was not on git and Salsa, I would have no way to see
> what the maintainers have been doing in the years 2018-2023 (Debian
> repos had last upload in 2018)

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

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


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

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

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

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


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

The UI of my email program is easy and useful.

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

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


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

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

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


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

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

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

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

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

...instead of lumping all those discussions into a discussion of ease of
user interface for a single catch-all code forge that maybe make all those
other complications go away by affecting all those questions and that way
implicitly provides *some* answer to them all.

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

 * mandate VCS-tracking
   * Yes
 * mandate the use of one specific VCS
   * Yes: git
 * mandate one specific 

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

[Otto Kekäläinen]

Hi Bill and Wookey!

In a recent long thread on debian-devel you had somewhat negative
sentiments towards the usefulness of Salsa. I do see you doing good
technical work for Debian and recently a MR from Bill too, so I was
thinking that maybe you will change your mind when you read more
in-depth arguments. This is my attempt to have you think about Salsa
in a new light:

On Tue, 9 Apr 2024 at 11:41, Bill Allombert  wrote:
> Having a repository on salsa or even "packaging team" does not prevent
> a lack of maintainer, so this is not relevant.
> Without a maintainer, no contribution will be merged in any case.

Consider this Merge Request to fix debbugs builds immediately, and to
include Salsa-CI to keep the build from regressing again:
https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19

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

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

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

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


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

Thanks,

Otto

Re: finally end single-person maintainership

[Matthias Urlichs]

On 12.04.24 00:52, Bill Allombert wrote:

These contributions always need to be carefull reviewed before being
accepted. As likely as not, they are either slightly incorrect or
introducing subtle breakages in some case the submitter did not
envision. This is where an expert maintainer is most needed.


Well that's your take.

My take is that when contributions to packaging "always" need a careful 
review, that's not  virtue, that's a symptom of underlying structural 
problems with package management.


We should strive to fix the root cause instead of requiring maintainers 
to be packaging experts. That doesn't scale.


--
-- regards
--
-- Matthias Urlichs



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Andreas Tille]

Am Fri, Apr 12, 2024 at 09:36:25PM +0200 schrieb Bastian Blank:
> > - I also think disallowing single-person maintainership would be very 
> > unwise,
> >   though I agree team maintenance in general is probably better than
> >   single-person maintainership. Still disallowing single-person 
> > maintainership
> >   doesnt make a team and motivation lost is often motivation lost forever.
> 
> What would that even mean?  What is a team anyway?

It means you motivate others to do the work you might not be able to do
by helping them in the first place.

I gave other answers in several talks page[1].

Kind regards
   Andreas.

[1] https://people.debian.org/~tille/talks/

-- 
https://fam-tille.de

Re: finally end single-person maintainership

[gregor herrmann]

On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote:

> Debian is about freedom, so let's apply that to free choice of the tooling
> to be usable.

I disagree. "Freedom" is about Free Software, so-called freedom in
packaging has high costs as people (who look at more than their
"own" favourite packages) need to known and learn a plethora of
packaging helper and styles and modes etc. This causes energy drains
and slows down the whole project. Let's please stop this.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: finally end single-person maintainership

[Luca Boccassi]

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

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

Re: finally end single-person maintainership

[Nilesh Patra]

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

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

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

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

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

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

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

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

Best,
Nilesh


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andreas Tille]

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

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

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

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

Kind regards
Andreas.

-- 
https://fam-tille.de

Re: finally end single-person maintainership

[Patrick Winnertz]

On 12.04.24 19:28, Luca Boccassi wrote:

New contributors won't start in a vacuum, most will start contributing
first to existing projects on Salsa, which are already set up and
configured to do what is needed, if it is needed. 

+1 here


Git is the bare
minimum these days, and has been for years. Salsa is the best thing
that has happened to Debian the past decade, and the Salsa team will
forever have my gratitude for the great job they have done and
continue to do.


Yepp - a very special thanks to the complete Salsa team. After seeing 
the numbers from Ganneff yesterday their work to set this up and keep it 
running is really impressive.


Furthermore I think that not only salsa was the best thing which 
happened to debian, but github/gitlab for open source in general. Just 
have a look how many projects are nowadays hosted on github/gitlab.


Greetings
Patrick (winnie)
--
 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  win...@debian.org/patr...@winnertz.eu
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: 8D208172388840811B85DA1CC6D50A4188C70E43
 ⠈⠳⣄

The people who refer to the pandemic in the past tense and climate 
change in the future tense are the reason everything is going to shit.

Re: finally end single-person maintainership

[Bastian Blank]

On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote:
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
>   where I can.

We still like those VCS-in-VCS workflows over everything else.  Those
debian/patches, where you need to call something special and can't just
re-use upstreams CI tests.  And which conflict outside of git with the
next upstream version.

I just stopped that and use git alone.

> - I also think disallowing single-person maintainership would be very unwise,
>   though I agree team maintenance in general is probably better than
>   single-person maintainership. Still disallowing single-person maintainership
>   doesnt make a team and motivation lost is often motivation lost forever.

What would that even mean?  What is a team anyway?

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!

Re: finally end single-person maintainership

[Luca Boccassi]

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

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

Re: finally end single-person maintainership

[Simon Richter]

Hi,

On 13.04.24 00:19, Marc Haber wrote:


'Require' is probably the wrong word.  I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.



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


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


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


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


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


   Simon


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: finally end single-person maintainership

[Marc Haber]

On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille 
wrote:
>'Require' is probably the wrong word.  I simply have heard from several
>potential young contributors that they feel blocked by the tooling and
>specifically not everything in Git. 

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

>> then pull them,
>> maybe into different branches,
>
>git-buildpackage maintains two or three branches:  The main packaging
>branch and an upstream branch.  The pristine-tar branch is optional (but
>default in the teams I'm working in)

And not (any more?) default in the tools, thus easily forgotten.

Greetings
MArc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: finally end single-person maintainership

[Gioele Barabucci]

On 12/04/24 15:00, Marc Haber wrote:

On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
 wrote:

Also regarding gbp, my packaging workflow does not require it
(debian/-folder-only in Git). Being enforced to use some other pkg'ing
style would reduce my fun and end up with less productivity, I fear.
The gbp workflow has its pros, but for me it is a too complex overhead
without much gain to the end result (the uploaded package).


The debian/-only layout was quite common in the svn days and back then
we had adequate tooling to support that but those tools have rotted
away, it feels unnatural to me, and, frankly, exim's debian/-only
layout (that I introduced myself fifteen^wtwenty years ago) is the
main reason why I am a mostly inactive member on the exim team since I
still don't know any more how to properly build the package.


This is not an endorsement of debian/-only repos, but building 
debian/-only packages using gbp is not hard:


$ git clone https://salsa.debian.org/exim-team/exim4.git
$ cd exim4
$ cat < debian/gbp.conf
[DEFAULT]
export-dir = ../
overlay = True
debian_branch = master
EOF
$ origtargz
$ gbp buildpackage --git-ignore-new --git-no-create-orig

(This is more a praise of gbp rather than a defense of debian/-only repos.)

--
Gioele Barabucci

Re: finally end single-person maintainership

[Marc Haber]

On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci 
wrote:
>Asking maintainers "to use git" means: please push your changes, even 
>those unreleased to a public git repository (salsa, github, codeberg, 
>your own domain...), so other people can contribute 1) knowing that they 
>are working against the same sources the maintainer has on their hard 
>drive, and 2) using git-based workflows.

To have this actually work, I'd like to have published best-practice
things such like "branches with a 'wip-' prefix can have their history
rewritten any time" so that I can use git rebase --autosquash
--interactive to fix my commit errors even on branches that I have
already pushed without feeling bad for doing so.

>dgit is both a Web interface to browse git repositories as wells as a 
>system to access the Debian archive as if it were a git repository, so 
>you can "dgit push" a branch and have the resulting binary uploaded to 
>the archive. (Yes, I'm simplifying here, but that's the gist.)

It is also not well documented for a beginner. I think that the dgit
docs are fine for someone who is already familiar with the tool and
has been using it for some time, but I have tried to read myself into
dgit multiple times and utterly failed with that.

>Salsa is a forge, i.e. a combination of a Web interface, a git server, 
>and a set of integrated features. In comparison to dgit, salsa has, like 
>most forges:
>
>* Merge requests: where people can suggest changes and discuss them with 
>line-based comments (accessible via email, no need to use the Web interface)
>
>* Continuous integration pipelines: as soon as you push a commit, 
>Salsa-CI will try to build a package, cross build it, test it against 
>piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI 
>developers).
>
>* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, 
>but funnily enough not BTS).
>
>* Project specific wikis, snippets, Docker images.
>
>* And with tag2upload salsa fulfills 50% of dgit functionality.

And, a web interface which make the learning curve a lot less steep.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: finally end single-person maintainership

[Marc Haber]

On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
 wrote:
>Also regarding gbp, my packaging workflow does not require it  
>(debian/-folder-only in Git). Being enforced to use some other pkg'ing  
>style would reduce my fun and end up with less productivity, I fear.  
>The gbp workflow has its pros, but for me it is a too complex overhead  
>without much gain to the end result (the uploaded package).

The debian/-only layout was quite common in the svn days and back then
we had adequate tooling to support that but those tools have rotted
away, it feels unnatural to me, and, frankly, exim's debian/-only
layout (that I introduced myself fifteen^wtwenty years ago) is the
main reason why I am a mostly inactive member on the exim team since I
still don't know any more how to properly build the package.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: finally end single-person maintainership

[Marc Haber]

On Tue, 9 Apr 2024 18:37:23 +, Holger Levsen
 wrote:
>- I also think disallowing single-person maintainership would be very unwise,
>  though I agree team maintenance in general is probably better than
>  single-person maintainership.

Agreed.

>  Still disallowing single-person maintainership
>  doesnt make a team and motivation lost is often motivation lost forever.

Agreed. It is too easy for three singel maintainers to form a pro
forma team where everyone works on their packages and not on the
others'. You cannot enforce team work.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: finally end single-person maintainership

[Holger Levsen]

On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote:
> On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
[...]
> I agree with everything you say here!

:)

> Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
> authors and maintainers and it's a very useful tool to bring together
> some complex workflows and in particular successfully move a lot of
> people over from svn-buildpackage.

absolutly.

> I do however agree that there's too much magic. Some of that is
> inherited from the Debian-specific tooling it sits on top of: I also
> think there's too much magic and/or complexity in debuild and
> dpkg-buildpackage.
 
absolutly.

Thanks for these additions!


-- 
cheers,
Holger

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

“I'll tell you what freedom is to me No fear.” (Nina Simone)


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Mike Gabriel]

Hi all, hi Holger,

On  Di 09 Apr 2024 18:37:23 UTC, Holger Levsen wrote:


hi,

just adding some random data points to this thread:

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

  doesnt make a team and motivation lost is often motivation lost forever.


Very well summarized, fully agreeing with the above, esp. the part  
about single-person maintainership (let's simply keep it and, at the  
same time, encourage people to work in teams).


Also regarding gbp, my packaging workflow does not require it  
(debian/-folder-only in Git). Being enforced to use some other pkg'ing  
style would reduce my fun and end up with less productivity, I fear.  
The gbp workflow has its pros, but for me it is a too complex overhead  
without much gain to the end result (the uploaded package).


Debian is about freedom, so let's apply that to free choice of the  
tooling to be usable.


light+love,
Mike

--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de

Re: finally end single-person maintainership

[Jonathan Dowland]

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

I agree with everything you say here!

Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
authors and maintainers and it's a very useful tool to bring together
some complex workflows and in particular successfully move a lot of
people over from svn-buildpackage.

I do however agree that there's too much magic. Some of that is
inherited from the Debian-specific tooling it sits on top of: I also
think there's too much magic and/or complexity in debuild and
dpkg-buildpackage.


-- 
Please do not CC me for listmail.

  Jonathan Dowland
✎j...@debian.org
   https://jmtd.net

Re: finally end single-person maintainership

[Bill Allombert]

Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a 
écrit :
> we need both. Domain specific knowledge is clearly very important and I'm not
> trying to argue against it. But doing packaging in a way such that it becomes
> easy for others to contribute is *also* every important. As the maintainer of 
> a
> package with expert knowledge of it you might think that there is nothing to 
> do
> but you while you are the expert for that package, you might not be the expert
> on topics like cross building, reproducible builds, multiarch, build profiles,
> merged-/usr, build hardening and many other topics which span the whole
> distribution. There are people who are heavily invested in these topics and 
> who
> will want to touch very many packages to fix things. It should be made easy 
> for
> them to make these contributions without them bit-rotting as a patch in the 
> BTS
> for months or years. I'm not saying that *you* let these contributions 
> bit-rot.
> This is meant as a general argument for making it easier to make large-scale
> changes to packages. Diversity in our packaging styles and strong package
> ownership sometimes work contrary to issues affecting very many packages 
> across
> our distro.

These contributions always need to be carefull reviewed before being
accepted. As likely as not, they are either slightly incorrect or
introducing subtle breakages in some case the submitter did not
envision. This is where an expert maintainer is most needed. People
heavily invested in some topic tend to forget the packages has other
users, and often fix the symptom instead of fixing the problem.

When a change leads to a RC bug a month or three after having be
part of a package, fixing the problem falls on the maintainer and not
on the change author. Even correct changes can trigger latent bugs
in software.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: finally end single-person maintainership

[Johannes Schauer Marin Rodrigues]

Quoting Andreas Tille (2024-04-10 22:44:25)
> > I do understand the argument that lots of different workflows adds
> > friction. But I'm just still using what used to be _the_ standard one
> > (insofar as we ever had such a thing). Putting everything in salsa/git
> > doesn't standardise workflows in itself. I think Ian/Sean identified 12
> > different git-based methods in their dgit review.
> 
> I agree that different workflows are not helpful.  We have DEP14[1]
> ... but we have no efficient processes to
>   a) accept DEPs
>   b) dedicate to accepted DEPs

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

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

signature.asc
Description: signature

Re: finally end single-person maintainership

[gregor herrmann]

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

> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to
> > commit everything into git first, so I have to remember to squash all these
> > commits later.
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow. I want to make changes and
> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it after I'm satisfied that it works.

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

% cat ~/.gbp.conf 
…

[buildpackage]
…
export = WC


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

> The point here is that 'requiring salsa' is actually code for 'no,
> you can't just use the tarball-based VCS any more - you have to use
> git'.

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

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

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


Cheers,
gregor


-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: finally end single-person maintainership

[Andreas Tille]

Hi Wookey,

Am Tue, Apr 09, 2024 at 05:52:43PM +0100 schrieb Wookey:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow.

I started packaging with VCS in 2007i.  Thanks to some Debian Med team
members (mainly Charles Plessy) I was convinced to us SVN first and
later I was moved to Git (yes, I *was* moved ;-) ).  I'm extremely happy
that I followed my team mates and could not imagine to move back.

> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it after I'm satisfied that it works. But I
> don't know that until I've made a whole set of changes and it builds.

Seems like a matter of style.  My team mates are accepting commits that
are not perfect and fixed later in another commit.  The great thing is
that I get some proof whether my commits are working after pushing to
Salsa thanks to Salsa CI.
 
> So now I've got a pile of changes which should really be separate
> commits and logically separate things often affect the same files, and
> even the same lines, so really I need to commit some chunks and not
> others and tidy it all up. Yes this makes a nice set of commits but
> it's _so_ much work in comparison to just editing the damn files, and
> then effectively doing one fat 'commit' when I dupload.

I do not think everybody expects you to follow the gold standard if Git
commits.  If it makes you more productive nobody will blame you about
some fat commits.

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

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

'Require' is probably the wrong word.  I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.  We simply have no idea what amount
of new contributors we might scare away due to sticking to habits that
feel old fashioned to those people.
 
> The point here is that 'requiring salsa' is actually code for 'no,
> you can't just use the tarball-based VCS any more - you have to use
> git'.  Removing that interface is a very big deal - it has served
> quite well for 30 years. Yes it old-fashioned and crufty and
> (presumably) only a minority still use it as the primary interface,
> but any GR on this should acknowledge what we are requiring of people
> still using it, not just frame this as 'and add salsa'. It's more
> fundamental than that (or I am misunderstanding)..

I'm using a workflow based on git-buildpackage with pristine-tar.  This
is a great wrapper for the tarball-based workflow.

> Also what do you git people do to replace uscan?

Nothing.  I'm using uscan.  When I realised that I'm doing always the
same for new upstream versions I wrote some semi-automated tool
routine-update which calls uscan, cme, janitor tools and is possibly the
reason why I was able to maintain the majority of packages of R pkg team
alone.  Sometimes I have 4-6 xterms open with running routine-update at
the same time.  Doing things semi-automated is dangerous to some extend
- thus I consider Salsa CI a great second pair of eye-balls.  Without
this toolset I could not manage all this.

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

I usually keep copies of most of my packaging git repositories on my
local disk.  So my workflow is checking some list of packages that need
an upgrade (we update such lists in some teams twice a day).  Than I move
to the local repository, run

   routine-update
 (works without interaction in about >80%, depending from the team)
   dput

> git world seems to make this way more complicated. I have to set up
> two different repos - one for salsa one for upstream,

No.  There are tag based workflows (as far as I know in openstack team)
which I personally do not understand.  I'm exclusively using tarball
based workflow.  When creating a new package starting with importing an
upstream tarball as first commit in a fresh repository (as I've shown in
several live packaging workshops for instance at DebConf23). I create a
local repository 

Re: finally end single-person maintainership

[gregor herrmann]

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


signature.asc
Description: Digital Signature

Re: finally end single-person maintainership

[Scott Kitterman]

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

Specifically to your last point, absolutely.  Saying everyone must do a certain 
thing has an inverse that is we would rather you not contribute at all than do 
it without that thing.  I would rather we make that list as short as possible.

I have all my packages in git on salsa.  Mostly I find it not that helpful to 
me, but I know others value it, so I do it (and for the occasional benefits it 
provides me).  I think I would feel pretty strongly about not continuing to do 
so if someone told me I had to.

Scott K

Re: finally end single-person maintainership

[Gioele Barabucci]

On 09/04/24 18:52, Wookey wrote:

So why mandate salsa rather than make dgit more official?


Independently from whether salsa should be mandated, "git", "salsa" and 
"dgit" are three different things and should not be used as replacement 
of one another.


Asking maintainers "to use git" means: please push your changes, even 
those unreleased to a public git repository (salsa, github, codeberg, 
your own domain...), so other people can contribute 1) knowing that they 
are working against the same sources the maintainer has on their hard 
drive, and 2) using git-based workflows.


dgit is both a Web interface to browse git repositories as wells as a 
system to access the Debian archive as if it were a git repository, so 
you can "dgit push" a branch and have the resulting binary uploaded to 
the archive. (Yes, I'm simplifying here, but that's the gist.)


Salsa is a forge, i.e. a combination of a Web interface, a git server, 
and a set of integrated features. In comparison to dgit, salsa has, like 
most forges:


* Merge requests: where people can suggest changes and discuss them with 
line-based comments (accessible via email, no need to use the Web interface)


* Continuous integration pipelines: as soon as you push a commit, 
Salsa-CI will try to build a package, cross build it, test it against 
piuparts, lintian a bunch of other QA tools (kudos to the Salsa-CI 
developers).


* Integrations with two dozen tools (irc, jenkins, mattermost, bugzilla, 
but funnily enough not BTS).


* Project specific wikis, snippets, Docker images.

* And with tag2upload salsa fulfills 50% of dgit functionality.

Regards,

--
Gioele Barabucci

Re: finally end single-person maintainership

[Bill Allombert]

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

Having a repository on salsa or even "packaging team" does not prevent
a lack of maintainer, so this is not relevant.
Without a maintainer, no contribution will be merged in any case.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: finally end single-person maintainership

[Holger Levsen]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Jose-Luis Rivas]

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 

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Andrey Rakhmatullin]

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


signature.asc
Description: PGP signature

Re: finally end single-person maintainership

[Johannes Schauer Marin Rodrigues]

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,

Re: finally end single-person maintainership

[Wookey]

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 

Re: finally end single-person maintainership

[Andreas Tille]

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

Re: finally end single-person maintainership

[Luca Boccassi]

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

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

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

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

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

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