>>>>> "Luca" == Luca Boccassi <bl...@debian.org> writes:
>> - After the merits and problems of the proposed new projects are >> discussed, the release team decides which projects are accepted >> for the next release. (I specifically do not mention what rules >> the release team should follow in deciding which projects to >> accept -- I trust their judgement) Luca> I like the idea in principle - just one comment here, isn't Luca> this role pretty much tailored for the CTTE? It already has Luca> standing to make project-wide decisions by existing rules, and Luca> in fact routinely does so. This is pretty much how the Fedora Luca> equivalent, the Steering Committee, operates, and it seems to Luca> work well over there. Any reason you preferred the Release Luca> Team in the proposal? I actually think that the skills and outlook you need for an appeals body of last resort are different than you need for the coordination of which of an overlapping set of projects to coordinate into a release. I don't know that the body making this decision should be the RT; I worked on a proposal like this that I circulated privately to a few people while I was DPL. There I was imagining something RT-like, probably with overlap in composition with the RT, but possibly not the same as the RT. Here are things I think the RT style composition has going for it. * The RT is used to trying to find ways to say yes, but is also used to managing stability and trying to minimize the number of parts moving at once so that releases can happen. * The RT needs to have buy-in; ultimately they are responsible for which changes are acceptable. For example in usrmerge, ultimately it was the RT that was able to say that we aren't going to actually move files around until dpkg gets fixed. Yes, their decision was consistent with the TC's decision, but the RT is used to, and good at saying "this is ready but that next step over there isn't yet." * the RT members are involved at a very detailed technical level in stuff. At an architecture review level, it's very easy to get stuck in the theoretical. When the RT is sitting there looking at the actual patches and going "wait! You want 60k lin.lines of changes in this close to the release," they see it is complex in a way that an architectural overview might hide. * The RT gets involved when things break. They have a very good exposure to what kinds of changes introduce real complexity than comes back to bite us and what kinds of changes are safe. * The RT is good at keeping processes focused on goals that we have wide agreement on. There is subjectivity, but with very few exceptions the RT isn't going to come back and tell me I shouldn't be able to do a transition; they are going to focus on working with me to make sure I'm ready for it and haven't missed details. In a proposal like this, whoever is deciding which projects should go in cannot be making the decision based on technical merits; they would need to be deciding whether adequate consensus has been reached, whether there are people lined up to do the work, whether all the stakeholders have had a say, that sort of thing. That looks a lot more like an architecture qualification than a TC decision. However, some of that is a bit beyond the work the RT appears to usually do, and certainly throwing that onto the existing work for the RT without adding a bunch of volunteers sounds challenging. And then there are the social factors. * the RT has a history of being able to say no in a way that we can accept. Oh, yes, there are some people who have gotten really upset (and I can think of one case where someone effectively minimized their Debian involvement) over RT decisions. But the RT has a really good track record of being able to say no without generating a project-wide storm. They have a lot of social capital. * I think that's in part because we all have positive interactions with the RT where we can see how they have helped us find a detail we missed in a transition, or asked an important question as we were proposing a stable update. Perhaps not all of us, but many of us have seen the RT actively working with us to move stuff we care about forward. Oh, I'm sure there's also frustration about how the RT doesn't move faster and the like. * And at the end of the day, the RT makes releases, and we all get to benefit from them. In contrast, the TC: * Is technically focused. The TC has a history of doing its own technical evaluations rather than working with consensus processes elsewhere. Sometimes that's exactly what we need, but I don't think that we would want that for early coordination of which shared projects we're working on. Also, the way that consensus stuff on debian-devel intermingled with TC bugs for usrmerge was a major step forward on this. * The TC is a body of last resort. That's a different mindset than trying to approve projects to get into releases. The TC is much more likely to say some form of no--no, we won't override, no this is too early for the TC, no we won't have an opinion, no, we're the wrong group--than the release team. That's actually valuable given the TC's job. * The last time the TC considered doing this job, they said no. Remember Debian roadmaps? At the time the DPL tried to get the TC involved, and was turned down. Those are my thoughts. I do think that the issues Ansgar raises are important. But I also think that something along these lines could lend legitimacy to consensus-based discussions or point out where we need a non-consensus decision earlier. As an example, I think there was a huge process failure in the usrmerge work. There was a consensus discussion on debian-devel that was used as justification to make the default change in debootstrap. The claim within the debootstrap change was that the debian-devel discussion reached consensus. As DPL, I went back and read that discussion. I'm actually not convinced there was a consensus. But because no one made a public consensus call, asserting their reading of consensus where people could challenge it, we'll never know. If there had been a consensus call, there would have been a lot more legitimacy in shutting down people who objected to the debootstrap change. Similarly, a coordination team could have pushed back on usrmerge much earlier pointing out that there were issues from the dpkg maintainer that were not addressed. I've made it no secret that I'm unhappy with the dpkg maintainer's behavior recently. Objections that are inappropriate now would have been much more reasonable earlier. And they were made--perhaps not well, perhaps not repeatedly enough--but they were made and dismissed earlier. I'm not saying we should have agreed with them and taking a different approach. I'm saying that if we had an agreed process to consider those objections, we could have either made a decision about those objections earlier, or discovered we were not able to make such a decision. If we failed to make a decision, then one side could not claim that the objections had been handled. If we made a decision, then we'd be expected to fall in behind that decision. In effect, we'd be deciding as a project what counts as steamrollering and what was just being in the rough part of a consensus. We could for example decide that we would penalize projects for not dealing with concerns raised early by stakeholders, but if those projects took the time to deal with concerns raised at the appropriate points, the bar for later concerns would be raised significantly. And yes, we might well discover we were unable to make decisions on some projects--possibly including things like usrmerge. I think even that would be a significant improvement. --Sam