[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unauthorized upload of xfree86 4.3.0-1 to unstable

Branden Robinson <branden@debian.org> wrote:
> FYI, for those who didn't know already, an upload identifying itself as
> xfree86 4.3.0-1, not authorized by me, was made by Daniel Stone to
> Debian unstable early Tuesday morning UTC.
> This upload was done without advance notice to, or consultation with the
> rest of the X Strike Force (XSF) team, and in conflict with the release
> plan[2] set down in the XSF Subversion repository.
> I would welcome follow-up to the debian-project list as to how we can
> clarify this sort of procedural ambiguity, whether Daniel Stone or I
> have transgressed the letter or spirit of any standard of conduct,
> whether his upload may have been justified even if it did violate some
> sort of code of conduct (perhaps because we have been waiting too long
> for a 4.3.0 upload to unstable), whether any sort of sanction should
> take place as a result of these actions, and what standards of procedure
> and courtesy we should have in team-maintained packages.
> Fundamentally, I think team-maintenance of
> packages has to be grounded on mutual trust among the members of the
> team.

Imho this is really something the maintainer team (i.e. XSF) has to
sort out themselves, because I agree with you that "mutual trust" is
absolutely necessary and trust cannot be forced upon the maintainer
team by formalized sanctions executed by the Debian SWAT team.[1]

You have to agree on how the X11 maintainership works and stick to
it. - Do you use the Linux-model with a single absolute ruler, or is
it more "democratically"?

> I personally feel that my trust was betrayed in this situation.
> If you think I should not feel this way, please explain why.

This is impossible to judge for me, as there was no note about this on
debian-x, but there is something seriously wrong with the
communication in the team, if one party does something without
discussing it with the other party and the other thinks discussion
would have been _absolutely_ necessary.
             cu andreas
PS: m-fup2 set for ccs to me as I do not read -project everyday.

[1] Compare it with how we handle botched NMUs just by peer-pressure.
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_

Reply to: