Git Packaging Round 2: When to Salsa

classic Classic list List threaded Threaded
117 messages Options
1234 ... 6
Reply | Threaded
Open this post in threaded view
|

Git Packaging Round 2: When to Salsa

Sam Hartman-3


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

Obviously, I need input on what we should recommend for non-DDs who are
packaging.  We can create repos in the debian group for them, but what's
the best practice if you don't want to wait that long?


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 realize that a number of people choose not to use Salsa.  Reasons have
included:

* Wanting to do packaging development in the upstream repository

* Wanting to use a platform less under the control of a small number of
  administrators than Salsa

* Not using Git

My take is that those people can ignore this recommendation.  My big
question here is whether there is consensus behind this being the
default recommendation if you don't have something else you want to do.


Packages not on Salsa
=====================

Some people choose not to host their packages on Salsa for a variety of
reasons.  Examples include wanting to host Debian packaging in the same
repository as upstream development when the Debian and upstream
maintainers are related.  Even if you do not host your packaging work on
Salsa you should:

* Host your packaging work in Git.

* Use a public repository where in-progress and ongoing work are
  available to the public.  Do not just push when you release.

* Set the vcs-git and vcs-browser fields in debian/control to point to
  your repository.

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

Non-Free Services
-----------------

It is important to many members of our community that they be able to do
work within Debian without using non-free software or web services that
depend on non-free software.  Github is a common example of a web
service that uses non-free software.
Clearly community members can use the BTS, make NMUs and interact with
mailing lists.

However, not being able to interact with packaging Git repos can
significantly reduce developer's effectiveness.

Evaluate the impact on our community before using a non-free service
like Github for Debian packaging.  Would your needs be met by mirroring
from free services to non-free services?

Using non-free services for Debian packaging is not recommended but is
permitted.

Some have suggested that we forbid the use of non-free services for
Debian packaging.  First, we'd rather public git repositories be
available than for example have people claim they are not using VCS at
all.  Secondly, we don't even have a mechanism to codify such a policy,
nor is it clear that it would be desirable to have formal policy for
what tools people use prior to upload.

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.


Discussion Comments
-------------------

The biggest question here is whether we have consensus that people
should be using Git.
I've seen two arguments against:

1) Simon pointed out that especially for upstreams with large files Git
may not be a fit.  However, I think that even in these cases the Debian
packaging can be in Git.  (Also, git-lfs may be appropriate in some
cases)

2) Upstreams that use some other VCS than Git.  I need more input here.
Would we prefer that people have Debian only packaging repos?  Would we
prefer that they use athe other VCS?  Do we not have enough consensus to
have a recommendation in this case.

The second issue where we've had some significant discussion is around
non-free services.
I'd appreciate feedback on whether I've gotten that right.

Recommendation for Teams
========================

The debian group on Salsa may not be the best choice for teams
maintaining a large number of packages.  The team packages will be mixed
together with other packages and that may be confusing.

Often, a team will want their own group to segregate their packages.

In this case the team should create a team group on Salsa and store
their packages there.  This will make looking at changes to these
packages, merge requests for the set of packages, and CI information
easier.

It is not possible to grant the debian group access to all packages in a
group at once.  However, if a team wishes, they may grant push access to
the debian group on a package-by-package basis.

Best practice is for multiple people to have owner privileges on the
team.  If the team owner leaves Debian, having a second team owner will
make managing the team easier.  Similarly if an account is locked for
security reasons, having a second owner will make the transition
smoother.


Account Transitions
===================

This isn't so much a case where we have a recommendation as where it
seems like we need to do more work.

There are some awkward issues around Salsa accounts:

* When you retire from Debian or are removed, your salsa account becomes
  inaccessible.  That means you no longer have access to teams and repos
  that you are granted access to.

* Granting access to repositories in personal namespace becomes
  problematic.  You will typically no longer be able to push to
  repositories in your personal namespace.

* If you are the only active team owner for a team, gaining access to
  the team will require administrator action and will be relatively
  slow.

* You will need to regain access to any repositories that you should
  have access to.

Depending on why an account is locked, the above may be strongly desired
or deeply frustrating.

There's been enough discussion of this issue that it seems like someone
should take on the task of trying to figure out what we as a project
want.  Solutions might include:

* Procedures that get followed when accounts are closed.  We probably
  don't want more effort added to the tasks of NM front desk, MIA or
  DAM.  But if additional volunteers stepped forward who wanted to help
  with these transitions, it might make sense to approach things that
  way.

* Changing how Salsa and Debian LDAP interact.  This would involve
  figuring out what we want and working with the Salsa admins and DSA.

 
Closing Thoughts
================

A couple of issues have been brought up where people objected to the
project recommending Salsa.

I've considered the following issues:

* Some have objected that Salsa is not sufficiently free.  My
  understanding of the argument is that Salsa is running a community
  edition of Gitlab that is generally free, but contains non-DFSG free
  components that we would strip/do strip from the package.

* Others have objected that we don't run the Gitlab package on Salsa.
  I'll note that many core services do not run packaged code.

* Some have objected to recommending Salsa without improving the account
  transition experience.

I've considered these issues, and my reading of the discussion is that
the community is aware of them, but they do not rise to a level where
they would challenge recommending Salsa.

If you'd like to work on Salsa, including helping Salsa be more free,
reach out to the Salsa admins and see if they can use your help.

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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 (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Russ Allbery-2
Sean Whitton <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa mirror

Geert Stappers-2
On Sun, Sep 08, 2019 at 10:05:17PM -0700, Russ Allbery wrote:

> Sean Whitton <[hidden email]> 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 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Nikolaus Rath
In reply to this post by Sam Hartman-3
On Sep 08 2019, Sam Hartman <[hidden email]> 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.«

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa mirror

Ansgar Burchardt-5
In reply to this post by Geert Stappers-2
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.18901@.../

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Ansgar Burchardt-5
In reply to this post by Sam Hartman-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Sam Hartman-3
>>>>> "Ansgar" == Ansgar  <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Jonas Smedegaard-2
Quoting Sam Hartman (2019-09-09 19:49:25)

> >>>>> "Ansgar" == Ansgar  <[hidden email]> 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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Sam Hartman-3
>>>>> "Jonas" == Jonas Smedegaard <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

David Bremner
Sam Hartman <[hidden email]> writes:

>>>>>> "Jonas" == Jonas Smedegaard <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Sam Hartman-3
>>>>> "David" == David Bremner <[hidden email]> writes:

    David> Sam Hartman <[hidden email]> writes:
    >>>>>>> "Jonas" == Jonas Smedegaard <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Russ Allbery-2
Sam Hartman <[hidden email]> 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 ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Scott Kitterman-5
In reply to this post by Sam Hartman-3


On September 10, 2019 1:26:35 AM UTC, Sam Hartman <[hidden email]> wrote:

>>>>>> "David" == David Bremner <[hidden email]> writes:
>
>    David> Sam Hartman <[hidden email]> writes:
>    >>>>>>> "Jonas" == Jonas Smedegaard <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Sam Hartman-3
>>>>> "Scott" == Scott Kitterman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Jonas Smedegaard-2
In reply to this post by Russ Allbery-2
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

Scott Kitterman-5
In reply to this post by Sam Hartman-3


On September 10, 2019 10:12:39 AM UTC, Sam Hartman <[hidden email]> wrote:

>>>>>> "Scott" == Scott Kitterman <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 2: When to Salsa

David Bremner
In reply to this post by Russ Allbery-2
Russ Allbery <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>

signature.asc (849 bytes) Download Attachment
1234 ... 6