Hi, first off, this was not an easy decision. It didn't happen so far yet, that motu-release had to decide if an upload should indeed get reverted, and hence this decision was done only with consent among all motu-release members. The key factor in regards to this decision was if this upload does work towards making an improvement in regards to the intrepid-release, or if it did in fact result in the opposite, hence making it unfit for release.
The following options were considered: 1) do not interfere, regressions/bugs are not grave enough to warrant an action of motu-release 2) revert the upload, either by archive admin intervention, or by uploading the old version with a higher version number. 3) revert the packaging back to the old version, but keep the svn snapshot (adjusting patches of the old packaging as needed) 4) Issue a one week deadline to Matthiaz/Neil to revert the packaging back to the old version, keeping the svn snapshot, otherwise falling back to 2. Since the svn snapshot made some patches unnecessary, option 3) was eliminated because it could cause regressions in a reversion upload from motu-release, whereas 4) seemed to address this concerns better. In order to find out, if 1) was a possible way, the possible regressions of gem handling in the change were examined compared to the previous package. This lead to the following findings: Executables of gems get symlinked via the alternatives mechanism to /usr/local/bin. Using the alternatives mechanism was considered inappropriate and counter- intuitive. /usr/local/bin is the first entry in $PATH, so executables installed there override any executables installed from Debian/Ubuntu packages. As a result, this can lead to problems in case there is a name clash between a binary shipped from an Ubuntu package and a binary installed from a gem. Among the problems of non-determinism and possible failing behaviour of Ubuntu- packages in case such a name-clash occurs, this situation is both hard to detect for a user/sysadmin, but also hard to fix without modifying /usr/local/bin in the first place (which however counter-acts the idea of the new gem handling). Especially the possible security problems arising from this approach (the mail from Stephan Hermann with imagemagick shipped by a gem served as an example in the motu-release discussion, especially since imagemagick is often called by web applications), was considered a critical enough issue to eliminate option 1). Another non-technical concern was also raised against option 1): The advice of developers in regards to the new gem handling was asked at [1] -- something which motu-release unambigously encourages -- but was obviously ignored when doing the upload in question. In order to find out, if patches from the new packaging should be kept, the diff to the old version was examined. The only noteworthy patch that was found, that doesn't fall under the catagory gem-handling, was a modification of the libgems updating mechanism. In contrast to the old version, this patch modifies the libgems package to call "apt-get install rubygems[version]" instead of printing a message to the user as the old package did. This approach was considered buggy as well, since it fails when apt-get is concurrently executed and is a no-operation in case the package list is not up to date. Finally, the discussion came down to choose between option 2) and 4). While importing a svn-snapshot wasn't considered a problem (since it was done before FeatureFreeze), motu-release tried to find out arguments why this was done in the first place. motu-release was convinced that this was done only in regards to the new gem handling. Likewise, the mislabeling of a svn-snapshot as non-technical argument was considered a bad practice. As a result it was decided to go for option 2). In this regard, motu-release found that unaccepting uploads is not possible with soyuz. To determine whether an epoch should be added, or rather a complicated version number should be used, motu-release contacted Lucas to find out if an epoch could be added to the debian package as well. However since Lucas stated that he was only the co-maintainer, and the maintainer would not very likely to agree to such a change, using a mangled version number was decided upon. As a result, motu-release will upload a reverted package within 24 hours. After that upload, libgems-ruby is free to be modified following the freeze rules again. Finally, in case this decision should not be acceptable to the involved parties, feel free to escalate to motu-council. Cheers, Stefan - on behalf of motu-release. -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu