svn games

[jurij@wooyd.org]

Hi,

I would like to bring the following recent svn commits to the
attention of the team. I have made a commit r6880 in Saturday morning
(Pacific time):

 Switch to gcc-4.1 for sparc, because it works (tm).

This commit was neccessary because the 2.6.17-1 kernel was uploaded by
Bastian on Friday, despite the fact that it has been known to be
broken on sparc SMP systems [0]. At this point Bastian has pointed out
to me on IRC that changing to a newer compiler is an ABI change. I
have immediately asked Jeroen whether it is feasible to reject the
sparc binaries from the NEW queue and got a response that since the
source have been already been accepted to unstable, there is not too
much point in such a rejection. So I made the commit r6881:

  * Move new changelog entries to 2.6.17-2, as -1 is uploaded already.
  * Add sparc32-iotlb.patch.
  * Bump ABI to 2 as a result.

This commit was *immediately* reverted by Bastian in r6883:

  Revert r6880, r6881 and r6882. Can't accept an ABI bump yet.

That was done while both of us were on IRC. I was quite dumbfounded by
such arrogant behavior and asked for explanation. After repeating my
question a few times, I was able to deduce from Bastian's one-word
replies that he talked to someone else on ftp-master team and was
assured that the rejection of sparc binaries was still possible. At
this point he "allowed" me to make commit r6884:

  * Switch sparc to gcc-4.1, no ABI bump as sparc binaries for 2.6.17-1
    never made it to the archive.
  * Add sparc32-iotlb.patch.
  * Add myself to uploaders.

I added myself to uploaders anticipating that we will be able to
upload soon and fix the unfortunate sparc situation. When I've asked
whether there are any other pending changes for 2.6.17-2, I was told
by Bastian that there's not going to be any upload any time soon
because we "don't want to trash the buildd network".

Later this day I was asked by Maks to review the 2.6.16.22 patch,
since it was likely to conflict with sparc patches already in
svn. I've examined it, removed the conflicting patch, and committed it
in r6886:

 * Start 2.6.16-6 (typo, should have been -16)
 * Remove dcache-momry-corruption.patch, included in 2.6.16.22
 * Add 2.6.16.22

I believe it was the first time I've added the stable point release to
the tree. I've assumed that as the diff was pretty small, the
possibility of failure was pretty minor, besides any such failure
would have been caught by the snapshot builders. Thus, I didn't run a
full build at that time, but only checked that the patches unapply and
apply cleanly. To my astonishment soon I've noticed Bastian's commits
r6890:

 Revert r6886. Untested changes.

and r6891:

 * debian/changelog: Update.
 * debian/templates/control.source.in:
   Remove Jurij from Uploaders, he has to learn how to test changes first.

Even if one ignores the derogatory remark, this does not make any
sense, because the latter commit was made into 2.6.17 tree (trunk),
which I have personally built and tested on sparc.

So, as a result of this I would like to issue the following statement
to Bastian:

I take reverting the svn commits very seriously. I will not tolerate
them without a clear technical explanation of why it was neccessary
and allowing a grace period to discuss and fix the problems. If
something like this will happen again, I will not hesitate to raise a
question of revoking your svn access, because I believe that the need
to deal with your childishly arrogant and disruptive behavior has by
now outweighed the usefulness of your contributions. I also find your
statements about the lack of testing quite hilarious, considering
that your latest upload of linux-kbuild-2.6 package has been rejected
from NEW due to lack of debian/copyright file.

I would also like to ask other members of the team for opinions on the
svn commit protocol. I suggest to formulate the policy for testing the
changes and for reverting the commits by others, to make sure that such
incidents never happen again.

[0] http://lists.debian.org/debian-kernel/2006/06/msg00347.html

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC