[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bikeshedding



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
<redacted>
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 brought up any problems yet, it shouldn't be too controversial
getting this DEP to a final stage.

2. Find some way to declare that a package is DEP14 compliant, maybe in
the control file, maybe just somewhere in the git repository, I don't
particularly care about the implementation, but since DEPs are opt-in,
it would be great to be able to track project-wide how many package
repositories are following it and to track momentum. It would need some
active promotion in the project.

3. The process above will be two-fold. It will help find edge cases that
can be fixed towards making that project policy, and it will get us some
good way in having that policy applied already. Additionally, when
something is already widely done it's easier to get applied in policy.
At that stage I think it could be very much uncontroversial and might
just have to go through a usual policy release cycle rather than
something as blunt as a GR.

That whole process might take a few months, or even as much as a whole
release cycle. I don't think it helps to push things too hard in Debian,
we tend to work better together when we make many small steps together
rather than having a few people try to make very hard pushes.

I know that I've conveniently left out the part about DDs having access
to all repositories above, but I think that's a detail that you might
have to be willing to give up on to make the rest of the above possible.
One might also argue that anyone already has access to change things by
submitting an MR. I know it's not quite the same thing, but sometimes
you have to make small sacrifices to a vision to drive the rest of it
forward.

-Jonathan

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


Reply to: