Marc Haber <mh+debian-de...@zugschlus.de> writes: > This is one more example of Debian lacking technical leadership, with > small groups taking technical decisions for the entire distribution > without even mentioning. Most of those technical decisions are sound and > supportable, but there are technical decisions that have impact on other > packages, and it is bad that those packages learn about it after > spending weeks or even months of spare time without knowing that this > work is going to go down the drain.
I just want to make a plug here that my hope when I first started working on Policy was that Policy could be used for this. That's part of why I spent a lot of time working on process and trying to identify gaps where major architectural decisions had gone undocumented in Policy. I have had almost no time and (to be honest the more directly relevant problem) emotional energy for Debian since at least last summer and honestly for some years before that, and I haven't been able to push that vision forward or even keep up with the existing work. Sean has been doing a fantastic job stepping into the gap I rather messily left, but Policy is in general underresourced, not so much on the Policy Editor side, but on the side of people doing the concrete work of documenting stuff. We need people to be proactively picking up technical decisions, figuring out a consensus, and writing up the results so that they can be merged into the Policy document if we want Policy to be a collection of these decisions for the project. I do think that would help, but I'm not sure if it's possible, at least following the current process. It's a fair bit of work and a lot of email back and forth. But I'm not sure what a better solution would be that would work with how Debian is structured. My experience is that the biggest obstacle is timeliness. We have to be able to document a technical decision within a reasonable amount of time or people will just go do things because they're blocked and need to move forward. When consensus is clear, I think we can mostly manage that, but often consensus is murky. My plan to address that had been to promptly refer such cases to the Technical Committee so that we could keep up momentum and make a real decision, but (a) I was never entirely sure the TC was on board with making that many decisions (the TC often decides to not decide), and (b) I only managed to do this once or twice and then stopped again so we never got into a rhythm. I pretty thoroughly dropped this ball along with a whole bunch of other balls, and I'm not sure my idea was even sound. Sean will certainly have his own opinions, and he's been doing most of the work recently and I would put more weight on his views than mine at this point. But maybe this will get people thinking about how they might be able to step into this decision-making gap and help out with it. I should probably say explicitly that my guess is that having a high-level process discussion about how Debian should do this in the abstract will probably not be helpful. We're good at having those discussions and then never acting on them. We probably instead need people to step in and start trying to resolve concrete technical issues and document the resolution, and then see if we can scale that process by having them identify the bottlenecks they encountered and the places they got stuck. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
