Re: Bikeshedding

[Martin Michlmayr]

* Stefano Zacchiroli  [2019-03-31 09:39]:
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
> 
> DPL candidates: do you agree with this statement?

I'm late to reply to your question, so first of all I want to make a
meta comment.  I'm very happy that your statement (and a number of
other statements on debian-vote) haven't led to a flamewar or big
controversy.  To me, this shows that we should start to "think big"
more.  I think we're afraid to touch / discuss certain topics because
of fear of controversy where in fact the community as a whole has
become much more "mellow".

* Stefano Zacchiroli  [2019-03-31 12:07]:
> I know well where I'm placed on that trade-off: I'd take uniformity
> every day. I'm convinced Debian's inability to impose one way of
> maintaining packages is holding us back in our ability to implement (by
> the means of semi-automation) archive-wide changes and is also setting
> the bug for newcomers unreasonably high.

I tend to agree with this, and I also believe that Debian's "we accept
any way" had led to a lot of negative behaviour.

Git and GitHub have become the standard way of collaborating.  This
makes it easier to contribute to other projects.  I can tell the tale
of my own contribution.  I contribute to a project which is maintained
on Mercurial on Bitbucket.  The developer doesn't want to move to Git
because Mercurial is superior in his opinion.  And while that may be
correct, the fact is that Git has "won" and people know how to use Git
(and as someone who is a few years behind with certain technologies,
figuring out how Git works, how to modify a pull request, etc, is
*not* trivial).

Each time I try to contribute to this project, I run into some issue
with Mercurial and it's really frustrating for me.  I put up with it
because I *really* want to contribute.  But if this project wasn't so
important to me, I would have long given up.

When you learn how Git works and how to contribute on GitHub, you can
contribute to thousands of projects.  When I learn Mercurial and
Bitbuck, there's one single project I'm in interested in contributing
to.

So I think there's a lot of value in uniformity and I would agree that
Debian has chosen salsa and that packaging should be done there.  We
can also investigate mechanism to make salsa more attractive, e.g.
automatic CI of packaging.

-- 
Martin Michlmayr
https://www.cyrius.com/

Re: Bikeshedding

[Joerg Jaspert]

On 15361 March 1977, Sean Whitton wrote:


Yes.  The amount of effort that we would need to expend on implementing
zack's Statement seems out of proportion to the benefit, given that it
mandates no particular git workflow.


That's because you are all in way too deep in technical stuff. This is
-vote, not -devel.
Actually hashing out how it will work and look isn't what these threads
here are (should be) about.

dgit may even be (part of) the answer when one goes down to the
technical work and specs. It may also not be but something new that may
be based on concepts of it. Or not. I don't think that can, or should,
be defined here and now.

--
bye, Joerg

Re: Bikeshedding

[Sam Hartman]

>>>>> "Sean" == Sean Whitton  writes:

Sean> Hello,
Sean> On Wed 03 Apr 2019 at 12:51PM +01, Ian Jackson wrote:

>> Stefano Zacchiroli writes ("Re: Bikeshedding"):
>>> Statement: every Debian package must be maintained in Git on
>>> salsa and every Debian Developer with upload rights to the
>>> archive should have commit/push right to every packaging
>>> repository on salsa.
>>> 
>>> DPL candidates: do you agree with this statement?  If so, what
>>> will be your approach to make this a reality?
>> 
>> What git tree format do you mandate ?
>> 
>> Such an imprecation is of little use if "maintained in git on
>> salsa" means for some packages a giant packaging-only monorepo
>> (like used by some language-specific packaging teams), for some a
>> git-debrebase or git-dpm patches-applied tree, for some a merging
>> git branch for use with 1.0-with-diff, and for some a gbp pq
>> branch.

Sean> Yes.  The amount of effort that we would need to expend on
Sean> implementing zack's Statement seems out of proportion to the
Sean> benefit, given that it mandates no particular git workflow.

I disagree.
Would be happy to discuss on -devel after the election.
I've written Ian a detailed reply privately outlining my thoughts on
advantages of salsa even without specifying a git workflow.

Re: Bikeshedding

[Sean Whitton]

Hello,

On Wed 03 Apr 2019 at 12:51PM +01, Ian Jackson wrote:

> Stefano Zacchiroli writes ("Re: Bikeshedding"):
>> Statement: every Debian package must be maintained in Git on salsa and
>> every Debian Developer with upload rights to the archive should have
>> commit/push right to every packaging repository on salsa.
>>
>> DPL candidates: do you agree with this statement?
>> If so, what will be your approach to make this a reality?
>
> What git tree format do you mandate ?
>
> Such an imprecation is of little use if "maintained in git on salsa"
> means for some packages a giant packaging-only monorepo (like used by
> some language-specific packaging teams), for some a git-debrebase or
> git-dpm patches-applied tree, for some a merging git branch for use
> with 1.0-with-diff, and for some a gbp pq branch.

Yes.  The amount of effort that we would need to expend on implementing
zack's Statement seems out of proportion to the benefit, given that it
mandates no particular git workflow.

> Another answer to this is:
>
> The git server you are asking about already exists.  It is called
> `dgit.debian.org', not `salsa.debian.org'.
>
> It has the following properties:
>
> [...]
>
> So real answer is: everyone should consider `dgit push' and most
> people should be using it.  It should be recommended in policy.

What's so nice about this is that it doesn't require anyone to
fundamentally change their git workflows (with the exceptions of people
who have only debian/ in their packaging repo (and Ian has experimental
patches for that case), and team monorepos).

You can incorporate `dgit push-source` into existing workflows and
achieve what (I think) zack and others want.  See dgit-maint-gbp(1) etc.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Bikeshedding

[Ian Jackson]

Stefano Zacchiroli writes ("Re: Bikeshedding"):
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
> 
> DPL candidates: do you agree with this statement?
> If so, what will be your approach to make this a reality?

What git tree format do you mandate ?

Such an imprecation is of little use if "maintained in git on salsa"
means for some packages a giant packaging-only monorepo (like used by
some language-specific packaging teams), for some a git-debrebase or
git-dpm patches-applied tree, for some a merging git branch for use
with 1.0-with-diff, and for some a gbp pq branch.

> (I'm putting on the side, on purpose, the problem of different workflows
> that Joerg has highlighted. Not because it's not a real problem, but
> because I think it's a distraction to discussing/fixing the more
> substantial problem of access rights and package ownership.)

Another answer to this is:

The git server you are asking about already exists.  It is called
`dgit.debian.org', not `salsa.debian.org'.

It has the following properties:

 * Every package has a corresponding git view via `dgit clone';
   when the maintainer didn't dgit push, it is a .dsc import.

 * Everyone who uploads a package with `dgit push-source' etc.
   already makes it availablevia the obsolete source package archive.

 * When you push with `dgit push-source' you make your actual git
   branch available to `dgit clone'.

 * You can do that iff you can upload the same package to the obsolete
   source package archive.  Ie the access control is identical.

 * You can use gbp pq or git-debrebase or git-dpm, and your git branch
   is magically transformed into a uniform immediately-buildable view
   for everyone who consumes it via `dgit clone'.

So real answer is: everyone should consider `dgit push' and most
people should be using it.  It should be recommended in policy.

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: Bikeshedding

[Simon Richter]

Hi,

On 02.04.19 05:59, Louis-Philippe Véronneau wrote:

> Some teams might dislike it, but I guess those people will also dislike
> the idea of giving all DDs commit access on all packages VCS.

Y'all are still solving social problems with technical solutions here,
and it's a bad technical solution because it doesn't even solve the
technical problem.

From a technical point of view, this is a classic "top-of-the-foodchain"
problem, in which multiple platforms are contending to integrate all of
the others. Debian's solution to this problem was to define:

 - Debian source packages live at the top of the foodchain
 - Debian source packages look precisely like *this*

The format was designed around the realities of free software at that
time, so of course it looks rather limited to us now.

But if we are to change it, just slapping a thin layer on top will not
be sufficient, and the way we currently use version control is just
that, with lots of workarounds for things that aren't solved. Seriously,
pristine-tar is cool, but it's still a hack, and so is storing patches
in a VCS.

Our users' requirements have not changed that much that we can do away
with the "original upstream release plus integration patches" concept,
and any version control system we'd use should be able to replicate this
without tricky hacks. If that means extending Git with a bunch of new
object types, so be it.

The real problem is still a social one, though.

Debian Policy is a protocol, not a platform. It defines the interchange
format between a number of tools, not the tools themselves. It also does
not define how the tools are to be used.

Mandating that everyone uses a specific workflow is a marked deviation
from that, and it effectively throws out the Debian Policy in its
entirety and replaces it by "whatever the platform currently accepts".

To avoid this, we'd first need a new policy document that defines the
new interface in a way that allows a conforming implementation to remain
conforming until the document is changed. That is, if it references
other technology as normative, it does so with a version number, the
same way the Debian policy addresses differences in archiver versions.

Anything less than that requires all tools to come from a single source.
We have precedent for that, and it was a shitshow for precisely that reason.

   Simon



signature.asc
Description: OpenPGP digital signature

Re: Bikeshedding

[Jonathan Carter]

On 2019/04/02 09:53, Jonas Meurer wrote:
> Gitlab subgroups would solve this problem: Move every Debian package
> into the 'debian' group, but allow subgroups in there:
> 
> https://salsa.debian.org/debian/foo-team/libfoo

Yeah I was thinking along that too. It seems like subgroups under
/debian for all the debian teams would solve everyone's problems and
introduce no new ones, well, except for having longer VCS fields but
that seems like an easy trade-off :)

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bikeshedding

[Joerg Jaspert]

On 15360 March 1977, Jonas Meurer wrote:

Gitlab subgroups would solve this problem: Move every Debian package
into the 'debian' group, but allow subgroups in there:


Not in the current way they work, no. Though there is a gitlab upstream
bug about it.

--
bye, Joerg

Re: Bikeshedding

[Jonas Meurer]

Raphael Hertzog:
> Hi,
> 
> On Mon, 01 Apr 2019, Louis-Philippe Véronneau wrote:
>>> So if i had to decide how to implement this technique, i think the
>>> simplest thing would be to move every
>>> https://salsa.debian.org/foo-team/libfoo to
>>> https://salsa.debian.org/debian/libfoo and let the debian/ grouping
>>> handle the permissions.
>>>
>>> That still leaves all the rest of salsa for user-specific projects,
>>> upstream projects, etc., which might have different permissions.
>>>
>>> Is there some reason that wouldn't address the concern you're raising?
>>
>> It does sound like a good solution to me :D
> 
> Unfortunately, it also means that it's much harder grant access
> to all repositories of a team to a non-DD since you have to add
> the non-DD to all individual repositories instead of adding him to
> the group.
> 
> Because obviously we don't want to add non-DD to the Debian group.
> 
> And while team-wide membership might be reviewed from time to time, I
> doubt that package-specific membership will ever be reviewed by anyone.

Gitlab subgroups would solve this problem: Move every Debian package
into the 'debian' group, but allow subgroups in there:

https://salsa.debian.org/debian/foo-team/libfoo

Cheers
 jonas




signature.asc
Description: OpenPGP digital signature

Re: Bikeshedding

[Raphael Hertzog]

Hi,

On Mon, 01 Apr 2019, Louis-Philippe Véronneau wrote:
> > So if i had to decide how to implement this technique, i think the
> > simplest thing would be to move every
> > https://salsa.debian.org/foo-team/libfoo to
> > https://salsa.debian.org/debian/libfoo and let the debian/ grouping
> > handle the permissions.
> > 
> > That still leaves all the rest of salsa for user-specific projects,
> > upstream projects, etc., which might have different permissions.
> > 
> > Is there some reason that wouldn't address the concern you're raising?
> 
> It does sound like a good solution to me :D

Unfortunately, it also means that it's much harder grant access
to all repositories of a team to a non-DD since you have to add
the non-DD to all individual repositories instead of adding him to
the group.

Because obviously we don't want to add non-DD to the Debian group.

And while team-wide membership might be reviewed from time to time, I
doubt that package-specific membership will ever be reviewed by anyone.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/


signature.asc
Description: PGP signature

Re: Bikeshedding

[Louis-Philippe Véronneau]

On 19-04-01 18 h 18, Daniel Kahn Gillmor wrote:
> On Mon 2019-04-01 15:17:27 -0400, Louis-Philippe Véronneau wrote:
>> On 19-03-31 03 h 39, Stefano Zacchiroli wrote:
>>>
>>> Statement: every Debian package must be maintained in Git on salsa and
>>> every Debian Developer with upload rights to the archive should have
>>> commit/push right to every packaging repository on salsa.
>>
>> I'm curious to how this would be implemented on Salsa. As far as I know,
>> DDs get added to the 'Debian' group when their accounts are created and
>> already have commit access on all repositories in that group.
> 
> fwiw, i think team-specific repository groupings in salsa aren't
> particularly useful.  I prefer to work on teams whose packages are
> already in the debian/ namespace anyway.
> 
> So if i had to decide how to implement this technique, i think the
> simplest thing would be to move every
> https://salsa.debian.org/foo-team/libfoo to
> https://salsa.debian.org/debian/libfoo and let the debian/ grouping
> handle the permissions.
> 
> That still leaves all the rest of salsa for user-specific projects,
> upstream projects, etc., which might have different permissions.
> 
> Is there some reason that wouldn't address the concern you're raising?

It does sound like a good solution to me :D

Some teams might dislike it, but I guess those people will also dislike
the idea of giving all DDs commit access on all packages VCS.

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Re: Bikeshedding

[Daniel Kahn Gillmor]

On Mon 2019-04-01 15:17:27 -0400, Louis-Philippe Véronneau wrote:
> On 19-03-31 03 h 39, Stefano Zacchiroli wrote:
>> 
>> Statement: every Debian package must be maintained in Git on salsa and
>> every Debian Developer with upload rights to the archive should have
>> commit/push right to every packaging repository on salsa.
>
> I'm curious to how this would be implemented on Salsa. As far as I know,
> DDs get added to the 'Debian' group when their accounts are created and
> already have commit access on all repositories in that group.

fwiw, i think team-specific repository groupings in salsa aren't
particularly useful.  I prefer to work on teams whose packages are
already in the debian/ namespace anyway.

So if i had to decide how to implement this technique, i think the
simplest thing would be to move every
https://salsa.debian.org/foo-team/libfoo to
https://salsa.debian.org/debian/libfoo and let the debian/ grouping
handle the permissions.

That still leaves all the rest of salsa for user-specific projects,
upstream projects, etc., which might have different permissions.

Is there some reason that wouldn't address the concern you're raising?

--dkg


signature.asc
Description: PGP signature

Re: Bikeshedding

[Jonathan Carter]

Hi Jelmer

On 2019/04/01 11:00, Jelmer Vernooij wrote:
>> In general, I think so. I'm unsure about the first "must" though, I tend
>> to like that we're not so rigid and inflexible in our policies that we
>> can't cater for a few exceptions. For example, I could understand that
>> packagers of a VCS system would want to host their work in such a VCS,
>> for example...
>>
>> """
>> $ debcheckout -d bzr
>> type bzr
>> url  https://code.launchpad.net/~debian-bazaar/debian/sid/bzr/unstable
>> """
> 
> As the primary maintainer of Bazaar in Debian, I find it convenient to
> maintain the Bazaar packaging in Bazaar but I would be very happy to
> see all packages move to Git on salsa if that enables improved tooling
> across the archive.
> 
> The Vcs-* headers were a major improvement at the time they were
> introduced. At the time it was unclear what the dominant Vcs would be,
> but git has long since emerged as the dominant VCS for Debian
> packages.
> 
>> I'm not fundamentally against that being a "must", but we should just be
>> aware that there might be some use cases that we'll end up sacrificing
>> in order to make such a unification of source control hosting possible.
>
> What kind of use cases do you have in mind that wouldn't work with Git on 
> salsa?

I didn't spend much time thinking about such cases, but I think your
feedback is great because it's probably one of the most obvious cases
that I could think of, and if you're open to migrating that packaging to
git/salsa then I think that's already a great sign.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bikeshedding

[Louis-Philippe Véronneau]

On 19-03-31 03 h 39, Stefano Zacchiroli wrote:
> 
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.

I'm curious to how this would be implemented on Salsa. As far as I know,
DDs get added to the 'Debian' group when their accounts are created and
already have commit access on all repositories in that group.

This means we don't have commit access to packages hosted in team groups
(ex. the 'Web extensions packaging team' group) or on users' public
repositories.

Salsa can also be used to host upstream projects or code that isn't
packaged in Debian [1] and we don't want DDs to have commit access to
those. We can't just give super cow powers to all DDs on Salsa :p

Maybe someone more familiar with the Gitlab code could chime-in?

[1] https://wiki.debian.org/Salsa/FAQ#What_can_be_hosted_on_salsa

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   po...@debian.org / veronneau.org
  ⠈⠳⣄



signature.asc
Description: OpenPGP digital signature

Re: Bikeshedding

[Jelmer Vernooij]

On Sun, Mar 31, 2019 at 10:42:10AM +0200, Jonathan Carter wrote:
> On 2019/03/31 09:39, Stefano Zacchiroli wrote:
> > On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
> >> And less "I'm the package maintainer, this is my castle, go away" and
> >> more "This is how the majority does it, you follow, the benefit of it
> >> being one way, not a dozen different, outweight some personal
> >> preferences".
> > 
> > Let's cut to the chase of this.
> > 
> > Statement: every Debian package must be maintained in Git on salsa and
> > every Debian Developer with upload rights to the archive should have
> > commit/push right to every packaging repository on salsa.
> > 
> > DPL candidates: do you agree with this statement?
> 
> In general, I think so. I'm unsure about the first "must" though, I tend
> to like that we're not so rigid and inflexible in our policies that we
> can't cater for a few exceptions. For example, I could understand that
> packagers of a VCS system would want to host their work in such a VCS,
> for example...
> 
> """
> $ debcheckout -d bzr
> type  bzr
> url   https://code.launchpad.net/~debian-bazaar/debian/sid/bzr/unstable
> """

As the primary maintainer of Bazaar in Debian, I find it convenient to
maintain the Bazaar packaging in Bazaar but I would be very happy to
see all packages move to Git on salsa if that enables improved tooling
across the archive.

The Vcs-* headers were a major improvement at the time they were
introduced. At the time it was unclear what the dominant Vcs would be,
but git has long since emerged as the dominant VCS for Debian
packages.

> I'm not fundamentally against that being a "must", but we should just be
> aware that there might be some use cases that we'll end up sacrificing
> in order to make such a unification of source control hosting possible.
What kind of use cases do you have in mind that wouldn't work with Git on salsa?

Cheers,

Jelmer

Re: Bikeshedding

[Joerg Jaspert]

On 15359 March 1977, Russ Allbery wrote:


I agree with what you are saying here.  However, I am concerned that the
"push == automatic package upload" idea may be a step too far in some
cases.

I assume this would only happen if you push a signed tag.  I wouldn't want
every random commit I push to immediately be uploaded.


Oh yeah, definitely something with a signature need to be there for an
upload, in whichever way that upload happens. But thats one of the
technicalities that needs to be defined.

For example, for ftp-masters dak we have an own branch, deploy.
That one goes, driven by a cronscript, to all machines we run dak on.

But only if its signed by a key in a pre-defined list. And if the old
deployed stuff is an ancestor of the new one. So usual work happens in
master (or any feature branch, but then merged to master). And if one of
us is happy, we do a signed merge commit over to deploy. Some minutes
later its deployed.

--
bye, Joerg

Re: Bikeshedding

[Russ Allbery]

Roberto C. Sánchez  writes:
> On Sun, Mar 31, 2019 at 03:47:26PM -0700, Russ Allbery wrote:

>> One of the great things about Git is that there's really no such thing
>> as a "primary place of development" since every clone of the repository
>> is equal and it's nearly trivial to push a repository to multiple
>> remotes.  I suppose it could be a statement about process, but if we
>> fleshed out the idea some more, I suspect the most it would mean is
>> that maintainers have some responsibility to review PRs on Salsa (at
>> least to the level that they are responsible for looking at minor bug
>> reports in the BTS), which doesn't seem too unreasonable or onerous.

> I agree with what you are saying here.  However, I am concerned that the
> "push == automatic package upload" idea may be a step too far in some
> cases.

I assume this would only happen if you push a signed tag.  I wouldn't want
every random commit I push to immediately be uploaded.  Constantly
releasable master branch is a nice goal, but I can't say that I always
follow it 100% nor want to be forced to.  At that point, it just means
replacing some dput or dgit upload rune with some git push rune.  (Well,
and dedicating some tag space, but hopefully most people who are using Git
for packaging are already tagging.)

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

Re: Bikeshedding

[Roberto C . Sánchez]

On Sun, Mar 31, 2019 at 03:47:26PM -0700, Russ Allbery wrote:
> Roberto C. Sánchez  writes:
> 
> > I suppose requiring that they be pull-mirrored to Salsa might make
> > sense, but requiring that the primary place of development for Debian
> > packaging actually be in Salsa would present an obstacle for some of my
> > current packages.  Of course, that would mean that direct commits to the
> > Salsa project in such an instance would be problematic.
> 
> One of the great things about Git is that there's really no such thing as
> a "primary place of development" since every clone of the repository is
> equal and it's nearly trivial to push a repository to multiple remotes.  I
> suppose it could be a statement about process, but if we fleshed out the
> idea some more, I suspect the most it would mean is that maintainers have
> some responsibility to review PRs on Salsa (at least to the level that
> they are responsible for looking at minor bug reports in the BTS), which
> doesn't seem too unreasonable or onerous.
> 
I agree with what you are saying here.  However, I am concerned that the
"push == automatic package upload" idea may be a step too far in some
cases.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Bikeshedding

[Russ Allbery]

Roberto C. Sánchez  writes:

> I suppose requiring that they be pull-mirrored to Salsa might make
> sense, but requiring that the primary place of development for Debian
> packaging actually be in Salsa would present an obstacle for some of my
> current packages.  Of course, that would mean that direct commits to the
> Salsa project in such an instance would be problematic.

One of the great things about Git is that there's really no such thing as
a "primary place of development" since every clone of the repository is
equal and it's nearly trivial to push a repository to multiple remotes.  I
suppose it could be a statement about process, but if we fleshed out the
idea some more, I suspect the most it would mean is that maintainers have
some responsibility to review PRs on Salsa (at least to the level that
they are responsible for looking at minor bug reports in the BTS), which
doesn't seem too unreasonable or onerous.

We may want to do some work on the notification process based on some past
threads, unless that's already been sorted out.  I've been surprised a few
times by discovering PRs or merged diffs for packages under the Debian
free-for-all-area because I hadn't figured out the right way to subscribe
to email notifications for such things.  (The surprise was pleasant, to be
clear, and I have no objections to the process; I just accidentally
uploaded one package without those fixes because I didn't realize they
existed and only found out after attempting to push my local repository.)

I keep all of my work on my own Git server for a variety of reasons, but
also push all upstream work to GitHub and much Debian work to Salsa, and
would have no objections to pushing more Debian work to Salsa.  Git isn't
great at handling multiple remotes out of the box, but I wrote one bit of
software (that I'm pretty close to releasing) to help make that easier,
and I'm sure more could be done.  It's already 90% of the way to being
automated, at which point it's essentially trivial to replicate the Git
repository to one more place.

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

Re: Bikeshedding

[Sam Hartman]

> "Stefano" == Stefano Zacchiroli  writes:

Stefano> I respectfully disagree.  While it's not DPL's
Stefano> responsibility to implement (and maybe even drive) any
Stefano> specific technical/workflow change in the project, knowing
Stefano> what the DPL *thinks* about matters like this one is a
Stefano> fundamental element when deciding whom to vote for. That is
Stefano> certainly the case for my vote, but I suspect I'm not
Stefano> alone.

I'm hesitant to reply further.  However, I feel passionate about
respecting a diversity of opinions, and I'm concerned that the approach
you take above can lead the project away from respecting that diversity.
I'd like to explain why; I'm not trying to convince you to change your
mind, but I think this is important to understanding who I am and how I
think.



I hope people will vote for me because I can get stuff done, because I
care about avoiding unnecessary pain, and because they agree with my
thoughts about what areas we should focus on, and within the scope of
things that are DPL matters, because they agree with how I'd approach
them.

Assuming we agree a question is important to answer, and assuming we
agree that respecting the wishes of the project is important rather than
just forcing a decision on people, my personal beliefs take a back seat.
If I'm good at getting the project to that decision, I am quite likely a
better choice than someone who agrees more closely with your preferred
position but who isn't going to be effective at getting a decision and
respecting the project wishes.

going too far down the path of voting for people based on whether they
agree with you in areas that are not related to doing the job rather
than on whether they can do the job well can lead to divisive splits and
lack of diversity.  I'd prefer not to see that here.

--Sam


signature.asc
Description: PGP signature

Re: Bikeshedding

[Jonathan Carter]

On 2019/03/31 14:12, Stefano Zacchiroli wrote:
> I respectfully disagree.  While it's not DPL's responsibility to
> implement (and maybe even drive) any specific technical/workflow change
> in the project, knowing what the DPL *thinks* about matters like this
> one is a fundamental element when deciding whom to vote for. That is
> certainly the case for my vote, but I suspect I'm not alone.
> 
> As I see it, we decide which candidates to vote for based on two main
> elements: general vision and specific program for the upcoming DPL term.
> The question I've asked helps, I believe, in better understanding the
> technical/workflow vision for Debian of each candidate.

I tend to agree with that. Any question is fair game (within reasonable
limits of course, we don't want something dumb that goes against our CoC
and other values), it's up to the candidate how they want to answer it,
or if they even want to answer it at all.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bikeshedding

[Joerg Jaspert]

On 15358 March 1977, Stefano Zacchiroli wrote:


I'm not fundamentally against that being a "must", but we should just be
aware that there might be some use cases that we'll end up sacrificing
in order to make such a unification of source control hosting possible.

I agree with your analysis here: there is a clear trade-off between
flexibility in package maintenance practices and uniformity.


Yes.


I know well where I'm placed on that trade-off: I'd take uniformity
every day. I'm convinced Debian's inability to impose one way of
maintaining packages is holding us back in our ability to implement (by
the means of semi-automation) archive-wide changes and is also setting
the bug for newcomers unreasonably high.


I have been on the side of "we are fine, you need to learn stuff, go and
do it". I am still on that, but much moving to "It ought to be enough to
learn one way and style, not a trillion different little ones".

This is scary in many ways, starting with "Oh gosh, 1k other people have
access to MY packages?" and "Uh what, I am able to modify all them other
30k packages, why do you trust me with that" and is entirely different
to what we do now (mostly, collab maint exists, I know).


What I'm trying to determine with this sub-thread is which candidates,
if any, are willing to take a courageous stance on this matter and, if
so, how will they go about it.
For now, I'm understanding that you're more inclined than Ganneff to
take steps to uniform package maintenance practices, but at the same
time you want to retain some uniformity. So I'm still at loss at what
*concrete steps* you will take to increase uniformity throughout the
archive.


I know I've not given exact steps on how to go. Discussion, possible GR.
That is vague, I understand. It is too broad a thing to nicely formulate
something now and stick with it. But I wouldn't say I am not prepared to
take steps to uniform stuff. Though I can list some actionable items, if
that makes it feel more real.

First off it needs to get discussed at a proper venue, -devel or
-project, not -vote. It also needs to have talks with DSA and salsa
maintainers, as it will mean a noticable load increase for that service
which may mean a change of the way it is setup (split over machines).
If that all works out positively, it needs -policy involved, as that
document needs to have paragraphs talking about it.
And then it will end up a GR, presenting the worked out solution and
policy change to the developers and let them decide for or against it.

And working that out will take time. While its simple to state "It all
must be there", there are various exception to the rule to be
considered, as usual. And get into it...

--
bye, Joerg

Re: Bikeshedding

[Joerg Jaspert]

On 15358 March 1977, Stefano Zacchiroli wrote:


> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
Well, you took it from one of my mails, so it is mostly what I said, so
yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.

The big difference is the "must": I'm suggesting that no package should
be in the archive if it isn't Git-maintained on salsa in a repo writable
by all DDs.  So, let me insist: do you agree with that (specific version
of the) statement or not?


Yes.


I think the DPL can (try to) start and steer discussions the right way.
In the end something that drastic will need a project decision on it,
either by everyone just doing it (highly unlikely given our project) or
a GR.



I'm sorry, but there are so many hypothethicals here that I still have
no idea of what you, as a DPL, will do to make us closer to the net
goal. Will you start a discussion on this or not? Will you start a GR on
this or not?


More than what we have at -vote just now, I will start a discussion on
-devel, yes. GR or not depends on the way that discussion will run. It
may show more hurdles than I currently can think of and turn out to make
no sense now to run a GR on it. OTOH it can show lots of support and
mostly small issues that are simple to solve, then a GR is good to have
and I will start one.

--
bye, Joerg

Re: Bikeshedding

[Stefano Zacchiroli]

Hi Sam, thanks for your detailed follow-up, which fully answer my
question.

Just a minor point on this:

On Sun, Mar 31, 2019 at 07:52:46AM -0400, Sam Hartman wrote:
> I'd encourage you to think more carefully before asking DPL candidates
> to strongly state things that aren't the DPL's business in the future.

I respectfully disagree.  While it's not DPL's responsibility to
implement (and maybe even drive) any specific technical/workflow change
in the project, knowing what the DPL *thinks* about matters like this
one is a fundamental element when deciding whom to vote for. That is
certainly the case for my vote, but I suspect I'm not alone.

As I see it, we decide which candidates to vote for based on two main
elements: general vision and specific program for the upcoming DPL term.
The question I've asked helps, I believe, in better understanding the
technical/workflow vision for Debian of each candidate.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Bikeshedding

[Jonathan Carter]

Hi Zack

On 2019/03/31 12:07, Stefano Zacchiroli wrote:
> I know well where I'm placed on that trade-off: I'd take uniformity
> every day. I'm convinced Debian's inability to impose one way of
> maintaining packages is holding us back in our ability to implement (by
> the means of semi-automation) archive-wide changes and is also setting
> the bug for newcomers unreasonably high.
> 
> What I'm trying to determine with this sub-thread is which candidates,
> if any, are willing to take a courageous stance on this matter and, if
> so, how will they go about it.
> 
> For now, I'm understanding that you're more inclined than Ganneff to
> take steps to uniform package maintenance practices, but at the same
> time you want to retain some uniformity. So I'm still at loss at what
> *concrete steps* you will take to increase uniformity throughout the
> archive.

I'm assuming that you made a small mistake in the paragraph above and
that you meant s/retain some uniformity/retain some flexibility/.

In terms of specifically committing to actions to drive the original
statement that you posted, I believe that would be somewhat
irresponsible. As DPL I don't want to impose agendas that doesn't yet
have a form of wide-spread consensus. This doesn't mean that everyone
has to agree, it also doesn't mean that we have to discuss it for weeks,
but as DPL, it would be my goal to enact on the wishes of the project
members, and I accept that with any progress there will be some people
that will be unhappy about some things some times. As a project, we all
have to learn that we won't always get our way and that that's ok. And
for those who do have objections to a process, I want to formally log
those so that they're acknowledged and so that we can plan mitigations
for those scenarios and ultimately, avoid looping through the same
conversations over and over on debian-devel without getting anywhere. I
know it may seem that I'm steering a bit off-topic here, but I'm not, my
ways of working as DPL is an important consideration in answering this
question.

So, in terms of your original two questions, I do feel that I originally
answered them sufficiently: my stance is basically that I'm not in a
position right now to commit to a solid approach in making that
statement a reality until I have the backing of our project members to
drive such a project.

And I believe it's reasonable to hear out all the concerns. Just today
on #debian-devel (I've redacted the log just to keep it on point, times
are UTC+2):

