Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi!

On 06.01.20 19:56, Alexander Wirt wrote:
> On Mon, 06 Jan 2020, Ulrike Uhlig wrote:
>>> On 28.12.19 18:16, Alexander Wirt wrote:
>> >From your replies to emails in this thread I was wondering: do you mean
>> that the Salsa team does not need, or does not want, help? Or does not
>> need, or want, help outside of a sprint?
> That basically means: yes we probably need help. But it also means that
> getting help should be done in a coordinated way, like introducing one or two
> team members during a sprint. Getting someone new involved always means
> overhead and should happen when there is time for such overhead. In my
> experience sprints are ideal for it. I also talked to some people about
> getting them involved in salsa, but there will also be a call for help. 
> 
> I / we plan to add at least one global admin and maybe one or two assistants
> that help with "user" support. 
> 
> We just need some time to plan and coordinate those things (around christmas
> is really a bad timing for such discussions)

Sounds like a good plan! :)

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Ulrike Uhlig wrote:

> Hi formorer,
> 
> > On 28.12.19 18:16, Alexander Wirt wrote:
> >> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> >> I am sure there are many ways to help the team and it is not just
> >> about Salsa/Gitlab admin stuff, but also about creating structure in
> >> the team, triaging issues, spreading best practices for users and
> >> helping the most advanced users to grow into admins of Salsa etc.
> >> Right now we don't even have any kind of salsa-related discussion
> >> list on lists.debian.org. Thus I wanted to raise discussion on
> >> debian-devel. In my opinion Salsa is becoming a very central piece of
> >> the Debian infrastructure and it should have more attention on
> >> debian-devel and from the project leader.
> 
> > We are working on it and after my holidays are over I will plan
> > another sprint for improving salsa.
> 
> >From your replies to emails in this thread I was wondering: do you mean
> that the Salsa team does not need, or does not want, help? Or does not
> need, or want, help outside of a sprint?
That basically means: yes we probably need help. But it also means that
getting help should be done in a coordinated way, like introducing one or two
team members during a sprint. Getting someone new involved always means
overhead and should happen when there is time for such overhead. In my
experience sprints are ideal for it. I also talked to some people about
getting them involved in salsa, but there will also be a call for help. 

I / we plan to add at least one global admin and maybe one or two assistants
that help with "user" support. 

We just need some time to plan and coordinate those things (around christmas
is really a bad timing for such discussions)

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Ulrike Uhlig]

Hi formorer,

> On 28.12.19 18:16, Alexander Wirt wrote:
>> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
>> I am sure there are many ways to help the team and it is not just
>> about Salsa/Gitlab admin stuff, but also about creating structure in
>> the team, triaging issues, spreading best practices for users and
>> helping the most advanced users to grow into admins of Salsa etc.
>> Right now we don't even have any kind of salsa-related discussion
>> list on lists.debian.org. Thus I wanted to raise discussion on
>> debian-devel. In my opinion Salsa is becoming a very central piece of
>> the Debian infrastructure and it should have more attention on
>> debian-devel and from the project leader.

> We are working on it and after my holidays are over I will plan
> another sprint for improving salsa.

>From your replies to emails in this thread I was wondering: do you mean
that the Salsa team does not need, or does not want, help? Or does not
need, or want, help outside of a sprint?

 -- ulrike

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 06 Jan 2020, Sam Hartman wrote:

> > "Alexander" == Alexander Wirt  writes:
> 
> Alexander> For everything else: we are working on it. 
> 
> I just want to confirm that part of the things that you are working on
> is documenting the issues.  At a number of points you've talked about
> how people are misunderstanding the issues or are thinking it's simply
> more CPU etc.
> 
> That's all doubtless true.
> But part of being in a community is communicating with that community.
> People would almost certainly be more understanding if they had more
> information.
just for the record, I am doing all of this in my spare time and I prefer to
decide on my own what is in my queue and what the priority is. And yes, I do
prefer to fix things instead of documenting what needs to get fixed. 

And if everyone would behave sane instead of st* flame wars, insulting each
other and so on (it was a listmaster month to forget) my motivation to work
with that specific community would be a lot better. 

And for everyones sake: when announcing CI support we told everyone that the
ressources are limited and everyone should play nice with the CI. 

As often, other people decided to make the CI and the runners a quasi
standard, adding it to their workflows and so on. Now everyone is surprised
if things are as we always told everybody. What a surprise. 

Thanks for listening. 

Alex



signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Sam Hartman]

> "Alexander" == Alexander Wirt  writes:

Alexander> For everything else: we are working on it. 

I just want to confirm that part of the things that you are working on
is documenting the issues.  At a number of points you've talked about
how people are misunderstanding the issues or are thinking it's simply
more CPU etc.

That's all doubtless true.
But part of being in a community is communicating with that community.
People would almost certainly be more understanding if they had more
information.

Yes, that sort of communication does involve time, and yes that time
could be spent fixing things.
There comes a point though where the communication becomes at least as
important as the fix.

I think I've heard several requests for more information here, and I
just want to confirm that too is in your queue.


--Sam

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Wed, 01 Jan 2020, Otto Kekäläinen wrote:

> Hello!
> 
> ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> > On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > > Also, if resources are an issue: I've offered several times to see if I
> > > can get some k8s resources for gitlab runners, but never got a reply.
> > > Not even a no.
> > It is not a problem on the runner side.
> >
> > And as said, we are working on the other problems until we can improve
> > something in that part.
> 
> If it is not a problem on the runner side and you don't need more
> runner resources, what is the reason the runner is capped at 1h?
> MariaDB is a huge beast and building it and running all tests take
> 1,5h for completely valid reasons (also note we have ccache on
> Salsa-CI so re-builds are much faster).
We updated the timeout to three hours. However, if that leads to problems on
salsa side we will have to set it back. So please ensure not to create too
much load / jobs that use that extended limit. 

For everything else: we are working on it. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

ti 31. jouluk. 2019 klo 14.55 Alexander Wirt (formo...@debian.org) kirjoitti:
> On Mon, 30 Dec 2019, Bernd Zeimetz wrote:
> > Also, if resources are an issue: I've offered several times to see if I
> > can get some k8s resources for gitlab runners, but never got a reply.
> > Not even a no.
> It is not a problem on the runner side.
>
> And as said, we are working on the other problems until we can improve
> something in that part.

If it is not a problem on the runner side and you don't need more
runner resources, what is the reason the runner is capped at 1h?
MariaDB is a huge beast and building it and running all tests take
1,5h for completely valid reasons (also note we have ccache on
Salsa-CI so re-builds are much faster).

Could you be kind at set back the default runner time limit to 2h as
it was some weeks ago?
This is stopping me and our contributors from working on putting
mariadb-10.4 in Debian.

It you don't intend to revert the change back to how it was?

Or could you please at least state the reasons at
https://salsa.debian.org/salsa/support/issues/184 ? So far you have
not commented anything in your own bug tracker at salsa/support..

Thanks again for everybody maintaining and developing Salsa, the CI
and all that comes with them. That has been a huge boost in my
motivation to continue Debian work and makes me much more productive
than ever before.


- Otto

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Bernd Zeimetz wrote:

> 
> 
> On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> > I don't think that salsa-ci is particularly problematic in terms of
> > "efficiency". With the exception of the LXC usage, there's not much
> > that can be "cut" to save resources.
> 
> Also, if resources are an issue: I've offered several times to see if I
> can get some k8s resources for gitlab runners, but never got a reply.
> Not even a no.
It is not a problem on the runner side. 
 
And as said, we are working on the other problems until we can improve
something in that part. 

Alex

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Bernd Zeimetz]

On 12/30/19 11:29 AM, Raphael Hertzog wrote:
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.

Also, if resources are an issue: I've offered several times to see if I
can get some k8s resources for gitlab runners, but never got a reply.
Not even a no.


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

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Mon, 30 Dec 2019, Raphael Hertzog wrote:

> On Sat, 28 Dec 2019, Alexander Wirt wrote:
> > On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> > 
> > > Hello!
> > > 
> > > I've seen many times before statements like these so I'd like to raise
> > > some discussion around the topic:
> > > 
> > > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > > The Salsa CA pipeline is recommended.
> > > >
> > > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > > have to work through too much problems first.
> > The salsa ci pipeline itself has some problematic implementation details
> > waldi lined out in the past. Afaik nothing changed, we had several reports
> 
> This is not really true:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi
> 
> Out of 12 issues reported by waldi, 8 have been fixed/closed.
> 
> Among the remaining ones:
> 
> - https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
>   (usage of LXC for autopkgtest)
>   is likely the most problematic one even though you never explained
>   what's the real issue... yeah it's virtualization over virtualization
>   and it downloads a root tarball to do its work, but is this worth than
>   downloading a docker image? It uses more resources than direct execution
>   of autopkgtest but it hasn't broken anything so far?
that second level of virtualisation caused problems where people told us they
are not able to do things in their ci jobs. 

*snip*

> > where people telling us things are not possible on our runners. In the end
> > most of them turned out to be limitations of salsa ci. Salsa ci is also
> > not very efficent, therefore the veto. 
> 
> Claims like "salsa ci is not very efficient" are not actionable. Bugs like
> those above are more useful but you should at least take the time to
> respond to queries of people, otherwise no progress can be made.
> 
> I don't think that salsa-ci is particularly problematic in terms of
> "efficiency". With the exception of the LXC usage, there's not much
> that can be "cut" to save resources.
Thats probably true, but if it is inefficent and may cause problems on our
current architecture / ressources - that can't get fixed easily - a veto is
the only thing we have. 

> > We are working on it and after my holidays are over I will plan another
> > sprint for improving salsa. 
> 
> \o/

Alex - forgive the shortness, I am on vacation


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Sat, 28 Dec 2019, Alexander Wirt wrote:
> On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> 
> > Hello!
> > 
> > I've seen many times before statements like these so I'd like to raise
> > some discussion around the topic:
> > 
> > pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > > The Salsa CA pipeline is recommended.
> > >
> > > For this I need to use my veto as Salsa admin.  With the CI people we
> > > have to work through too much problems first.
> The salsa ci pipeline itself has some problematic implementation details
> waldi lined out in the past. Afaik nothing changed, we had several reports

This is not really true:
https://salsa.debian.org/salsa-ci-team/pipeline/issues?scope=all=%E2%9C%93=opened_username=waldi

Out of 12 issues reported by waldi, 8 have been fixed/closed.

