How to not collaborate with Debian (and upstream)

[Michael Casadevall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I added comments to the Launchpad bug explaining the FHS violation the
modification causes, and why its a problem is greater detail.

I generally think that something which is this invasive should have
been talked about on ubuntu-devel recently before ANY change was
pushed. The Debian group considered changing it and decided "WONTFIX".
Any suggestions to coordinate with Debian were shrugged off, and the
package itself did massive changes w.r.t to how gems operates on
Ubuntu.

/usr/local issues aside, the upload breaks a few other long standing
guidelines, like packaging git snapshots which should ONLY be done as
a last resort (i.e. upstream explicatively states to do so, i.e.
ffmpeg), changing the patch system is always a no-no, and using a
cdbs-patch-system. Since Soyuz to my knowledge doesn't support
UNACCEPT, that means every merge/sync from Debian will have to
increase the epoch to keep things working nicely on our side. This was
an absolutely boneheaded upload; It looks like this got uploaded by
someone sponsoring uploads before the feature freeze, and it didn't
fully get checked during this time.

I think we first need to revert this upload before anything else is
done, and THEN figure out a proper course of actions as a group.
Michael

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: http://getfiregpg.org

iEYEARECAAYFAki1/qsACgkQpblTBJ2i2psvzQCfecibhV4RSsIgoVXzaBN+MjP6
tkEAn36Xpw1ocFgzTxOaLise9wyXpSQr
=5/5A
-----END PGP SIGNATURE-----

On Wed, Aug 27, 2008 at 8:48 PM, Scott Kitterman <ubuntu at kitterman.com> wrote:
> On Wed, 27 Aug 2008 20:35:19 -0400 "Steven Harms"
> <thisdyingdream at gmail.com> wrote:
>>This sounds more like 'How not to encourage anyone to help at all'.
>>The tone of the comments
>>in the bug are very confrontational when clearly all these people
>>wanted was a functional
>>package.
>>
>>They saw a package that didn't work for *anyone* and wanted to change
>>it.  They were not
>>seasoned pro's, and I think this is just a testimate to the lack of a
>>obvious process.
>>
>>It would be a shame, on the heels of developer week, to lambaste new
>>contributors on
>>mailing lists.
>
> So it's better to stay silent in the face of a bad technical decision
> (leaving the inter-distro/inter-project frictions aside even)?  Gems, as
> has been the subject of recent discussion on Ubuntu ML about why this was
> NOT a good idea, pretty thoroughly ignore the entire package management
> systems.  Putting them in the path so random versions not installed by the
> package management system get executed in the place of system installed
> version is not my idea of a good plan.
>
> Also, Lucas is speaking as a Debian developer and he's really not under any
> obligation to worry about our social calendar.  The best way to avoid this
> kind of backblast is to work out sensible solutions with Debian and
> upstream.
>
> Scott K
>
> --
> Ubuntu-motu mailing list
> Ubuntu-motu at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
>