"""
10:25 < jcristau> eww @ "every DD gets to push to every packaging repo"
10:26 < dwfreed> -1

10:42 < jcristau> i don't trust a thousand people with my packages, and
i don't trust myself with everybody else's packages
11:03 < Ganneff> jcristau: scary thought, yes, but i think its the long
term goal to make us better. and to get large scale changes easier.
also, having such rights dont mean just going around randomly and
abusing them.
11:03 < jcristau> well if i don't need certain permissions i'd rather
not have them
11:04 < Ganneff> i can also imagine a way where one does not have it all
the time, but it is *easy* to get. thats "impementation detail".
11:05 < Ganneff> "found a bug in tons of packages, all point to the same
one line fix? be able to commit it everywhere and have it uploaded
WITHOUT weeks of patches send and ignored and whatnot"
11:09 < jcristau> a bug in tons of packages with the same one line fix
sounds like opportunity for rethinking how it's done to not need tons of
patches :)
"""

I'm not going to unpack every detail about the discussion above, but
there are certainly details to work through and consider. Having a
system where every DD has access to every git repository, and if we get
to a point where uploading a package becomes as simple as pushing to the
git repository, it can be a severe shock to a bunch of workflows and it
will surely need some cultural changes too.

So, having said all the above, I'm not against the idea :)

Also, the question you asked in this mail is a bit different than the
ones in your original. So, in terms of concrete steps to making this a
reality, I'll put together a small roadmap right here. Obviously it's
slightly hypothetical, we don't know who will be DPL yet, and you're
kind of putting me on the spot here, so with some more time to think
about it and having more feedback, details could obviously change, but
with all of that disclaimer out of the way, I think it might answer your
question:

1. DEP14 is still in draft, which is actually great because it means it
can be updated to reflect that we now use salsa.debian.org as our
standard version control repository location. I wouldn't drive those
changes unilaterally, I would make contact with Raphael who's marked as
the driver of that DEP, and ask if we can work together in making those
modifications and getting it to a final release state. I think that,
since many packages are already using a DEP14 layout and because it
hasn't 

Re: Bikeshedding

[Sam Hartman]

> "Stefano" == Stefano Zacchiroli  writes:

Stefano> On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
>> And less "I'm the package maintainer, this is my castle, go away"
>> and more "This is how the majority does it, you follow, the
>> benefit of it being one way, not a dozen different, outweight
>> some personal preferences".

Stefano> Let's cut to the chase of this.

Stefano> Statement: every Debian package must be maintained in Git
Stefano> on salsa and every Debian Developer with upload rights to
Stefano> the archive should have commit/push right to every
Stefano> packaging repository on salsa.

So, with my DPL candidate hat on, I absolutely agree that this is an important
discussion to have.  I think we've reached a point where we've discussed
enough of the issues that we can have a discussion around forming
consensus rather than a researchy discussion where we explore the
issues.

I plan on approaching this in a couple of phases.
I plan to reach out to salsa maintainers, DSA, and probably ftpmaster
(although it's not clear they have a direct need to be involved, it
seems important) and make sure I am framing the discussion well.

Then I'd start a discussion on -project or -devel; not 100% sure which
and try and guide that discussion to a consensus.
If one emerges, I'd call it.  It wouldn't be important to get to
implementation details, just a consensus on the overall direction (and
things like must vs should).
If that consensus can be called, I'd delegate the decision of coming up
with an implementation approach.  (Well, if the consensus is no we don't
want to do that, it might not require a delegation to implement the
status quo:-)


If we aren't going to reach a consensus I'd look into either proposing a
GR with multiple ballot options or delegating the decision to the TC.
TC vs GR would depend on whether the open issues seem like technical
ones clearly within the scope of the TC or non-technical policy.

I think asking the DPL candidates to state a position on this issue is
harmful.  I think I could be more effective in driving this discussion
if I don't state a personal opinion.  It's not the DPL's job to decide
issues like this: it's the DPL's job to lead the project in making these
decision.  I'd encourage you to think more carefully before asking DPL
candidates to strongly state things that aren't the DPL's business in
the future.

That said, I'll answer, because the question having been asked, being
equivocal is perhaps more harmful.
I want to stress that my goal would be to come to a decision, not to
implement my will.

I agree with the above statement.  Essential to my agreement is that you
say DDs should have push access not must have push access.  I'd say that
an MR on salsa must be a reasonable way to contribute a patch, and that
DDs should have push access.  During the discussion, we might decide
that DDs must have push access, but there are more open issues there
including the one Roberto brought up.

--Sam


signature.asc
Description: PGP signature

Re: Bikeshedding

[Roberto C . Sánchez]

On Sun, Mar 31, 2019 at 10:42:10AM +0200, Jonathan Carter wrote:
> On 2019/03/31 09:39, Stefano Zacchiroli wrote:
> > 
> > Statement: every Debian package must be maintained in Git on salsa and
> > every Debian Developer with upload rights to the archive should have
> > commit/push right to every packaging repository on salsa.
> > 
> > DPL candidates: do you agree with this statement?
> 
> In general, I think so. I'm unsure about the first "must" though, I tend
> to like that we're not so rigid and inflexible in our policies that we
> can't cater for a few exceptions. For example, I could understand that
> packagers of a VCS system would want to host their work in such a VCS,
> for example...
> 
[SNIP]
> 
> I'm not fundamentally against that being a "must", but we should just be
> aware that there might be some use cases that we'll end up sacrificing
> in order to make such a unification of source control hosting possible.
> 
Some of the packages I am involved in maintaining for Debian live in
upstream Git repositories (and I do my associated packaging work and
build packages for upload from those same repositories).

I suppose requiring that they be pull-mirrored to Salsa might make
sense, but requiring that the primary place of development for Debian
packaging actually be in Salsa would present an obstacle for some of my
current packages.  Of course, that would mean that direct commits to the
Salsa project in such an instance would be problematic.

It would not surprise me if such a requirement were to cause some
upstream developers to give up on being involved in the Debian packaging
of their projects rather than deal with the hassle.  Perhaps other
interested parties not involved with upstream might come along and
maintain these packages.  In some cases that may be no great loss, but
there are enough upstream developers who are frustrated by Debian
policies it would seem to be better to be more accommodating, not less.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: Bikeshedding

[Stefano Zacchiroli]

On Sun, Mar 31, 2019 at 10:42:10AM +0200, Jonathan Carter wrote:
> In general, I think so. I'm unsure about the first "must" though, I tend
> to like that we're not so rigid and inflexible in our policies that we
> can't cater for a few exceptions. For example, I could understand that
> packagers of a VCS system would want to host their work in such a VCS,
> for example...
[...]
> I'm not fundamentally against that being a "must", but we should just be
> aware that there might be some use cases that we'll end up sacrificing
> in order to make such a unification of source control hosting possible.

I agree with your analysis here: there is a clear trade-off between
flexibility in package maintenance practices and uniformity.

I know well where I'm placed on that trade-off: I'd take uniformity
every day. I'm convinced Debian's inability to impose one way of
maintaining packages is holding us back in our ability to implement (by
the means of semi-automation) archive-wide changes and is also setting
the bug for newcomers unreasonably high.

What I'm trying to determine with this sub-thread is which candidates,
if any, are willing to take a courageous stance on this matter and, if
so, how will they go about it.

For now, I'm understanding that you're more inclined than Ganneff to
take steps to uniform package maintenance practices, but at the same
time you want to retain some uniformity. So I'm still at loss at what
*concrete steps* you will take to increase uniformity throughout the
archive.

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Bikeshedding

[Stefano Zacchiroli]

On Sun, Mar 31, 2019 at 10:23:29AM +0200, Joerg Jaspert wrote:
> On 15358 March 1977, Stefano Zacchiroli wrote:
> > Statement: every Debian package must be maintained in Git on salsa and
> > every Debian Developer with upload rights to the archive should have
> > commit/push right to every packaging repository on salsa.
> 
> Well, you took it from one of my mails, so it is mostly what I said, so
> yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.

The big difference is the "must": I'm suggesting that no package should
be in the archive if it isn't Git-maintained on salsa in a repo writable
by all DDs.  So, let me insist: do you agree with that (specific version
of the) statement or not?

> I think the DPL can (try to) start and steer discussions the right way.
> In the end something that drastic will need a project decision on it,
> either by everyone just doing it (highly unlikely given our project) or
> a GR.

I'm sorry, but there are so many hypothethicals here that I still have
no idea of what you, as a DPL, will do to make us closer to the net
goal. Will you start a discussion on this or not? Will you start a GR on
this or not?

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Bikeshedding

[Jonathan Carter]

Hi Zack

On 2019/03/31 09:39, Stefano Zacchiroli wrote:
> On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
>> And less "I'm the package maintainer, this is my castle, go away" and
>> more "This is how the majority does it, you follow, the benefit of it
>> being one way, not a dozen different, outweight some personal
>> preferences".
> 
> Let's cut to the chase of this.
> 
> Statement: every Debian package must be maintained in Git on salsa and
> every Debian Developer with upload rights to the archive should have
> commit/push right to every packaging repository on salsa.
> 
> DPL candidates: do you agree with this statement?

In general, I think so. I'm unsure about the first "must" though, I tend
to like that we're not so rigid and inflexible in our policies that we
can't cater for a few exceptions. For example, I could understand that
packagers of a VCS system would want to host their work in such a VCS,
for example...

"""
$ debcheckout -d bzr
typebzr
url https://code.launchpad.net/~debian-bazaar/debian/sid/bzr/unstable
"""

