"Luca" == Luca Boccassi <bluca@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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)