qmail

[Sam Hartman <hartmans@debian.org>]

*sigh*
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.


Some thoughts.

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
   other) grounds.


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.

--Sam