Having said that, all the other major VCS systems already seem to be
either in salsa or in another git repository.

I'm not fundamentally against that being a "must", but we should just be
aware that there might be some use cases that we'll end up sacrificing
in order to make such a unification of source control hosting possible.

> If so, what will be your approach to make this a reality?

Well, if we'd want to enforce this, it would ultimately have to get into
policy somehow.

DEP14 (https://dep-team.pages.debian.net/deps/dep14/) predates salsa so
doesn't mention it, but that already had quite a lot of thought go into
it, and if that would be expanded to include bits about salsa hosting,
then you get what you mentioned above plus the workflow parts from below
(which are already used on salsa by a number of projects).

I also do think that "every Debian package /should/ be maintained in Git
on salsa" would be easier to accept project-wide than "every Debian
package /must/ be maintained in Git on salsa". I would perhaps ask the
proposer of such a statement to consider whether it might be worth while
taking the smaller step first, and then in the future revisit it to
change it to the stronger statement when the community at large have had
more time to adapt.

> (I'm putting on the side, on purpose, the problem of different workflows
> that Joerg has highlighted. Not because it's not a real problem, but
> because I think it's a distraction to discussing/fixing the more
> substantial problem of access rights and package ownership.)

ack.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bikeshedding

[Joerg Jaspert]

On 15358 March 1977, Stefano Zacchiroli wrote:


And less "I'm the package maintainer, this is my castle, go away" and
more "This is how the majority does it, you follow, the benefit of it
being one way, not a dozen different, outweight some personal
preferences".

Let's cut to the chase of this.



Statement: every Debian package must be maintained in Git on salsa and
every Debian Developer with upload rights to the archive should have
commit/push right to every packaging repository on salsa.



DPL candidates: do you agree with this statement?


Well, you took it from one of my mails, so it is mostly what I said, so
yeah. Concepts like LowThresholdNMU are nice, but the wrong way around.


If so, what will be your approach to make this a reality?


I think the DPL can (try to) start and steer discussions the right way.
In the end something that drastic will need a project decision on it,
either by everyone just doing it (highly unlikely given our project) or
a GR.

It's also possible that something this big needs more resources thrown
at (like scaling salsa or the ci around it), in that a DPL can obviously
use the assets available in the best possible way. Be that with sprints,
throwing hardware at it, whatever.

--
bye, Joerg

Re: Bikeshedding

[Stefano Zacchiroli]

On Sat, Mar 30, 2019 at 11:38:43PM +0100, Joerg Jaspert wrote:
> And less "I'm the package maintainer, this is my castle, go away" and
> more "This is how the majority does it, you follow, the benefit of it
> being one way, not a dozen different, outweight some personal
> preferences".

Let's cut to the chase of this.

Statement: every Debian package must be maintained in Git on salsa and
every Debian Developer with upload rights to the archive should have
commit/push right to every packaging repository on salsa.

DPL candidates: do you agree with this statement?
If so, what will be your approach to make this a reality?

(I'm putting on the side, on purpose, the problem of different workflows
that Joerg has highlighted. Not because it's not a real problem, but
because I think it's a distraction to discussing/fixing the more
substantial problem of access rights and package ownership.)

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Bikeshedding

[Joerg Jaspert]

On 15356 March 1977, Anthony Towns wrote:


Did anything happen to that? (Or perhaps, that's better phrased as:
did anything cause it to stall other than ENOTIME?) I'm guessing not?
[1]


ENOTIME. And ENOONEELSEINTERESTEDINCODING.


Unless the things that caused it to stall were legal concerns or a need
for separated hosting/mirror infrastructure, that might not be something
the DPL can make much better. Perhaps if Joerg quits DAM due to being DPL
and ftpmaster due to having to re-delegate it, the combination of those
might leave him with more time for dak development despite also being
DPL?


Thats an interesting take on it.


As a result, I kind of disagree with Joerg's statement in his platform
that "As the DPL is not the lead of actual technical development, it is
not for the DPL to find technical solutions for the challenges we face"
-- I think spending time making a huge technical improvement for the
project, like bikesheds, would be the best way to demonstrate leadership
(whether done by the DPL or not), and honestly I'd be more impressed
seeing a DPL do that compared to a DPL spending a year's time focussed
on mediating disputes and PR. Obviously, YMMV.


I stay with my statement. The DPL is not the lead of actual technical
development. But that does not exclude a DPL from being the lead of
actual technical development - by the virtue of the person thats DPL at
the time also being in a team where that development happens.

Maybe obscure, but I think of that as two hats.


 * Debian is made up of a lot of policies, and rules; and often has a
   lot of arguments and hurt feelings. Debian's also made up of a lot of
   genius (and admittedly not so genius) code and technical achievements.
   Usually, DPLs seem to spend all their time dealing with policies and
   conflicts, rather than technical stuff.



   Do you think it makes sense to put some real effort in moving the
   balance the other way? If so, how?


I think we do have a good amount of policies and sometimes too much of a
fear to just go and break one if its sensible. Also, everyone likes to
define sensible different.

And yeah, we discuss things to death way too often.

Unsure how to get that pendulum moving into the other direction, and for
how far.


 * Do you think bikesheds are actually a bad idea, or know of any other
   particular roadblocks in the way of making bikesheds happen? If Joerg
   is too busy to do it, do you have any ideas on how others could make it
   happen (within Debian, not as a derivative of some sort)? If elected,
   would you help remove those roadblocks?


I think they are a pretty nice one and would still love to see them.

Others: The hard way, join the ftp team, work your way up until you have
the powers to just go and do em. Takes years.

Better: First off it needs code finished. There is a branch, bikeshed, I
just pushed it to salsa. That does need to get a recent master $magiced
(merge, rebase, whatever) in, then cleaned up and finished off. Anyone
who understands python can start working on that. A bit of understanding
the archive will help, sure, but first off, its python code.
That will take a while before it does need an ftpmaster. Any of us,
though I am happy to be the contact and think Ansgar won't run away
screaming either.


 * As far as technical projects go, is there anything you think would
   have more of an impact than having bikesheds available to every DD?
   (Or, if you think bikesheds are a bad idea, what's the biggest positive
   impact technical project, in your opinion?)


Salsa as the one and only platform of hosting our packaging, with only
ONE way of doing so in git, not half a dozen, followed by "git push ==
upload" I mentioned elsewhere.

And less "I'm the package maintainer, this is my castle, go away" and
more "This is how the majority does it, you follow, the benefit of it
being one way, not a dozen different, outweight some personal
preferences".

--
bye, Joerg

Re: Bikeshedding

[Jonathan Carter]

Hi aj

On 2019/03/29 06:32, Anthony Towns wrote:
> FWIW, I think giving every DD their own bikeshed that they can paint
> whatever colour they like would be by far the biggest improvement possible
> in Debian today. [2]
> 
> As a result, I kind of disagree with Joerg's statement in his platform
> that "As the DPL is not the lead of actual technical development, it is
> not for the DPL to find technical solutions for the challenges we face"
> -- I think spending time making a huge technical improvement for the
> project, like bikesheds, would be the best way to demonstrate leadership
> (whether done by the DPL or not), and honestly I'd be more impressed
> seeing a DPL do that compared to a DPL spending a year's time focussed
> on mediating disputes and PR. Obviously, YMMV.

Well, there are two sides to that coin.

In the literal sense I tend to agree with Joerg on that one, the DPL
shouldn't lead actual technical development.

Having said that, the DPL does tend to have a lot of attention that can
be used to bring focus and limelight to a project, and I think in that
way a DPL could use that to help keep momentum and focus for a
project-wide goal. However, I think such goals need to go through our
usual processes. If I were to become DPL, I would very likely make use
of the DEP process and get an approved DEP for something like bikesheds
before driving that. I don't think it's the DPLs place to just chase the
ideas that are cool to them (although, of course it does help if that's
aligned with the project in terms of DPL enthusiasm), but it's important
that the DPL spends energy where the project needs it with the backing
of the members in the project.

>  * Debian is made up of a lot of policies, and rules; and often has a
>lot of arguments and hurt feelings. Debian's also made up of a lot of
>genius (and admittedly not so genius) code and technical achievements.
>Usually, DPLs seem to spend all their time dealing with policies and
>conflicts, rather than technical stuff.

Heh, you've intermingled quite a few things there. I'll reduce it to
this: policies and rules are our friends, they help keep things simple
and help move us forward. Our rules aren't sacred text carved out on
stone tablets either, they exist to serve our project. When they fail in
doing so, we should look at enhancing them.

I agree that the DPL shouldn't only focus on minutia, and have also
addressed that in my platform. However, it has been unfortunate that
some of the previous DPLs had little choice in the matter due to
circumstances during their terms.

>  * Do you think bikesheds are actually a bad idea, or know of any other
>particular roadblocks in the way of making bikesheds happen? If Joerg
>is too busy to do it, do you have any ideas on how others could make it
>happen (within Debian, not as a derivative of some sort)? If elected,
>would you help remove those roadblocks?

I don't think it's a bad idea, although personally I'm not fond of the
nomenclature. As DPL I would certainly support it. Sprints seem to have
proven themselves in Debian to get blocks of work that's otherwise
difficult to co-ordinate done. As DPL I would be happy to approve
funding for such sprints, but even then you'll need the people who are
willing to do this work to begin with.

>  * As far as technical projects go, is there anything you think would
>have more of an impact than having bikesheds available to every DD?

There are probably too many to mention. As I see it, bikesheds solve a
few very specific problems, but I can't see a reason to think of it as
the most important project in Debian right now.

Having said that, I think people who care about it should keep the
conversation going. Schedule IRC meetings, schedule BoFs at DebConf
(CfP's are open now btw), make notes about those in etherpads and put
together a kick-ass DEP that everyone can get behind. There are plenty
of good ideas that die quietly in mailing list threads, if an idea is
important and people care about it, they will get behind you if you put
the energy in to it.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Bikeshedding

[Sam Hartman]

> "Anthony" == Anthony Towns  writes:

Anthony> Hi *, "More of a comment than a question..."
>> I am disappointed when people leave bitter and disheartened.

Anthony> That's still kind-of better than if they're bitter and
Anthony> disheartened, but won't go away though!

Yeah.
I actually think a huge huge improvement in Debian in the last five
years or so is that culturally we've encouraged people to analyze
whether they are happy and stop if they are not.

More often than I'd like they go away bitter and that's unfortunate both
because it's not great for the people departing and because it tends to
spread bad blood around.

And when it's a sign of something where we could have fixed the problem
and kept people happy, well, it makes me want to fix the problems.

Anthony> But we've got lots of new problems where that doesn't work
Anthony> so well: people who want to quickly develop stuff with
Anthony> random libraries vs people who don't want to run "curl
Anthony> http://... | sudo bash"; people who want to make big
Anthony> changes to everything in the distro vs people who don't
Anthony> want their packages to get broken due to the latest fad,
Anthony> etc.

Anthony> A few years ago, we had a plan that (IMO) would have made a
Anthony> big improvement there:

Anthony>   https://lists.debian.org/debian-devel/2013/05/msg00131.html
Anthony> https://lists.debian.org/debian-devel/2015/09/msg00340.html
Anthony> https://lists.debian.org/debian-devel/2015/09/msg00404.html

With respect, I don't actually think bikeshedding helps that much with
the sort of situations where people want the project to choose one
thing.
It allows people to try things out, it allows people to have technical
data for their experiments more easily.

However, ultimately, they still want to get stuff into Debian.
And ultimately, they don't want to have to fork huge chunks of Debian to
do the stuff they want.

And I don't think that it solves the real emotional issues I'm seeing
more and more in the project.  I have high confidence that I'm not alone
in feeling hurt when things I value aren't even considered by others.
Having my own little playground doesn't really make me feel much better
when my needs for respect and community are not met.
A sufficiently poorly received email can drive away my motivation for a
day and can significantly reduce my willingness to work on some aspect
of Debian.
I am perhaps less thick-skinned than average, but I know it's a real
issue because I hear others talking about it and because I see the same
signs of disengagement I find in myself when I see others receive
something that is hard to take.

So, I think bikeshedding is valuable, and can help some, but I don't
think it's nearly as valuable as you do.


The good news is that we actually have a lot of the infrastructure you
need for this.  As an example, the salsa CI team has a pipeline that
builds packages to run several of our quality tests against.
I know many people who have independently adopted similar work flows and
attached them to repositories to give something very similar to what
you're talking about.

Interestingly, when the bikeshedding project first came out, I found it
really exciting and thought it was going to be a game changer.  These
days though, reprepro, mini-buildd, aptly and others are strong enough
tools that when I've had something I wanted to share enough to actually
make it available, the infrastructure just hasn't been a problem.
I realize that it still is an issue for newcomers, and that it still is
valuable, but I think that tool improvements have taken off some of the
pressure.  The good news of course being that we can use those tool
improvements in actually deploying something.

That's especially true if we're willing to be incremental.  Perhaps the
first version only builds for amd64 and one or two other architectures.
Perhaps the first version has adequate but not great key management for
release keys.  Perhaps the first version uses tools other than dak and
buildd that aren't quite as robust.
I'm not at all sure that would be a problem.


Anthony> As a result, I kind of disagree with Joerg's statement in
Anthony> his platform that "As the DPL is not the lead of actual
Anthony> technical development, it is not for the DPL to find
Anthony> technical solutions for the challenges we face" -- I think
Anthony> spending time making a huge technical improvement for the
Anthony> project, like bikesheds, would be the best way to
Anthony> demonstrate leadership (whether done by the DPL or not),
Anthony> and honestly I'd be more impressed seeing a DPL do that
Anthony> compared to a DPL spending a year's time focussed on
Anthony> mediating disputes and PR. Obviously, YMMV.

I agree that the DPL has a job in leading technical work.  I think the
DPL can work to figure out how things are getting blocked and help
remove blocks.  The