Where are the High Energy Low Conflict Projects
>>>>> "Brian" == Brian Gupta <brian.gupta@brandorr.com> writes:
Brian> On Wed, Mar 4, 2020 at 2:32 PM Sam Hartman Brian> Sam, Thank you for your work as DPL. I just want to add
Brian> one thought about your takeaway that maybe the project isn't
Brian> ready for a "high-energy DPL". I don't think we should
Brian> discourage folks who have "high-energy" and free time to work
Brian> on Debian (as DPL).
I didn't want to discourage anyone. My personal take away is that if
you are doing a bunch of high energy leading and facilitating, you need
to have a way to do what you say below.
Brian> Everyone working on Debian just needs to
Brian> always remember that there is common ground, and we need to
Brian> work around the areas of conflict. In other words "pick your
Brian> battles" (carefully), because we as the Debian family have
Brian> some strong common bonds, and it's a shame to break or damage
Brian> those bonds.
The challenge is that to do this work you need everyone else to buy into
that idea too.
It's not enough that you see the common bonds and work toward them.
The other people in the project need to see the same common bonds.
And that just doesn't happen. My take away is that since that doesn't
happen in practice, you need to have some way to help people see the
common bonds and to deescalate things when there is disagreement about
where the commonality is.
It's possible that someone else with a lot of energy will have a
different way of looking at this problem that allows them to make
progress.
That's great.
Brian> There is so much work that we could be doing
Brian> that we don't have time for, that aren't "battles". For
Brian> example, I don't know what happened to "Debian PPAs"? As I
Brian> understood, there was a broad consensus that this would be a
Brian> great thing, but no one had time to do the work. I'd love to
Brian> see a motivated DPL, come in and "make it happen". (It
Brian> doesn't need to be a DPL, but this is just one example.)
Ppa without battles?
See, there are people working on this problem today, but it's one of the
most embattled areas of the project. It's precisely the sort of area
where the interests of people doing the new work run up against
challenges from existing teams.
No, no one is working on the specific design that people came up with
for Bikeshed back in 2011 or whenever.
The world changes; new tools come along that can make solutions easier to
develop.
One of the things we've learned is that PPAs aren't really about being
able to dput to some repo that isn't quite Debian.
Even on Launchpad, if you use PPAs a lot, you quickly learn that isn't
the best approach for what you want to do.
You want to be able to commit to a repository somewhere and have Debian
packages pop out the other end.
Perhaps not everyone wants this, but it's a common enough goal that it
quickly interests anyone working on the problem.
So, on the Launchpad side, you end up either using their existing recipe
system, which does this for you. Alternatively you end up developing
your own tooling which somehow, on a regular basis prepares source
packages (almost certainly from a repository) and dputs them to a ppa.
On the Debian side. If you are willing to develop your own tooling,
then we've actually got most of the components. Between mini-buildd,
reprepro, custom instances of dak, aptly, pbuilder, and sbuild, we've
got a fairly good kit for people who don't mind writing their own
tooling.
I'm probably forgetting some of the tools there.
But if you want integration with repositories, especially if you want
integration without writing a bunch of your own tooling, then it turns
out we're also doing work. It looks a lot more like Salsa CA,
tag2upload, fastrack.debian.net, and related technologies than it does
the classic Bikeshed design. Why is that?
* Our requirements have changed. It's not good enough to just produce a
repository. We live in a world that values CI/CD. We want to run
tests against our repository--piuparts, autopkgtest, lintian and
friends.
* The rest of the world has developed technologies for doing this sort
of automation. It's a lot easier to code to .gitlab-ci.yml,
containers, docker, etc than it is to code to Dak, wana-buildd and
tossing around a bunch of source packages.
* Prototyping away from the core infrastructure allowed people to move
faster in part because they were not involved in the teams that had a
justified culture of being conservative.
And yet we're seeing significant friction with the last 10% of these
projects (you know that same last 10% that takes 90% of the time).
The Salsa admins are uncomfortable with Salsa CI and have vetoed
recommending it.
The Salsa Admins declined to engage with the project and explain the
problems, explaining that they valued doing more than communicating.
There was a lot of friction around tag2upload. Despite a rough start,
ftpmaster did explain their concerns. The authors of tag2upload were
not happy with that explanation; I got a lot of pressure to change the
ftpmaster delegation to remove the decision of whether to go forward
with tag2upload from ftpmaster.
(It doesn't matter for this discussion, but for the record, I think that
would have been the wrong thing for me to do at the time.)
Fasttrack.debian.net takes an entirely different approach, but it
targets one of the common use cases of PPAs.
There was conflict--or at least miscommunication--that kept fasttrack
from getting off the ground. When they reach a stability point where
they are ready to move from debian.net to tighter integration there's
going to be more conflict.
In conclusion, I don't think PPAs are battles.
I do hink there is significant conflict we'll need to face to get PPAs
or almost any evolution/change we want. That's just part of life.
Conflict doesn't have to be bad if you have the right tools and resources.
I think that by working on decision making tools, I started the ground
work to make this easier, whether it is PPAs or something else. I think
the work I did will be easier when we get to a point where it is time to
consider as a project whether to adopt one of these technologies.
I think the next step in that process is to figure out how to address
conflicts between teams and the project's needs: I think that's critical
for the PPA discussion and a number of others.
But perhaps your example was bad? Perhaps there's some other area
where we can just get it done without battles or conflict.
At one level, we're just getting it done every day, building all sorts
of new, neat things.
All you have to do is look at planet, ITP bugs, Misc Developer News, or
d-d-a to see all the amazing just get it done we do every week.
But as for big project-level things?
I'd like to think that treating people with respect and creating a
welcoming community would be an area where we can find common bonds,
where there aren't battles.
It is an area where we've found conflict though.
There may be such an area, but it's a little harder to find than your
message implies. It's perhaps a little harder to find than I was able
to accomplish in a year.
My bet remains on finding the tools to face conflict rather than on
finding the growth opportunities that don't involve conflict.
But the beauty of this process is that anyone with a plan can step
forward.
If someone sees the growth areas that aren't going to involve conflict,
this year sounds like a great time for them to be DPL.
Reply to: