sent this from the wrong address.
Bdale> The way I look at this is that it has not been a primary
Bdale> *expectation* of the project that the ftpmasters review and
Bdale> approve the quality of the software that is packaged. The
Bdale> lack of a routine expectation does and should not prevent
Bdale> them doing it, however.
1) I don't think the skill set required to accomplish the ftpmasters
typical tasks makes them particularly more qualified than other
developers at judging quality. I can accept they may be above
average because it's a relatively trusted position and requires
experience. However ftpmasters are not explicitly selected to make
this sort of quality decision.
2) From a process and organization standpoint, the more power people
have, the more they need to be accountable for their actions and
the more careful they need to be to avoid personal biases being the
deciding factor. That doesn't mean their judgment is objective:
there are significant and important subjective elements of sound professional technical judgment.
3) Related to 2, you want to encourage processes that enable
individuals to make forward progress. You want to encourage
motivated people to be able to do the work they want to do. You
want to have a relatively high bar to saying "no, don't do that." You want a much lower bar to saying "here's how to do that better," and an even lower bar to "here, let me help you do this better in this way."
4) Following from 3 and 2, it can be incredibly demotivating when a
group with relatively high power is telling people "no," rather
than "no, here's how to fix." It's sometimes necessary. "I want
to package Vista for Debian," is a clear no on DFSG (and many
5) You want to be more careful when a group is excersising power
outside their primary mandate. If ftpmasters are saying "No, that
is not DFSG," then you are less careful than if they are saying
"no, that is too buggy." However you don't want to be too careful.
For example, ftpmasters are developers: they should clearly be able
to raise any objection that a normal developer can raise. But if
they are excersising power for reasons that they typically don't do
so, or are not expected to do so, you want to be careful and
probably want to have others involved to sanity check the decision.
6) The release and security teams are explictly chartered to judge whether software is too buggy. It seems fine for ftpmaster is taking input from those teams. If the release team judged something to be too buggy and suggested the ftpmasters should consider removing it from the archive that would seem fine to me. If they said something was too buggy and the ftpmasters should carefully consider not letting it in, that also seems reasonable to me.
7) The TC is also chartered to review things like whether software is too buggy.
In conclusion, I think that ftpmasters saying this is too buggy and when there is disagreement, sending it to the TC is entirely reasonable process. If the ftpmasters said that something was too buggy and without concurring input from some other team required the TC to overrule them in order to disagree, I'd think that was very questionable process.
I do not think the TC should feel the need to "back up" the ftpmasters here. I think that an honest review of the technical issues is appropriate here.
Just my thoughts.