>>>>> "Anthony" == Anthony Towns <aj@erisian.com.au> 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 DPL has a lot of tools to do this. The DPL can lead
discussions. When something is not going to get a project wide
consensus, the DPL can delegate actually making the decision.
Alternatively, when it's the right thing, the DPL can ask the TC or
project as a whole to vote to actually make a decision. When people are
getting in the way the DPL can work to resolve problems or re-delegate
so that the right set of people are working on the problem.
Also, to be clear, my hope is to do better than spending a year
mediating disputes. My hope is to improve the quality of dispute
resolution we have by helping the people who come to the DPL for dispute
resolution improve their approach to disputes. My hope is to also set
up a better structure to handle dispute resolution so it's not just the
DPL handling that.
Anthony> Anyway, some explicit questions if that's any help:
Anthony> * Debian is made up of a lot of policies, and rules; and
Anthony> often has a lot of arguments and hurt feelings. Debian's
Anthony> also made up of a lot of genius (and admittedly not so
Anthony> genius) code and technical achievements. Usually, DPLs
Anthony> seem to spend all their time dealing with policies and
Anthony> conflicts, rather than technical stuff.
Anthony> Do you think it makes sense to put some real effort in
Anthony> moving the balance the other way? If so, how?
I think it makes a lot of sense to get the DPL doing more to help
unblock technical work and lead technical discussion. I think the DPL
should not lead by preferring a specific solution, but rather by
bringing attention to problems that need solving and helping drive the
discussion and decision and work facilitation process.
That said, I think conflict resolution is really important in keeping a
community strong and healthy.
I don't think having the DPL write code is often the best choice. I do
think it's critical that the DPL understand the technology and be able
to talk and think coherently about the code involved, but actually
spending a year hacking doesn't make that much sense to me for the DPL.
Anthony> * Do you think bikesheds are actually a bad idea, or know
Anthony> of any other particular roadblocks in the way of making
Anthony> bikesheds happen? If Joerg is too busy to do it, do you
Anthony> have any ideas on how others could make it happen (within
Anthony> Debian, not as a derivative of some sort)? If elected,
Anthony> would you help remove those roadblocks?
I don't think bikesheds are a critical priority. I think things that
limit our workflow when contributing to the big debian are higher
priorities. I'm much more interested in helping move the git source
package and better workflows involving salsa projects forward, because I
think they will make Debian easier to contribute to and reduce
cross-team and intra-team frustrations as we do our work.
I'd be happy to help bikesheds along by working with someone who wanted
to drive that work and lending DPL help/delegation where needed.
Would you be interested in doing a deep dive into figuring out where
they are now and trying to build a plan to get from where we are to
something that works?
Anthony> [0] I think the idea of mandating everyone use "dh" is a
Anthony> bit weird here; if we made rules like that, then everyone
Anthony> would have been forced to use debhelper or debmake and we
Anthony> would have had to have a big policy debate before rolling
Anthony> it out, rather than "just doing it"... I think that's the
Anthony> sort of setup that would have prevented "dh" ever getting
Anthony> written in the first place, and I don't think it's far off
Anthony> from saying it's the sort of policy that caused dh's
Anthony> inventor to move on from Debian...
Anthony> [1]
Anthony> https://lists.debian.org/debian-dak/2018/04/msg00039.html
Anthony> https://lists.debian.org/debian-dak/2018/04/msg00040.html
Anthony> [2] For example, want to do a big change but are stymied
Anthony> because some maintainer isn't using dh and doesn't want to
Anthony> manually update their package? Fork the entire archive into
Anthony> your own bikeshed and just do it. After you've fixed the
Anthony> bugs, it's a lot easier to say "here's a working solution,
Anthony> please consider the patches", and if there's still
Anthony> opposition, a lot easier to have a useful debate on a list
Anthony> or with the tech ctte about which is the best approach when
Anthony> they're both implemented. And in the meantime anyone who
Anthony> cares can just use the bikeshed, so they don't have to
Anthony> wait.
Attachment:
signature.asc
Description: PGP signature