Among the remaining ones:

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
  (usage of LXC for autopkgtest)
  is likely the most problematic one even though you never explained
  what's the real issue... yeah it's virtualization over virtualization
  and it downloads a root tarball to do its work, but is this worth than
  downloading a docker image? It uses more resources than direct execution
  of autopkgtest but it hasn't broken anything so far?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/94
  (docker images accumulating in forks)
  this one should have improved a lot AFAIK as GitLab now supports what's
  required to remove images from the CI environment too and there's
  WIP on that front (it might even be live without anyone updating that
  bug, I'm not sure)

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/116
  This one is not clear to me. What jobs are using "docker-in-docker"
  without any legitimate use ?

- https://salsa.debian.org/salsa-ci-team/pipeline/issues/121
  (split into source and build)
  This one seems like wishlist and has no real impact on resources as long
  as we build for a single architecture...

> where people telling us things are not possible on our runners. In the end
> most of them turned out to be limitations of salsa ci. Salsa ci is also
> not very efficent, therefore the veto. 

Claims like "salsa ci is not very efficient" are not actionable. Bugs like
those above are more useful but you should at least take the time to
respond to queries of people, otherwise no progress can be made.

I don't think that salsa-ci is particularly problematic in terms of
"efficiency". With the exception of the LXC usage, there's not much
that can be "cut" to save resources.

> We are working on it and after my holidays are over I will plan another
> sprint for improving salsa. 

\o/

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Alexander Wirt]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:

> Hello!
> 
> I've seen many times before statements like these so I'd like to raise
> some discussion around the topic:
> 
> pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> > On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > > The Salsa CA pipeline is recommended.
> >
> > For this I need to use my veto as Salsa admin.  With the CI people we
> > have to work through too much problems first.
The salsa ci pipeline itself has some problematic implementation details
waldi lined out in the past. Afaik nothing changed, we had several reports
where people telling us things are not possible on our runners. In the end
most of them turned out to be limitations of salsa ci. Salsa ci is also
not very efficent, therefore the veto. 

> There seems to be a conflict between the Salsa admins and users of
> Salsa: the more Salsa is used, the bigger becomes the maintenance
> burden and the more computing resources Salsa needs. There is however
> no inherent growth feedback loop in the system that would increase
> maintenance commitments as usage commitments grow. In economic terms
> one could say that the Salsa admins don't profit from maintaining
> Salsa and as demand grows there is nothing that grows the supply at
> the moment.
> 
> The reason for Salsa popularity to grow all the time is simply because
> it is such a brilliant service and many Debian Developers and aspiring
> new contributors love to use it. Personally I've had all my packages
> on Salsa since early 2018 and I would never want to go back to the mix
> of Github and Alioth I used before. Using Gitlab-CI is nowadays an
> inherent part of my packaging workflow to test contributions before
> merging them and to do QA before uploads. Any disruptions to Salsa
> basically grinds by packaging work to a halt[1], it is so central for
> me nowadays.
> 
> Since Salsa was officially launched in 2018 there has not been any [2]
> new members to the Salsa admins group [3]. Alexander, Joerg and
> Bastian have done a great job maintaining our Gitlab installation. The
> software suite is a beast and keeping it running well is a major
> effort in itself.
> 
> They need help going forward. The sentiment of restricting vital use
> of Salsa is a sign of them trying to keep things under control. But
> Salsa usage needs to grow, as that is good for Debian as a project.
> For the Debian project I think it would be a priority to find more
> resources to the Salsa admin team. I think that would be the ultimate
> solution to the current conflict.
For more performane salsa would need a proper redesign by moving it from its
monolithic system to a more distributed system. In fact we are already
talking about it for some time. But in fact you - the users - should not
think that everything is as easy as just adding some cpus, disks or workers.
Things are often more complicated and - in the end - everything should be
maintainable by DSA too. 

> Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
> is out of computing resources I can however help find more sponsors
> for public runners. But I have the understanding that Google has
> donated plenty of cloud computing time and the root cause is not in
> lack of computing resources, but in the human scalability aspects of
> Salsa operations.
in fact thats only partially true. 

We are working on it and after my holidays are over I will plan another
sprint for improving salsa. 

Things are not always as easy as it seems.

Alex


signature.asc
Description: PGP signature

Re: Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Raphael Hertzog]

On Thu, 26 Dec 2019, Otto Kekäläinen wrote:
> I am sure there are many ways to help the team and it is not just
> about Salsa/Gitlab admin stuff, but also about creating structure in
> the team, triaging issues, spreading best practices for users and
> helping the most advanced users to grow into admins of Salsa etc.
> Right now we don't even have any kind of salsa-related discussion list
> on lists.debian.org. Thus I wanted to raise discussion on
> debian-devel. In my opinion Salsa is becoming a very central piece of
> the Debian infrastructure and it should have more attention on
> debian-devel and from the project leader.

+1 on everything you said. (And IMO you should have started a new thread
instead of replying to an old one)

I do hope we can find some constructive way to go forward because the current
settings are now too strict and are effectively hindering big packages
(exactly those that need help!) and some other advanced use of the
service.

I would also like to mention that we should have #salsa or #debian-salsa and
drop #alioth on IRC, sure it made sense at the start to continue to use
the same place as where we used to be but now it just makes it harder
to find the correct place to discuss issues with Salsa.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Help needed: conflicting interests between Salsa admins and Salsa users (Re: Git Packaging Round 2: When to Salsa)

[Otto Kekäläinen]

Hello!

I've seen many times before statements like these so I'd like to raise
some discussion around the topic:

pe 13. syysk. 2019 klo 16.36 Bastian Blank (wa...@debian.org) kirjoitti:
> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > The Salsa CA pipeline is recommended.
>
> For this I need to use my veto as Salsa admin.  With the CI people we
> have to work through too much problems first.

There seems to be a conflict between the Salsa admins and users of
Salsa: the more Salsa is used, the bigger becomes the maintenance
burden and the more computing resources Salsa needs. There is however
no inherent growth feedback loop in the system that would increase
maintenance commitments as usage commitments grow. In economic terms
one could say that the Salsa admins don't profit from maintaining
Salsa and as demand grows there is nothing that grows the supply at
the moment.

The reason for Salsa popularity to grow all the time is simply because
it is such a brilliant service and many Debian Developers and aspiring
new contributors love to use it. Personally I've had all my packages
on Salsa since early 2018 and I would never want to go back to the mix
of Github and Alioth I used before. Using Gitlab-CI is nowadays an
inherent part of my packaging workflow to test contributions before
merging them and to do QA before uploads. Any disruptions to Salsa
basically grinds by packaging work to a halt[1], it is so central for
me nowadays.

Since Salsa was officially launched in 2018 there has not been any [2]
new members to the Salsa admins group [3]. Alexander, Joerg and
Bastian have done a great job maintaining our Gitlab installation. The
software suite is a beast and keeping it running well is a major
effort in itself.

They need help going forward. The sentiment of restricting vital use
of Salsa is a sign of them trying to keep things under control. But
Salsa usage needs to grow, as that is good for Debian as a project.
For the Debian project I think it would be a priority to find more
resources to the Salsa admin team. I think that would be the ultimate
solution to the current conflict.

Personally I cannot commit to maintain Salsa, unfortunately. If Salsa
is out of computing resources I can however help find more sponsors
for public runners. But I have the understanding that Google has
donated plenty of cloud computing time and the root cause is not in
lack of computing resources, but in the human scalability aspects of
Salsa operations.

I hope somebody else on the debian-devel list would respond to this
call for help.

I am sure there are many ways to help the team and it is not just
about Salsa/Gitlab admin stuff, but also about creating structure in
the team, triaging issues, spreading best practices for users and
helping the most advanced users to grow into admins of Salsa etc.
Right now we don't even have any kind of salsa-related discussion list
on lists.debian.org. Thus I wanted to raise discussion on
debian-devel. In my opinion Salsa is becoming a very central piece of
the Debian infrastructure and it should have more attention on
debian-devel and from the project leader.

Thanks again for current Salsa admins for the work you've done! Salsa
is amazing and I hope it will get broader attention and help so it
scales to support our packaging work far into the future.

[1] https://salsa.debian.org/salsa/support/issues/184
[2] https://wiki.debian.org/Salsa?action=diff=37=17
[3] https://wiki.debian.org/Salsa#Maintenance

Re: Git Packaging Round 2: When to Salsa

[Guillem Jover]

Hi!

On Wed, 2019-11-06 at 12:43:58 +, Simon McVittie wrote:
> On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> > It does, it's specifically mentioned as a branch that will be
> > rewinded. See the “Branch management for next and pu after a feature
> > release” section.
> 
> gitworkflows(7) describes how git.git works, as an example of the workflow
> of a particular project, rather than mandating particular workflows for
> all projects:
> 
> This document attempts to write down and motivate some of the workflow
> elements used for git.git itself. Many ideas apply in general
>
> In git.git, next and pu are branches themselves, not prefixes for families
> of branches. This means that branches called next/foo and pu/bar cannot
> exist in git.git. The workflows and naming used to develop git, dpkg and
> (for example) GNOME are all entirely valid, but they aren't the same.

Hmm, I find this reply slightly confusing TBH. :) It's clear that git
upstream cannot mandate how other projects operate their branches (as
long as they would not do that via code). But the point here was
whether there is precedent on branch nomenclature that people might
easily understand or be aware of to have the desired rebasing+force-push
semantics. And I provided a prominent example of this, which granted,
does not use the same exact naming format, but uses the same concepts
(nomenclature and semantics). To recap we have at least:

  * git.git: workflows(7)
  * Pro Git book:
https://git-scm.com/book/en/v2/Distributed-Git-Maintaining-a-Project
  * linux-next.
  * dpkg: https://wiki.debian.org/Teams/Dpkg/GitUsage

I didn't include dpkg, because I assume its git usage does not really
have much of an impact. But the git man page or the git book would be
two things I assume do have quite some exposure.

I note that GNOME seems to be using “wip“ (which was one of the
other proposals on this thread), which looks clearish to me too.


Perhaps your point was that the “pu” and “next” names are not really
commonly understood depending on the communities or context, and might
be considered confusing or non-obvious? I'm clearly biased here, as
I've been using those terms for a long time, so I cannot really tell.
But having at least some prominent references, I think counts in favor.

Thanks,
Guillem

Re: Git Packaging Round 2: When to Salsa

[Simon McVittie]

On Tue, 05 Nov 2019 at 02:41:29 +0100, Guillem Jover wrote:
> It does, it's specifically mentioned as a branch that will be
> rewinded. See the “Branch management for next and pu after a feature
> release” section.

gitworkflows(7) describes how git.git works, as an example of the workflow
of a particular project, rather than mandating particular workflows for
all projects:

This document attempts to write down and motivate some of the workflow
elements used for git.git itself. Many ideas apply in general

In git.git, next and pu are branches themselves, not prefixes for families
of branches. This means that branches called next/foo and pu/bar cannot
exist in git.git. The workflows and naming used to develop git, dpkg and
(for example) GNOME are all entirely valid, but they aren't the same.

(git's workflow also uses a single maint branch for updates to the latest
stable version, which is fine if you only ever support one stable version
at a time - presumably that's the case for git? - but doesn't work as-is
if you want to support two stable branches at the same time, like Debian
buster and stretch at the moment.)

gitworkflows(7) also mentions branches of the form ai/*. I'm not sure
what "ai" means. From context, these seem to be topic branches used to
integrate new features into next, and seem to be non-rebasing but it
isn't entirely clear to me?

smcv

Re: Git Packaging Round 2: When to Salsa

[Guillem Jover]

On Sun, 2019-09-15 at 12:23:48 +0200, Marc Haber wrote:
> On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover wrote:
> > I think the common prefixes for these are pu/ and next/? These are
> > also documented somehow in the gitworkflows(7) man page.
> 
> The definition of those prefixes doesn't contain language like "might
> be rebased and force-pushed any time".

It does, it's specifically mentioned as a branch that will be
rewinded. See the “Branch management for next and pu after a feature
release” section.

That's how I've seen all pu/ and next/ branches being used, and how
I've always used them myself.

Thanks,
Guillem

Re: Git Packaging Round 2: When to Salsa

[Jonas Meurer]

Matt Zagrabelny:
> On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz  wrote:
> 
>>
>>> There are a number of ways forward:
>>>
>>> [...]
>>> 5) Make no recommendations in this space
>>
>> Why do all things need a recommendation? List the possible places to
>> host a repository with their advantages/disadvantages. If somebody is
>> not able to decide where to put a package based on that, they might not
>> be able to maintain it anyway.
>>
> 
> Having sensible recommendations reduces the barrier to entry. Even if you
> provide a list with all the pros/cons there is still a decision to be made.
> Every decision that needs to be made is a barrier. Reading and
> understanding, research and applying context, contemplating and making
> decisions.

As someone who several times introduced newcomers to the world of Debian
packaging, I wholehearted agree. There's tons of tools to understand and
decisions to make if you're new to the Debian ecosystem. Having some
clear recommendations definitely helps a lot here and significantly
lowers the entry barrier. Again, thanks to Sam for driving forward the
discussion towards clear recommendations/defaults here!

On the other hand, calling newcomers as incompetent just because they
struggle with reading through the pros and cons of every single tool
decision doesn't help at all. Quite contrary, it aggravates a
non-welcoming athmosphere.

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Re: Git Packaging Round 2: When to Salsa

[Alexander Wirt]

On Sun, 15 Sep 2019, Jonas Meurer wrote:

> Sam Hartman:
> >> "Bastian" == Bastian Blank  writes:
> > 
> > Bastian> Hi Sam
> > Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> > >> The Salsa CA pipeline is recommended.
> > 
> > Bastian> For this I need to use my veto as Salsa admin.  With the CI
> > Bastian> people we have to work through too much problems first.
> > 
> > [...]
> > I'll remove it from the next version.
> 
> Please don't. It would be a shame if we would *not* recommend to use the
> awesome Salsa CI pipeline for automated continuous testing of package
> development. I applaud the Salsa-CI's team for their effort, it's a huge
> step forwart for Debians QA standards.
> 
> I also honestly appreciate all the hard work that the Salsa admins put
> into running Salsa, but it's absolutely not acceptable how they try to
> missuse the power of their role by behaving as Salsa dictators.
They? Since noone Cced me, I wasn't even aware of this discussion. 

So please don't they unless it is something offical from the team (such
things will not hidden in a long thread).

Alex



signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

On Sat, Sep 14, 2019 at 07:44:44PM +0200, Inaki Malerba wrote:
> On 13/9/19 15:20, Bastian Blank wrote:
> > For this I need to use my veto as Salsa admin.  With the CI people we
> > have to work through too much problems first.
> If there are _too much problems_ I think you should, at least,
> communicate with us.

I opened several issues now.  Most of them are about reduction of
resource usage.

In combination with the changes I did to Salsa, those should be at least
a step in the right direction.  I haven't looked deep enough for a
complete overview.

> Forbidding something you don't like without further explanation doesn't
> seem to be the best way to go (applies to all Salsa matters).

If you do stuff ten or hundred times, we don't care.  If you do it a
thousand or more times, we start to care.

We told people a lot of times to think before doing and be light with
the available resources.

> > On 13/9/19 18:00, Sam Hartman wrote:
> > Are there additional resources either the salsa admins or the salsa CI
> > team needs to move forward to a place where you'd both feel comfortable
> > recommending Salsa CI?
> It would be great to find a way to discuss things between Salsa admins
> and users. It's been one way only so far.

The communication is more no-way.

You once just added callouts to an external service of your choice to
all jobs you controlled, leaked information about private repositories,
without telling users, and managed to ignore errors while asking the
API using the leaked data.

Regards,
Bastian

-- 
Genius doesn't work on an assembly line basis.  You can't simply say,
"Today I will be brilliant."
-- Kirk, "The Ultimate Computer", stardate 4731.3

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

Matt Zagrabelny writes:
> On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz  wrote:
>> Why do all things need a recommendation? List the possible places to
>> host a repository with their advantages/disadvantages. If somebody is
>> not able to decide where to put a package based on that, they might not
>> be able to maintain it anyway.
>>
>
> Having sensible recommendations reduces the barrier to entry. Even if you
> provide a list with all the pros/cons there is still a decision to be made.
> Every decision that needs to be made is a barrier. Reading and
> understanding, research and applying context, contemplating and making
> decisions.

Then the best recommendation is probably "find a team to maintain the
package in" and, if that really doesn't work for some reason, "try to
find a team maintaining similar packages (language, domain) and consider
following whatever they do" to make it easier to interact with these
people when asking for advice or so.

Ansgar

Re: Git Packaging Round 2: When to Salsa

[Matt Zagrabelny]

On Wed, Sep 25, 2019 at 4:09 PM Bernd Zeimetz  wrote:

>
> > There are a number of ways forward:
> >
> >[...]
> > 5) Make no recommendations in this space
>
> Why do all things need a recommendation? List the possible places to
> host a repository with their advantages/disadvantages. If somebody is
> not able to decide where to put a package based on that, they might not
> be able to maintain it anyway.
>

Having sensible recommendations reduces the barrier to entry. Even if you
provide a list with all the pros/cons there is still a decision to be made.
Every decision that needs to be made is a barrier. Reading and
understanding, research and applying context, contemplating and making
decisions.

I'm not suggesting that maintainers don't (eventually) understand all of
the relevant details and particulars. Sometimes not forcing them to drink
from the fire hose right away could be considered polite.

-m

Re: Git Packaging Round 2: When to Salsa

[Bernd Zeimetz]

On 9/10/19 3:26 AM, Sam Hartman wrote:
> I tried to cover the disadvantages of this in the original mail:
> 
> * Works poorly when maintainership changes

Why? Its git. Press the fork button, select a destination, update
debian/control, be happy.

> * Works poorly when account status changes

Why? Do we delete repositories?


> There are a number of ways forward:
> 
>[...]
> 5) Make no recommendations in this space

Why do all things need a recommendation? List the possible places to
host a repository with their advantages/disadvantages. If somebody is
not able to decide where to put a package based on that, they might not
be able to maintain it anyway.


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

Automatic update of Vcs-Git info (was Re: Git Packaging Round 2: When to Salsa)

[Dominique Dumont]

On Friday, 13 September 2019 15:00:11 CEST gregor herrmann wrote:
> That's obviously an artifact of our poor Vcs-* information handling
> (in source packages); in reality, of course all of the 3600+
> perl-team packages are maintained on salsa.

For what it's worth, Vcs-Git info can be updated automatically with 'cme run 
set-vcs-git`. This command shoud be run in each repo. It won't change files if 
VCS-Git is already up-to-date.

Here's the output of 'cme run set-vcs-git --doc'

$ cme run set-vcs-git --doc
update control Vcs-Browser and Vcs-git from git remote value
parameters: remote (default is origin)

example:
cme run set-vcs-git
cme run set-vcs-git -arg remote=debian
will commit with message: 'control: update Vcs-Browser and Vcs-Git'

Hope this helps

Dod

Re: Git Packaging Round 2: When to Salsa

[Bernd Zeimetz]

On 9/15/19 9:57 AM, Bastian Blank wrote:
> [...]
> But basically the Salsa CI stuff needs to reduce the resource usage in
> various stages as Salsa simply lacks them.

I really hope that adding more resources is not the problem here, Debian
has some funds and also I'd expect people to offer k8s logins for CI
runners if being asked for.


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

Re: Git Packaging Round 2: When to Salsa

[Jonas Meurer]

Sam Hartman:
>> "Bastian" == Bastian Blank  writes:
> 
> Bastian> Hi Sam
> Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> >> The Salsa CA pipeline is recommended.
> 
> Bastian> For this I need to use my veto as Salsa admin.  With the CI
> Bastian> people we have to work through too much problems first.
> 
> [...]
> I'll remove it from the next version.

Please don't. It would be a shame if we would *not* recommend to use the
awesome Salsa CI pipeline for automated continuous testing of package
development. I applaud the Salsa-CI's team for their effort, it's a huge
step forwart for Debians QA standards.

I also honestly appreciate all the hard work that the Salsa admins put
into running Salsa, but it's absolutely not acceptable how they try to
missuse the power of their role by behaving as Salsa dictators.

Cheers
 jonas



signature.asc
Description: OpenPGP digital signature

Re: Git Packaging Round 2: When to Salsa

[Balasankar "Balu" C]

Hi,

On 15/9/19 1:27 PM, Bastian Blank wrote:

>> Are there additional resources either the salsa admins or the salsa CI
>> team needs to move forward to a place where you'd both feel comfortable
>> recommending Salsa CI?
> 
> We need to sit down and disuss between the admins first what we exactly
> require and where we want to go in the future, which is some sort of a
> problem right now.
> 
> But basically the Salsa CI stuff needs to reduce the resource usage in
> various stages as Salsa simply lacks them.
> 
> Salsa is also in a weird state.  It's both a large and a small GitLab
> installation.  This is source of a lot of those problems.

[With both my GitLab employee hat and Debian Developer hat on]
Let me know if I can help in any way. :)

> 
> It is large.  Salsa is one of the largest public accessible GitLab
> instances.  The only other I know, git.drupalcode.com, which contains
> more projects, is technically a GitLab, but is only used as git web
> interface.

There's also GitLab.com, but I understand what you meant. :)

Regards
Balu

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Sean" == Sean Whitton  writes:

>>> 
>>> I would already assume any branch prefixed with 'wip' might be
>>> rebased myself, but others might be surprised.
>> 
>> I would like to have this documented somewhere so that people
>> dont get surprised. I am not particularly fond of the wip-prefix
>> though and would appreciate better suggestions.

Sean> Maybe just go ahead and add it to the salsa wiki page, if
Sean> no-one objects in this subthread for a few days?

Sean> rebasing/ wip/ tmp/ work/

That makes sense to me.  It sounds like documenting this has a path
forward and so I'm not tracking it further.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Marc Haber]

On Sun, 15 Sep 2019 00:04:14 +0200, Guillem Jover 
wrote:
>On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
>> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
>> > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>> > > How about documenting that branches prefixed with "wip" can be force
>> > > pushed any time and people pulling from those branches should be
>> > > expected to handle that?
>> >
>> > This would be useful.
>> >
>> > I would already assume any branch prefixed with 'wip' might be rebased
>> > myself, but others might be surprised.
>> 
>> I would like to have this documented somewhere so that people dont get
>> surprised. I am not particularly fond of the wip-prefix though and
>> would appreciate better suggestions.
>
>I think the common prefixes for these are pu/ and next/? These are
>also documented somehow in the gitworkflows(7) man page.

The definition of those prefixes doesn't contain language like "might
be rebased and force-pushed any time".

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

On Sun, Sep 15, 2019 at 09:57:15AM +0200, Bastian Blank wrote:
> On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> > Bastian> For this I need to use my veto as Salsa admin.  With the CI
> > Bastian> people we have to work through too much problems first.

After thinking about it again, let's rephrase this.  I hope this is
better.

| As Salsa admin, I object the inclusion of Salsa CI into the
| recommendation.

Regards,
Bastian

-- 
"Life and death are seldom logical."
"But attaining a desired goal always is."
-- McCoy and Spock, "The Galileo Seven", stardate 2821.7

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

On Fri, Sep 13, 2019 at 12:00:37PM -0400, Sam Hartman wrote:
> Bastian> For this I need to use my veto as Salsa admin.  With the CI
> Bastian> people we have to work through too much problems first.
> What I am hearing you say is that right now, as service admins, you
> cannot support the CI pipeline being used that widely.  I confirm that's
> absolutely a call you get to make as a service adminand that forms a
> blocking objection to recommending that now.
> I'll remove it from the next version.

Thanks.

> Are there additional resources either the salsa admins or the salsa CI
> team needs to move forward to a place where you'd both feel comfortable
> recommending Salsa CI?

We need to sit down and disuss between the admins first what we exactly
require and where we want to go in the future, which is some sort of a
problem right now.

But basically the Salsa CI stuff needs to reduce the resource usage in
various stages as Salsa simply lacks them.

Salsa is also in a weird state.  It's both a large and a small GitLab
installation.  This is source of a lot of those problems.

It is large.  Salsa is one of the largest public accessible GitLab
instances.  The only other I know, git.drupalcode.com, which contains
more projects, is technically a GitLab, but is only used as git web
interface.

It is small.  Salsa is a let's lump all together installation, without
any real separation in terms of resource usage.  This means that
problems in one part quickly break others as well.

> Beyond that though, I think the term "veto" here tends to shut down
> discussion in a way that is not good for the project.

Yeah, it sounded wrong too, but I failed to find something different.

> I think it's fine for you to veto something today.  But I'd encourage
> you to do that in a manner that does not shutdown discussion about the
> future while still being firm about what part of that future you're
> interested in bringing about.

I don't want to shut up any discussion.  It's just that we have not yet
managed to talk through the last outage, which was caused directly by
the Salsa CI and how it does things.

Regards,
Bastian

-- 
You can't evaluate a man by logic alone.
-- McCoy, "I, Mudd", stardate 4513.3

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

Anthony DeRobertis writes:
> On 9/12/19 8:57 AM, Ansgar wrote:
>> I don't see much value in this requirement (besides additional work).
>> One should look at the repository anyway whan planning to do changes
>> (to match the existing style used); one would naturally see how files
>> are organized.  We already had tons of packages shipping a
>> README.source stating "this packages uses quilt, ..." before which I
>> also didn't find very valuable; this seems pretty similar.
>
> Working with packages downstream it's nice to have that
> documented. E.g., needing to patch something for a weird site
> requirement, or backport a fix that isn't a big deal for anyone else
> (so likely wouldn't qualify for a stable update), etc. Not everyone
> who wants to modify a package is familiar with the multitude of ways
> of maintaining packages.

As long as you only need to touch the more trivial parts of the package
and not the upstream source.  There are many more ways to organize
upstream sources; more conventions (for different programming
languages); more workflows; code style conventions; ...

Most of the variance in Debian packaging is much less than what one
would encounter outside of the packaging-specific bits.

Ansgar

Re: Git Packaging Round 2: When to Salsa

[Anthony DeRobertis]

On 9/12/19 8:57 AM, Ansgar wrote:

I don't see much value in this requirement (besides additional work).
One should look at the repository anyway whan planning to do changes
(to match the existing style used); one would naturally see how files
are organized.  We already had tons of packages shipping a
README.source stating "this packages uses quilt, ..." before which I
also didn't find very valuable; this seems pretty similar.



Working with packages downstream it's nice to have that documented. 
E.g., needing to patch something for a weird site requirement, or 
backport a fix that isn't a big deal for anyone else (so likely wouldn't 
qualify for a stable update), etc. Not everyone who wants to modify a 
package is familiar with the multitude of ways of maintaining packages.


dgit makes this a lot better, though.

Re: Git Packaging Round 2: When to Salsa

[Guillem Jover]

On Sun, 2019-09-15 at 00:37:00 +0530, Pirate Praveen wrote:
> On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen  
> wrote:
> > I guess because according to https://trends.debian.net/#vcs-hosting
> > there's *still*, today, almost 1 source packages in unstable which
> > declare they are maintained in git on alioth.
> >
> > I wouldn't call that (part) a success.
> 
> Don't they get redirected to salsa?

Not by default, no. And given how the migration was planned, I don't
see how that would be even possible.

 * There was no automatic migration, so something that was
   previously in alioth might not even be in salsa yet (or ever).
 * When people migrated the repos, they might have used a different
   group name (say from collab-maint/ to debian/), or placed them
   in the personal space, or changed the repo names or used the same
   team but adapting it to the new team namespace policies.
 * git:// URLs would and do not redirect anyway.

But, if the maintainers have done the migration already, they can
always add the redirections manually via:

  https://salsa.debian.org/salsa/AliothRewriter

Thanks,
Guillem

Re: Git Packaging Round 2: When to Salsa

[Guillem Jover]

On Sat, 2019-09-14 at 13:07:09 +0200, Marc Haber wrote:
> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton wrote:
> > On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
> > > How about documenting that branches prefixed with "wip" can be force
> > > pushed any time and people pulling from those branches should be
> > > expected to handle that?
> >
> > This would be useful.
> >
> > I would already assume any branch prefixed with 'wip' might be rebased
> > myself, but others might be surprised.
> 
> I would like to have this documented somewhere so that people dont get
> surprised. I am not particularly fond of the wip-prefix though and
> would appreciate better suggestions.

I think the common prefixes for these are pu/ and next/? These are
also documented somehow in the gitworkflows(7) man page.

Thanks,
Guillem

dgit violating best practices? (Re: Git Packaging Round 2: When to Salsa)

[Holger Levsen]

On Thu, Sep 12, 2019 at 02:57:09PM +0200, Ansgar wrote:
> (Using dgit to upload packages is sadly incompatible with best
> practices around packaging.)

I'm genuinly curious: why do you say so? Which practices does it
violate?


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 15 12:35:18 AM IST, Holger Levsen  
wrote:
>On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
>> On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber
> wrote:
>> >alioth.debian.org, anyone? That one went away pretty fast.
>> I wonder why people keep repeating this. 
>
>I guess because according to https://trends.debian.net/#vcs-hosting
>there's 
>*still*, today, almost 1 source packages in unstable which declare
>they
>are maintained in git on alioth.
>
>I wouldn't call that (part) a success.

Don't they get redirected to salsa?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: When to Salsa

[Holger Levsen]

On Fri, Sep 13, 2019 at 11:30:51AM +0530, Pirate Praveen wrote:
> On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber 
>  wrote:
> >alioth.debian.org, anyone? That one went away pretty fast.
> I wonder why people keep repeating this. 

I guess because according to https://trends.debian.net/#vcs-hosting there's 
*still*, today, almost 1 source packages in unstable which declare they
are maintained in git on alioth.

I wouldn't call that (part) a success.


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Inaki Malerba]

On 13/9/19 15:20, Bastian Blank wrote:
> For this I need to use my veto as Salsa admin.  With the CI people we
> have to work through too much problems first.

If there are _too much problems_ I think you should, at least,
communicate with us.

Besides two issues[0][1] reported some time ago -which are both waiting
for your feedback- nobody has reached us. You are more than welcome to
write us so we can talk about the best way to continue.

Forbidding something you don't like without further explanation doesn't
seem to be the best way to go (applies to all Salsa matters).


On 13/9/19 18:00, Sam Hartman wrote:
> I'll remove it from the next version.

I hope we can discuss this a bit further. There's a lot of work invested
on the project and the main goal is to increase Debian's workflow quality.

> On 13/9/19 18:00, Sam Hartman wrote:
> Are there additional resources either the salsa admins or the salsa CI
> team needs to move forward to a place where you'd both feel comfortable
> recommending Salsa CI?

It would be great to find a way to discuss things between Salsa admins
and users. It's been one way only so far.


Thanks.


0_ https://salsa.debian.org/salsa-ci-team/pipeline/issues/93
1_ https://salsa.debian.org/salsa-ci-team/pipeline/issues/94

-- 
- ina

Re: Git Packaging Round 2: When to Salsa

[Sean Whitton]

Hello,

On Sat 14 Sep 2019 at 01:07PM +02, Marc Haber wrote:

> On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton
>  wrote:
>>On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>>> How about documenting that branches prefixed with "wip" can be force
>>> pushed any time and people pulling from those branches should be
>>> expected to handle that?
>>
>>This would be useful.
>>
>>I would already assume any branch prefixed with 'wip' might be rebased
>>myself, but others might be surprised.
>
> I would like to have this documented somewhere so that people dont get
> surprised. I am not particularly fond of the wip-prefix though and
> would appreciate better suggestions.

Maybe just go ahead and add it to the salsa wiki page, if no-one objects
in this subthread for a few days?

rebasing/
wip/
tmp/
work/

> Are we on the same terminology here, myself saying a rebased and
> force-pushed branch while you only say rebased?

Yes.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Marc Haber]

On Fri, 13 Sep 2019 13:05:20 -0700, Sean Whitton
 wrote:
>On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:
>> How about documenting that branches prefixed with "wip" can be force
>> pushed any time and people pulling from those branches should be
>> expected to handle that?
>
>This would be useful.
>
>I would already assume any branch prefixed with 'wip' might be rebased
>myself, but others might be surprised.

I would like to have this documented somewhere so that people dont get
surprised. I am not particularly fond of the wip-prefix though and
would appreciate better suggestions.

Are we on the same terminology here, myself saying a rebased and
force-pushed branch while you only say rebased?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Git Packaging Round 2: When to Salsa

[Sean Whitton]

Hello,

On Thu 12 Sep 2019 at 09:35PM +02, Marc Haber wrote:

> How about documenting that branches prefixed with "wip" can be force
> pushed any time and people pulling from those branches should be
> expected to handle that?

This would be useful.

I would already assume any branch prefixed with 'wip' might be rebased
myself, but others might be surprised.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Bastian" == Bastian Blank  writes:

Bastian> Hi Sam
Bastian> On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
>> The Salsa CA pipeline is recommended.

Bastian> For this I need to use my veto as Salsa admin.  With the CI
Bastian> people we have to work through too much problems first.

What I am hearing you say is that right now, as service admins, you
cannot support the CI pipeline being used that widely.  I confirm that's
absolutely a call you get to make as a service adminand that forms a
blocking objection to recommending that now.
I'll remove it from the next version.

Are there additional resources either the salsa admins or the salsa CI
team needs to move forward to a place where you'd both feel comfortable
recommending Salsa CI?


Beyond that though, I think the term "veto" here tends to shut down
discussion in a way that is not good for the project.

The people running the service absolutely do get to decide what work
they are willing to do.  Or to say that they would need additional
resources to do something.

But your message and a couple of messages from Alex have come across
like you're saying that service maintainers get to veto things the
project wants.
You don't.

The project gets to decide what it wants.  You as service maintainers
get to decide how much of that you're interested in doing.  You can say
things like "To do that we'd need these things."  You can ask for people
to help, equipment, etc.
Or you can say something like "Actually, that's just beyond what we're
interested in doing no matter what resources we had."  That's all fine.

But the discussion may not stop there.
Often it will.  Often people will understand your point or not care
enough and drop the issue.

But sometimes people will want to talk about whether there are different
ways of splitting responsibilities or create a new team or something
where they can get something they value while respecting what the
current service maintainers are willing to do.

I think it's fine for you to veto something today.  But I'd encourage
you to do that in a manner that does not shutdown discussion about the
future while still being firm about what part of that future you're
interested in bringing about.

Thanks again for letting us all know that the CI pipeline is not ready
for a global recommendation.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Bastian Blank]

Hi Sam

On Sun, Sep 08, 2019 at 05:35:10PM -0400, Sam Hartman wrote:
> The Salsa CA pipeline is recommended.

For this I need to use my veto as Salsa admin.  With the CI people we
have to work through too much problems first.

I don't have anything else to add for now.

Bastian

-- 
Totally illogical, there was no chance.
-- Spock, "The Galileo Seven", stardate 2822.3

Re: Git Packaging Round 2: When to Salsa

[Xavier]

Le Vendredi, Septembre 13, 2019 15:00 CEST, gregor herrmann  
a écrit:
> On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:
>
> > I did do a bit of looking at data.
> > In my unstable sources.list, there are 17863 source packages that
> > include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
> > debian group.
> > That's the largestsingle group; perl-team (next) comes in at 1417.
>
> That's obviously an artifact of our poor Vcs-* information handling
> (in source packages); in reality, of course all of the 3600+
> perl-team packages are maintained on salsa.

Hi,

same for JS-Team packages (~2600)

Regards,
Xavier

Re: Git Packaging Round 2: When to Salsa

[gregor herrmann]

On Thu, 12 Sep 2019 08:14:13 -0400, Sam Hartman wrote:

> I did do a bit of looking at data.
> In my unstable sources.list, there are 17863 source packages that
> include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
> debian group.
> That's the largestsingle group; perl-team (next) comes in at 1417.

That's obviously an artifact of our poor Vcs-* information handling
(in source packages); in reality, of course all of the 3600+
perl-team packages are maintained on salsa.
 

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: Git Packaging Round 2: When to Salsa

[Pirate Praveen]

On 2019, സെപ്റ്റംബർ 13 1:06:13 AM IST, Marc Haber 
 wrote:
>alioth.debian.org, anyone? That one went away pretty fast.

I wonder why people keep repeating this. This was migrated to salsa and also 
archived, so nothing was lost. This was a planned move to a better solution 
(gforge was unmaintained), there was enough time to move things around.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Git Packaging Round 2: When to Salsa

[Guillem Jover]

On Thu, 2019-09-12 at 15:37:49 +0100, Ian Jackson wrote:
> Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> > (Using dgit to upload packages is sadly incompatible with best
> > practices around packaging.)
> 
> Using dgit to upload packages is best practice.

I'm sorry, but "best practice" according to who? The dgit maintainers?

Thanks,
Guillem

Re: Git Packaging Round 2: When to Salsa

[Marc Haber]

On Sun, 08 Sep 2019 22:05:17 -0700, Russ Allbery 
wrote:
>Sean Whitton  writes:
>> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
>
>>> You are encouraged to mirror your repository to Salsa so that people can
>>> find more of the Debian packaging in one place.
>
>> Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
>> salsa?  (I don't object in the least; just wondering about the value.)
>
>Higher chance that the repository won't go away.  For instance, the
>primary home of all of my packaging repositories is on my own Git server
>and will continue to be because I like to have my own personal control
>over such things, but it's in the project's best interest for me to mirror
>them to Salsa so that if I suddenly make millions of dollars and decide I
>just want to read books and stop running online services, the repositories
>don't become inaccessible.

alioth.debian.org, anyone? That one went away pretty fast.

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Git Packaging Round 2: When to Salsa

[Marc Haber]

On Sun, 08 Sep 2019 17:35:10 -0400, Sam Hartman 
wrote:
>* Use a public repository where in-progress and ongoing work are
>  available to the public.  Do not just push when you release.

I would liket to have a recommendation about git push --force in that
case. I frequently do rebase --interactive to sort and bring structure
in my commit histories, which would need a force push in case a commit
which is part of a rebase was already pushed. To avoid this; I
frequenly push only after releasing.

How about documenting that branches prefixed with "wip" can be force
pushed any time and people pulling from those branches should be
expected to handle that?

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Git Packaging Round 2: When to Salsa

[Ian Jackson]

Ansgar writes ("Re: Git Packaging Round 2: When to Salsa"):
> If dgit provides a program to figure this out, people interested in
> obtaining the information automatically can just extract and use that. 

It is not possible to figure out the branch format automatically
given just the maintainer branch.

> (Using dgit to upload packages is sadly incompatible with best
> practices around packaging.)

Using dgit to upload packages is best practice.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Sam Hartman  writes:

>> "Ansgar" == Ansgar   writes:
>
> Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
> Ian> 1. The maintainer's git repository branch format must be
> Ian> documented.  Otherwise another contributor has to guess.  This
> Ian> could be done either by doing maintainer uploads with dgit
> Ian> (since recent versions of dgit include the maintainer branch
> Ian> format information in the git tags), or perhaps by writing
> Ian> something in README.source.
> >> 
> >> Makes sense.  My take is discussion on debian-devel strongly
> >> supports making it easier to figure out what branch format people
> >> are using.
>
> Ansgar> I don't see much value in this requirement (besides
> Ansgar> additional work).  One should look at the repository anyway
> Ansgar> whan planning to do changes (to match the existing style
> Ansgar> used); one would naturally see how files are organized.
>
> I actually find it annoying to figure out which  branch format something
> is.
> I do the work you suggest, but automation or documentation would help me
> as a developer.

I just went through a batch of 240+ team uploads (because *sigh* no
arch-all bin:NMUs). I can confirm it's annoying to have to figure the
the git workflows involved when working at even this modest scale.  If
we're not going to enable people to work on multiple packages, then I
(still) don't really see the point of the Debian salsa team.

d

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
Ian> 1. The maintainer's git repository branch format must be
Ian> documented.  Otherwise another contributor has to guess.  This
Ian> could be done either by doing maintainer uploads with dgit
Ian> (since recent versions of dgit include the maintainer branch
Ian> format information in the git tags), or perhaps by writing
Ian> something in README.source.
>> 
>> Makes sense.  My take is discussion on debian-devel strongly
>> supports making it easier to figure out what branch format people
>> are using.

Ansgar> I don't see much value in this requirement (besides
Ansgar> additional work).  One should look at the repository anyway
Ansgar> whan planning to do changes (to match the existing style
Ansgar> used); one would naturally see how files are organized.

I actually find it annoying to figure out which  branch format something
is.
I do the work you suggest, but automation or documentation would help me
as a developer.

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

On Thu, 2019-09-12 at 08:14 -0400, Sam Hartman wrote:
> Ian> 1. The maintainer's git repository branch format must be
> Ian> documented.  Otherwise another contributor has to guess.  This
> Ian> could be done either by doing maintainer uploads with dgit
> Ian> (since recent versions of dgit include the maintainer branch
> Ian> format information in the git tags), or perhaps by writing
> Ian> something in README.source.
> 
> Makes sense.
> My take is discussion on debian-devel strongly supports making it easier
> to figure out what branch format people are using.

I don't see much value in this requirement (besides additional work). 
One should look at the repository anyway whan planning to do changes
(to match the existing style used); one would naturally see how files
are organized.  We already had tons of packages shipping a
README.source stating "this packages uses quilt, ..." before which I
also didn't find very valuable; this seems pretty similar.

If dgit provides a program to figure this out, people interested in
obtaining the information automatically can just extract and use that. 
(Using dgit to upload packages is sadly incompatible with best
practices around packaging.)

Ansgar

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Sam Hartman  writes:
>
> I did do a bit of looking at data.
> In my unstable sources.list, there are 17863 source packages that
> include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
> debian group.
> That's the largestsingle group; perl-team (next) comes in at 1417.
>
> The debian group is larger than all the individual accounts used on
> salsa combined according to vcs-git in unstable.

Sure, but there's a lot of inertia from collab-maint on alioth when it
was the promoted / only-sensible option. I'd guess that most
collab-maint packages were ported to the debian group.

d

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

>>>>> "Ian" == Ian Jackson  writes:

Ian> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments ---
Ian> ...
>> I realize that not everyone wants all developers to have push
>> access to their packages.  If you have a firm idea about that,
>> then this recommendation is not for you.  I also realize that by
>> starting by recommending the debian group I'm recommending a more
>> permissive maintainership model closer to low threshhold NMU than
>> only NMU my packages after explicit confirmation.  I think that
>> the dh discussion supports the conclusion that we are OK with
>> that as a project *as a recommendation*.  If a maintainer doesn't
>> like that level of openness, that's fine.  My take though is that
>> when recommending what to do to people who do not have
>> preconceived ideas, more open policies like the debian group and
>> low threshhold NMUs are in alignment with the project.

Ian> I absolutely have no problem with recommending this as a
Ian> practice to the individual maintainer who doesn't know better.
Ian> However, for this practice to be useful:

Ian> 1. The maintainer's git repository branch format must be
Ian> documented.  Otherwise another contributor has to guess.  This
Ian> could be done either by doing maintainer uploads with dgit
Ian> (since recent versions of dgit include the maintainer branch
Ian> format information in the git tags), or perhaps by writing
Ian> something in README.source.

Makes sense.
My take is discussion on debian-devel strongly supports making it easier
to figure out what branch format people are using.


Ian> 2. We need to have a shared understanding of when people may
Ian> push to branches in the debian/ repository.  I think you are
Ian> proposing that the answer be "if you do an NMU".  I would
Ian> support this but it is a change to current practice.  We also
Ian> need to understand how this relates to the recommendation to
Ian> NMU to DELAYED.

I'm not  proposing a change to current practice.
I *think* that  the documented practice may not be in alignment with
what happens.
That is, it seems like Debian developers are much more conservative in
how they use the debian group than is permitted by the wiki.

I use the debian group for my packages.
My experience has been that sometimes people push obvious things like
changelog cleanups without asking.  Sometimes I get merge requests.
People will sometimes push fixes to areas of the code they have been
working on especially after I encourage them to do so.
Yes, I could have just given permission to push.  I probably would not
have done so in the instances in question.

I understand this is one person's experience not actual data.

I think in this discussion we can recommend that interested parties
revisit the wiki documentation and see how it matches to reality after
running with the debian group for a few years.

I did do a bit of looking at data.
In my unstable sources.list, there are 17863 source packages that
include salsa.debian.org in the vcs-git.  Of those, 2192 are in the
debian group.
That's the largestsingle group; perl-team (next) comes in at 1417.

The debian group is larger than all the individual accounts used on
salsa combined according to vcs-git in unstable.

So, what I'm seeing is that most people maintain packages in teams.
When they choose to maintain packages not in an explicit team, the
debian group is the dominant choice.
That choice is common enough that we have a strong presumption that it
actually works for people.  If it were a complete mess of people pushing
without thinking or considering consequences we'd be hearing about it
more.

My take is that I think I have sufficient support for my original
recommendation on using debian at this point.  Adding Ian's
recommendation that you need to document the branch format makes sense.

Revisiting what current practice is for the debian group and how that
interacts with NMUs and delayed also makes sense.
I don't think we need to block on that happening.  I do not plan to lead
that discussion: I don't think I have time.

As always, continued feedback welcome; this is where I see things at
this point in the discussion.

--Sam

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Ian Jackson  writes:

> Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
>> Discussion Comments
>> ---
> ...
>> I realize that not everyone wants all developers to have push access to
>> their packages.  If you have a firm idea about that, then this
>> recommendation is not for you.  I also realize that by starting by
>> recommending the debian group I'm recommending a more permissive
>> maintainership model closer to low threshhold NMU than  only NMU my
>> packages after explicit confirmation.  I think that the dh discussion
>> supports the conclusion that we are OK with that as a project *as a
>> recommendation*.  If a maintainer doesn't like that level of openness,
>> that's fine.  My take though is that when recommending what to do to
>> people who do not have preconceived ideas, more open policies like the
>> debian group and low threshhold NMUs are in alignment with the project.
>
> I absolutely have no problem with recommending this as a practice to
> the individual maintainer who doesn't know better.  However, for this
> practice to be useful:
>
> 1. The maintainer's git repository branch format must be documented.
> Otherwise another contributor has to guess.  This could be done either
> by doing maintainer uploads with dgit (since recent versions of dgit
> include the maintainer branch format information in the git tags), or
> perhaps by writing something in README.source.
>
> 2. We need to have a shared understanding of when people may push to
> branches in the debian/ repository.  I think you are proposing that
> the answer be "if you do an NMU".  I would support this but it is a
> change to current practice.  We also need to understand how this
> relates to the recommendation to NMU to DELAYED.
>
> 3. The answers to (1) and (2) need to be documented.
>
> I would like to suggest another possible widening of when to push to a
> branch in the debian group on salsa: "if you would do an NMU, but for
> some reason an actual upload is not desirable right now".  Examples
> could include packages owned by QA, if a maintainer invites you to
> make a change, if a bug needs fixing but for transition or migration
> or similar release management reasons it is not a good time for an
> upload.
>

This first part is consistent with my intuition / understanding. I
haven't had time to absorb the rest.

d

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "David" == David Bremner  writes:

l reaction,
David> but I'm not currently very comfortable with any DD being able
David> to make global changes to thousands of git repos. I think we
David> haven't yet developed any kind of social conventions or rules
David> about when that is appropriate, and we don't have much
David> project experience with it. That's possibly a seperate
David> discussion, but if mass changes are the justification for
David> some other policy/norm/standard/reccomendation, then maybe it
David> should be discussed first.

I think that it's worth continuing to discuss the above.  I think it is
closely related to the disagreement here.  It may be possible to come to
consensus on a default recommendation for where to stick stuff on Salsa
without deciding how we feel about mass changes, but they are related
enough that they will influence each other.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Ian Jackson]

Sam Hartman writes ("Git Packaging Round 2: When to Salsa"):
> Discussion Comments
> ---
...
> I realize that not everyone wants all developers to have push access to
> their packages.  If you have a firm idea about that, then this
> recommendation is not for you.  I also realize that by starting by
> recommending the debian group I'm recommending a more permissive
> maintainership model closer to low threshhold NMU than  only NMU my
> packages after explicit confirmation.  I think that the dh discussion
> supports the conclusion that we are OK with that as a project *as a
> recommendation*.  If a maintainer doesn't like that level of openness,
> that's fine.  My take though is that when recommending what to do to
> people who do not have preconceived ideas, more open policies like the
> debian group and low threshhold NMUs are in alignment with the project.

I absolutely have no problem with recommending this as a practice to
the individual maintainer who doesn't know better.  However, for this
practice to be useful:

1. The maintainer's git repository branch format must be documented.
Otherwise another contributor has to guess.  This could be done either
by doing maintainer uploads with dgit (since recent versions of dgit
include the maintainer branch format information in the git tags), or
perhaps by writing something in README.source.

2. We need to have a shared understanding of when people may push to
branches in the debian/ repository.  I think you are proposing that
the answer be "if you do an NMU".  I would support this but it is a
change to current practice.  We also need to understand how this
relates to the recommendation to NMU to DELAYED.

3. The answers to (1) and (2) need to be documented.

I would like to suggest another possible widening of when to push to a
branch in the debian group on salsa: "if you would do an NMU, but for
some reason an actual upload is not desirable right now".  Examples
could include packages owned by QA, if a maintainer invites you to
make a change, if a bug needs fixing but for transition or migration
or similar release management reasons it is not a good time for an
upload.

> I realize that a number of people choose not to use Salsa.  Reasons have
> included:
...
> * Wanting to use a platform less under the control of a small number of
>   administrators than Salsa

You are missing one: some people think the software behind Salsa is
not Free enough.

> Non-Free Services
> -
...
> Using non-free services for Debian packaging is not recommended but is
> permitted.

I strongly disagree with this, or at least, with what seems to me to
be the obvious implication.  It is also contrary to our current
practice.

No-one should be asked to interact with a non-free service, as part of
contributing to Debian.

Note I say "no-one should be asked".  It is not enough, for me, for
there to be a "plan (b)" route.  Ie, it is not OK for a maintainer to
advertise a github repo as preferred, or to ask for PRs on github,
even if an alternative or mirror, or Salsa, or the BTS are also
advertised.

This is for two reasons: firstly, this is a matter of principle.  Our
mission is free software.  Free software needs free tools.  We should
not be advertising or encouraging the use of non-free tools.

Secondly, there is a practical problem if a maintainer (even a solo
maintainer) chooses to regard a nonfree service as primary.  If
another person comes along and wants to help out with that package,
they will either have to also tolerate using the nonfree service, or
they will have to try to persuade the maintainer to abandon their
existing hosting or tools (and maybe the maintainer's existing
workflow, if the nonfree tools are significantly different).  For me
that is wholly unacceptable.

> If the use of a non-free service is preventing an active member of
> our community from contributing to a team, the team should work to
> find a solution so that member can contribute effectively.

This is no good as an answer.

In practice imprecations to a team (or a maintainer) to "find a
solution so that a Debian contributor can contribute effectively" will
be useless because:

(i) Even having to ask this question already makes the new contributor
seem awkward, puts them at a social disadvantage, and perhaps annoys
people.

(ii) We lack workable enforcement mechanisms for this kind of
imprecation.  (Because we lack *any* workable enforcement mechanisms
to deal with obstructive maintainer behaviours.)

(iii) Even if everyone has good will, and or even if we had excellent
and proportionate and swift enforcement mechanism, there will
inevitably be a delay and hassle and friction.

In summary: people who refuse to use nonfree software must be 100%
first class citizens within Debian.  Nothing that we do must
disadvantage those people in an

Re: Git Packaging Round 2: When to Salsa

[Enrico Zini]

On Tue, Sep 10, 2019 at 08:13:15AM -0300, David Bremner wrote:

> I'm also not sure if this is a completely rational reaction, but I'm not
> currently very comfortable with any DD being able to make global changes
> to thousands of git repos. I think we haven't yet developed any kind of
> social conventions or rules about when that is appropriate, and we don't
> have much project experience with it. That's possibly a seperate
> discussion, but if mass changes are the justification for some other
> policy/norm/standard/reccomendation, then maybe it should be discussed
> first.

To me, given that the recommendation is optional, and doesn't apply to
teams, it doesn't seem that much different than turning the low
threshold NMU[1] idea into a practical workflow instead of a wiki page
that one tends to forget looking it up before doing a NMU.

So I personally read the proposal as:

 - besides the option of adding my name to [1], I can also choose to put
   a package in the debian group in salsa, where it fits in a well known
   workflow
 - if a maintainer has no better ideas, we propose this as the default
   workflow for non-team-maintained packages

Team packages will be maintained in whatever way a team chooses to.
Packages over which one wants more control will be maintained in a
personal repo or wherever one wants, and it's all ok.

For the rest, I think this is a definite improvement over the status
quo, which I understand more or less as "do something at random and
please don't suddenly disappear".


Enrico

[1] https://wiki.debian.org/LowThresholdNmu
-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini 


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Scott Kitterman]

On September 10, 2019 10:12:39 AM UTC, Sam Hartman  wrote:
>> "Scott" == Scott Kitterman  writes:
>
>
>Scott> I don't think your alleged works poorly for using your own
>Scott> namespace are real problems.
>
>I would be a lot happier if your message was phrased in terms of
>discussing which trade off you prefer.
>It's clear from past discussion that people are concerned about these
>issues.
>I hear you as saying that you value other things more .

I value maintainers having a sense of responsibility for their packages.  I 
think that we've pushed the benefits of loosening maintainer control (and there 
are certainly benefits) about as far as we can without risking it becoming 
meaningless.  If everyone is responsible for something, what that really means 
is that no one is.

I think people feeling like someone else will handle things is a much bigger 
problem than losing ephemera like historical merge requests.

>Scott> Since git has no single central
>   Scott> repository moving is as simple as a clone and then push it to
>Scott> the new location.  If there are multiple instances of a
>   Scott> package on salsa (which can happen for any number of reasons)
>Scott> the "official" one is the one the Vcs-* point to.
>
>I do believe this viewpoint has been considered in the discussion.
>I don't have the counter-arguments at hand that have been made.  So
>here
>I'm responding with my own opinion rather than trying to make a call
>based on past discussions.
>
>* There's a lot in Gitlab beyond just the repo.  Cloning a repo doesn't
>  clone merge requests, issues, wiki, pipelines, or artifacts among
>  others.
>
>* It doesn't clone access control information
>
>* There is a significant coordination/transition cost in changing names
>  even when no information is lost.
>
>* There's value in stability of names.  As an example does everyone
>look
>  at vcs-* out of unstable rather than say testing or stable?
>
>I suspect you have considered most if not all of the above.  I do hear
>you as saying you value other things (which I think you have not yet
>specified) more.
>
>However, when you say that a concern is not valid, it's easy to read
>that as saying that it is unreasonable to value fixing that concern.  I
>disagree strongly: I think a technical concern with trade offs on both
>sides has been articulated.

See above.  Personally, I usually end up looking at tracker.d.o which uses the 
most recent version.

While I think having a common Debian namespace for packages is fine for people 
that want it, I think the arguments for it are overstated.  We had collab-maint 
on alioth, but it was harder to deal with alternatives then.  Let's not make 
present virtue out of past necessity.

I don't agree with the "people are used to it" argument either.  On platforms 
like GitHub there's a working assumption that only regular commiters can 
directly commit.  Everyone else uses pull requests.Now that we are on 
gitlab, a common namespace is far less beneficial than it used to be.

Scott K

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Russ Allbery  writes:

> 3. Anyone who comes from a tech company / Silicon Valley development
>environment is probably going to already be used to this style of
>collective ownership (along with politeness conventions about not
>messing with other people's stuff unless you have talked to them or
>know what you're doing), since this is an extremely common development
>model there, and this will feel natural.

This specifically I have to disagree with. I think anyone with this
background will be used to doing merge requests. I think the idea of
needing direct push access to many repos is specific to Debian. Maybe
there are different subcultures out there, and we have exposure to
somewhat disjoint sets.

> 5. We can easily make mass changes to these packages, which is something
>we've not done much of historically but which would be a powerful new
>tool.  It would be even more powerful if we could do that for all
>packages, of course, but that has more social tradeoffs, and it's still
>useful to be able to do mass changes to a class of packages that may be
>the ones with the least "attached" maintainers to the project who may
>not be following project-wide discussions.

In order mass changes to be possible, there needs to be a common
workflow for packages in the debian group. In order for automation to
work, we need not just a general recommendation but a rigid policy. I'm
not objecting to that, but I don't think it exists now. In fact I think
this is probably an interesting answer to Zigo's proposal to make a
uniform git workflow mandatory, which is to do that for the Debian salsa
team.

I'm also not sure if this is a completely rational reaction, but I'm not
currently very comfortable with any DD being able to make global changes
to thousands of git repos. I think we haven't yet developed any kind of
social conventions or rules about when that is appropriate, and we don't
have much project experience with it. That's possibly a seperate
discussion, but if mass changes are the justification for some other
policy/norm/standard/reccomendation, then maybe it should be discussed
first.

Re: Git Packaging Round 2: When to Salsa

[Jonas Smedegaard]

Quoting Russ Allbery (2019-09-10 03:50:47)
> I think using the debian namespace is the right default, particularly 
> when we view it through the lens of what's best for the project.
> 
> Think of it this way: we have a new Debian package maintained by 
> someone who's maybe new to the project.  What kind of experience do we 
> want them to have by default, and how do we want to store their work 
> to reduce the risk of various failure modes with new maintainers?
[...]
> Obviously, we cannot and should not *require* using the debian 
> namespace, and anyone who wants to can certainly create their own 
> namespaces.  But I think it's important to note here that folks like 
> Jonas are not the target audience for these recommendations.  Anyone 
> who, like him, already is doing Debian packaging and already knows how 
> Debian works can continue to manage their packages however they want.  
> They already know the onboarding costs and are comfortable with them, 
> the project has a track record with them and knows they're not likely 
> to disappear, etc.

Thanks for the clarification, Russ.

I agree with the "debian" area being a sensible default.

@Sam: I apologize for misreading your proposal. Reading it again, I see 
absolutely nothing wrong with it - it was simply me not reading properly 
the first time.  Sorry!

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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


signature.asc
Description: signature

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Scott" == Scott Kitterman  writes:


Scott> I don't think your alleged works poorly for using your own
Scott> namespace are real problems.

I would be a lot happier if your message was phrased in terms of
discussing which trade off you prefer.
It's clear from past discussion that people are concerned about these
issues.
I hear you as saying that you value other things more .

Scott> Since git has no single central
Scott> repository moving is as simple as a clone and then push it to
Scott> the new location.  If there are multiple instances of a
Scott> package on salsa (which can happen for any number of reasons)
Scott> the "official" one is the one the Vcs-* point to.

I do believe this viewpoint has been considered in the discussion.
I don't have the counter-arguments at hand that have been made.  So here
I'm responding with my own opinion rather than trying to make a call
based on past discussions.

* There's a lot in Gitlab beyond just the repo.  Cloning a repo doesn't
  clone merge requests, issues, wiki, pipelines, or artifacts among
  others.

* It doesn't clone access control information

* There is a significant coordination/transition cost in changing names
  even when no information is lost.

* There's value in stability of names.  As an example does everyone look
  at vcs-* out of unstable rather than say testing or stable?

I suspect you have considered most if not all of the above.  I do hear
you as saying you value other things (which I think you have not yet
specified) more.

However, when you say that a concern is not valid, it's easy to read
that as saying that it is unreasonable to value fixing that concern.  I
disagree strongly: I think a technical concern with trade offs on both
sides has been articulated.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Scott Kitterman]

On September 10, 2019 1:26:35 AM UTC, Sam Hartman  wrote:
>> "David" == David Bremner  writes:
>
>David> Sam Hartman  writes:
>>>> "Jonas" == Jonas Smedegaard  writes:
>>> 
>>> 
>   Jonas> I think there is a general consensus on working in teams, and
>   Jonas> therefore using git repos belonging to teams - but not to use
>Jonas> that one giant "team" called "debian".
>>> 
>>> What would you recommend people do if they have a package that
>>> doesn't fit into an existing team.
>>> 
>>> --Sam
>
>David> One option is putting them in their own user namespace. This
>David> is generally my preferred option for packages that are not
>David> maintained as part of a team. I think the option of merge
>David> requests reduces the need to give out direct push access.
>
>I tried to cover the disadvantages of this in the original mail:
>
>* Works poorly when maintainership changes
>
>* Works poorly when account status changes
>
>I am sure you're aware of these, but I want to make sure they are on
>the
>table.
>And obviously, the debian group has disadvantages:
>
>* works poorly if you don't want everyone having push access
>
>  * Because you don't want to be that open with your package
>
> * Because you are mirroring or something where having push access will
>break things
>
>There are a number of ways forward:
>
>1) Add a recommendation for people who don't want to give push access
>to
>all developers.  Personal namespaces is the only option I've seen so
>far.
>
>2) Only recommend personal namespaces and never debian
>
>3) Note both options but not make a recommendation between them
>
>4) Something along the lines of the current text; Jonas has explicitly
>disagreed with this approach
>
>5) Make no recommendations in this space
>
>While I've been monitoring a lot of discussions, this issue is one
>where
>we'd need significantly more feedback than we've received so far for me
>to call a consensus.

I don't think your alleged works poorly for using your own namespace are real 
problems.  Since git has no single central repository moving is as simple as a 
clone and then push it to the new location.  If there are multiple instances of 
a package on salsa (which can happen for any number of reasons) the "official" 
one is the one the Vcs-* point to.

For other VCS I think those would be valid concerns, but for git they can be 
trivially avoided.

Scott K

Re: Git Packaging Round 2: When to Salsa

[Russ Allbery]

Sam Hartman  writes:

> There are a number of ways forward:

> 1) Add a recommendation for people who don't want to give push access to
> all developers.  Personal namespaces is the only option I've seen so
> far.

> 2) Only recommend personal namespaces and never debian

> 3) Note both options but not make a recommendation between them

> 4) Something along the lines of the current text; Jonas has explicitly
> disagreed with this approach

> 5) Make no recommendations in this space

> While I've been monitoring a lot of discussions, this issue is one where
> we'd need significantly more feedback than we've received so far for me
> to call a consensus.

I think using the debian namespace is the right default, particularly when
we view it through the lens of what's best for the project.

Think of it this way: we have a new Debian package maintained by someone
who's maybe new to the project.  What kind of experience do we want them
to have by default, and how do we want to store their work to reduce the
risk of various failure modes with new maintainers?

My arguments in favor of the debian namespace:

1. This has the lowest bar of entry: you don't have to set up a namespace
   or think about access control.

2. This has the lowest friction for collaborative work and onboarding new
   contributors.

3. Anyone who comes from a tech company / Silicon Valley development
   environment is probably going to already be used to this style of
   collective ownership (along with politeness conventions about not
   messing with other people's stuff unless you have talked to them or
   know what you're doing), since this is an extremely common development
   model there, and this will feel natural.

4. This has the least risk for the project if the person doing the work
   disappears.  We don't have to move the Git repository, change ACLs,
   recover history from somewhere else, etc.  Anyone else can pick up work
   as needed in the same place.

5. We can easily make mass changes to these packages, which is something
   we've not done much of historically but which would be a powerful new
   tool.  It would be even more powerful if we could do that for all
   packages, of course, but that has more social tradeoffs, and it's still
   useful to be able to do mass changes to a class of packages that may be
   the ones with the least "attached" maintainers to the project who may
   not be following project-wide discussions.

Obviously, we cannot and should not *require* using the debian namespace,
and anyone who wants to can certainly create their own namespaces.  But I
think it's important to note here that folks like Jonas are not the target
audience for these recommendations.  Anyone who, like him, already is
doing Debian packaging and already knows how Debian works can continue to
manage their packages however they want.  They already know the onboarding
costs and are comfortable with them, the project has a track record with
them and knows they're not likely to disappear, etc.

I'm also a little bit uncomfortable with putting some of my packages
(particularly the ones for which I'm also upstream) into the debian
namespace because I want more control.  (This may be an unproductive
emotional reaction; I may decide later that this is wrong.  But it was my
first reaction.)  But I don't think we should look at this through whether
it matches what I, or Jonas, or David, or someone else already deeply
enmeshed in Debian would do.  We should be choosing a default
recommendation anticipating the mindset of a new developer instead.

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

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "David" == David Bremner  writes:

David> Sam Hartman  writes:
>>> "Jonas" == Jonas Smedegaard  writes:
>> 
>> 
Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that one giant "team" called "debian".
>> 
>> What would you recommend people do if they have a package that
>> doesn't fit into an existing team.
>> 
>> --Sam

David> One option is putting them in their own user namespace. This
David> is generally my preferred option for packages that are not
David> maintained as part of a team. I think the option of merge
David> requests reduces the need to give out direct push access.

I tried to cover the disadvantages of this in the original mail:

* Works poorly when maintainership changes

* Works poorly when account status changes

I am sure you're aware of these, but I want to make sure they are on the
table.
And obviously, the debian group has disadvantages:

* works poorly if you don't want everyone having push access

  * Because you don't want to be that open with your package

  * Because you are mirroring or something where having push access will
break things

There are a number of ways forward:

1) Add a recommendation for people who don't want to give push access to
all developers.  Personal namespaces is the only option I've seen so
far.

2) Only recommend personal namespaces and never debian

3) Note both options but not make a recommendation between them

4) Something along the lines of the current text; Jonas has explicitly
disagreed with this approach

5) Make no recommendations in this space

While I've been monitoring a lot of discussions, this issue is one where
we'd need significantly more feedback than we've received so far for me
to call a consensus.

--Sam

Re: Git Packaging Round 2: When to Salsa

[David Bremner]

Sam Hartman  writes:

>> "Jonas" == Jonas Smedegaard  writes:
>
>
> Jonas> I think there is a general consensus on working in teams, and
> Jonas> therefore using git repos belonging to teams - but not to use
> Jonas> that one giant "team" called "debian".
>
> What would you recommend people do if they have a package that doesn't
> fit into an existing team.
>
> --Sam

One option is putting them in their own user namespace. This is
generally my preferred option for packages that are not maintained as
part of a team. I think the option of merge requests reduces the need to
give out direct push access.

d

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Jonas" == Jonas Smedegaard  writes:


Jonas> I think there is a general consensus on working in teams, and
Jonas> therefore using git repos belonging to teams - but not to use
Jonas> that one giant "team" called "debian".

What would you recommend people do if they have a package that doesn't
fit into an existing team.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Jonas Smedegaard]

Quoting Sam Hartman (2019-09-09 19:49:25)
> > "Ansgar" == Ansgar   writes:
> 
> Ansgar> Sam Hartman writes:
> >> If you are a Debian Developer packaging a package for inclusion
> >> in Debian, you should store your packaging information in one
> >> repository per package on salsa.debian.org in the debian group.
> >> That is you should create a repository under
> >> https://salsa.debian.org/debian .
> 
> Ansgar> This allows everyone to do arbitrary changes and presumably
> Ansgar> upload the package.  That is quite a large change that I'm
> Ansgar> not sure everyone likes.
> 
> I'm sure some people don't like it.  What I'm hoping to get here is
> comments on whether I've correctly judged consensus that the rough
> consensus is we're OK with that as a general recommendation.

It is not my impression that there is a general concensus on that, no.

I think there is a general consensus on working in teams, and therefore 
using git repos belonging to teams - but not to use that one giant 
"team" called "debian".

Yes, my impression on this might be biased by my own personal opinion.  
Perhaps it makes sense to look at statistics of how much the debian part 
of salsa is currently used, compared ot other teams' get areas.  Sorry, 
I don't know how to extract such statistics, but am sure some do.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

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


signature.asc
Description: signature

Re: Git Packaging Round 2: When to Salsa

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> Sam Hartman writes:
>> If you are a Debian Developer packaging a package for inclusion
>> in Debian, you should store your packaging information in one
>> repository per package on salsa.debian.org in the debian group.
>> That is you should create a repository under
>> https://salsa.debian.org/debian .

Ansgar> This allows everyone to do arbitrary changes and presumably
Ansgar> upload the package.  That is quite a large change that I'm
Ansgar> not sure everyone likes.

I'm sure some people don't like it.  What I'm hoping to get here is
comments on whether I've correctly judged consensus that the rough
consensus is we're OK with that as a general recommendation.

--Sam

Re: Git Packaging Round 2: When to Salsa

[Ansgar]

Sam Hartman writes:
> If you are a Debian Developer packaging a package for inclusion in
> Debian, you should store your packaging information in one repository
> per package on salsa.debian.org in the debian group.  That is you should
> create a repository under https://salsa.debian.org/debian .

This allows everyone to do arbitrary changes and presumably upload the
package.  That is quite a large change that I'm not sure everyone likes.

+---
| Direct commits to repositories in the Debian group by any Debian
| developer are implicitly welcome. No pre-commit coordination
| (e.g. merge-request or mail) is expected.
+---[ 
https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group 
]

Ansgar

Re: Git Packaging Round 2: When to Salsa mirror

[Ansgar]

Geert Stappers writes:
> On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
>> Higher chance that the repository won't go away.
>
> Where is Alioth? As retoric question.

The repositories on Alioth weren't lost and can still be found archived
on https://alioth-archive.debian.org/

> What about Vcs-Mirror-*  for actual telling where a mirror is.
> In case of `git` is "mirror" a "clone"

Arguably in Git everything but the maintainer's local repository might
be a mirror.  This was even called a security feature as hash collisions
might need to be sneaked in there to get included in release tarballs[1].

Ansgar

  [1] 
https://public-inbox.org/git/pine.lnx.4.58.0504291221250.18...@ppc970.osdl.org/

Re: Git Packaging Round 2: When to Salsa

[Colin Watson]

On Mon, Sep 09, 2019 at 10:22:03AM +0100, Nikolaus Rath wrote:
> On Sep 08 2019, Sam Hartman  wrote:
> > Hopefully you will choose to monitor merge requests for your
> > repository.  If not, turn off merge requests.
> 
> Monitor *and respond to* might be a better phrasing..?

I don't think I can promise to respond to every merge request on my
packages any more than I can promise to respond to every bug report.
It's fine for us to say that this sort of thing should actually result
in somebody getting some kind of notification rather than going into an
effective black hole where nobody sees it except by chance; but
requiring a response in all cases is effectively an SLA ("service level
agreement"), and I can't realistically give SLAs unless I'm being paid
for it.

-- 
Colin Watson   [cjwat...@debian.org]

Re: Git Packaging Round 2: When to Salsa

[Nikolaus Rath]

On Sep 08 2019, Sam Hartman  wrote:
> Hopefully you will choose to monitor merge requests for your
> repository.  If not, turn off merge requests.

Monitor *and respond to* might be a better phrasing..?

Best,
Nikolaus
-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Git Packaging Round 2: When to Salsa mirror

[Geert Stappers]

On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:
> Sean Whitton  writes:
> > On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:
> 
> >> You are encouraged to mirror your repository to Salsa so that people can
> >> find more of the Debian packaging in one place.
> 
> > Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
> > salsa?  (I don't object in the least; just wondering about the value.)
> 
> Higher chance that the repository won't go away.

Where is Alioth? As retoric question.

What about Vcs-Mirror-*  for actual telling where a mirror is.
In case of `git` is "mirror" a "clone"


Groeten
Geert Stappers
-- 
Leven en laten leven


signature.asc
Description: PGP signature

Re: Git Packaging Round 2: When to Salsa

[Russ Allbery]

Sean Whitton  writes:
> On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:

>> You are encouraged to mirror your repository to Salsa so that people can
>> find more of the Debian packaging in one place.

> Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
> salsa?  (I don't object in the least; just wondering about the value.)

Higher chance that the repository won't go away.  For instance, the
primary home of all of my packaging repositories is on my own Git server
and will continue to be because I like to have my own personal control
over such things, but it's in the project's best interest for me to mirror
them to Salsa so that if I suddenly make millions of dollars and decide I
just want to read books and stop running online services, the repositories
don't become inaccessible.

(Of course, I upload all of my stuff with dgit, so even in that case not
everything would be lost, but Salsa would preserve unreleased work,
branches that weren't uploaded with dgit, and so forth.)

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

Re: Git Packaging Round 2: When to Salsa

[Sean Whitton]

Hello,

On Sun 08 Sep 2019 at 05:35PM -04, Sam Hartman wrote:

> You are encouraged to mirror your repository to Salsa so that people can
> find more of the Debian packaging in one place.

Hmm, if the Vcs-* are set correctly, what's the value of mirroring to
salsa?  (I don't object in the least; just wondering about the value.)

-- 
Sean Whitton


signature.asc
Description: PGP signature

Git Packaging Round 2: When to Salsa

[Sam Hartman]

So, this is much harder than the dh discussion.
Here, we're not trying to come to a consensus on policy changes.
And here, the level of agreement is not as high.

I'd like to start by thanking the Salsa admins for running a great
service and for answering some naive questions I had while putting this
mail together.

First, I guess I should see if we're in the same place on what we're
trying to accomplish.

Based on what I've seen, I think we can come up with recommendations
that are entirely optional.
One purpose these can serve is to guide people who are starting a new
package and simply want to follow something they know a bunch of other
people are doing.

In some cases we can make conditional recommendations about best
practice.  Fore example, in round one we seem to have agreed that
leaving merge requests enabled while entirely ignoring them with no one
set to receive notifications is a definite worst practice.

Judging consensus on optional recommendations is harder than judging
consensus in the dh discussion.  For example "Hey, I do not want to do
that," may not even be an argument against a recommendation.  Similarly,
"There are circumstances where that would be wrong," may be an argument
for documenting the circumstances or may even be an argument for no
change.

I can really use your help here.  If you're providing feedback please
make it clear whether you're arguing to refine/constrain the
recommendation, just providing context, or arguing that I'm misreading
what we as a community want to do.  And as always, it's more helpful if
you explain why.

Deferred for Round 3


In this message I'm trying to focus on when we should use
salsa.debian.org and where we should put stuff on that server.

I'm hoping to cover git branch format, upstream tarballs, pristine-tar,
and upstream integrity in round 3.

General Recommendation
==

This recommendation is intended for people who are simply looking for an
approach that will work well with approaches others are using.  If you
are packaging something in a large team, follow their existing
practices.  If you are setting up a new team, see the recommendation for
teams.  If you have your own ideas about what you'd like to do and
choose to disregard this recommendation, that is also fine.  If you
do not already know the answer you want, this recommendation is for you.

If you are a Debian Developer packaging a package for inclusion in
Debian, you should store your packaging information in one repository
per package on salsa.debian.org in the debian group.  That is you should
create a repository under https://salsa.debian.org/debian .

You should make sure that at least one person sets their notification
level to 'watch' rather than global.  This way you will receive
notifications of merge requests and changes.

Hopefully you will choose to monitor merge requests for your
repository.  If not, turn off merge requests.

If you are not a Debian Developer, you cannot directly create a
repository in the debian group.  If you're willing to wait for a Debian
Developer to create a repository for you and grant you access, that may
make things simpler longer-term.  If that wait would be long enough to
frustrate you or demotivate you, you should
[do what?  Create a repo in their personal namespace on salsa?]

By creating a repository in the debian group, you grant access to all
developers.  That way people performing NMUs can directly commit their
changes.  It will also make it easier if you later orphan the package to
preserve version control history.

The Salsa CA pipeline is recommended.

Notes and Limitations
-

The debian group is great for relatively unrelated packages.  It may not
be appropriate for a large number of related packages (especially when
maintained by a team) for these reasons:

* It is hard to examine the group of related packages without also
  seeing other unrelated packages

* You cannot subscribe to watch a group of related packages with one
  click

* Access to people who are not Debian Developers needs to be granted on
  a per-repository basis in the debian group

Some teams with a large number of packages have adopted a
monolithic format where a single repository contains information for
many packages.  It is not the intent of this recommendation to judge
that approach either positively or negatively; this recommendation is
targeted at a very different audience.

This recommendation is not appropriate in cases when Debian Developers
should not have push access to the repository.  For example if you are
mirroring the repository from another service and do not want changes
pushed to this replica, using the debian group is inappropriate.

Discussion Comments
---

This is my notes for the debian-devel discussion.  I'm not sure how much
of any of the text here will survive into something that lasts, but the
"discussion comments" subsections are explicitly intended only for