>>>>> "Brian" == Brian Gupta <brian.gu...@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.