* If the Debian package uses a patch system, change the patch system. You get bonus points if you switch from dpatch to anything else, and rename all the patches during the process, since this increases the diff size significantly.
* Upstream doesn't release often enough? And marking an svn snapshot as such in the upstream version doesn't look good? Don't hesitate to make up a new upstream release (or an RC). Doesn't matter if it only exists in Ubuntu. * You want to fix an upstream bug? Fix it in a way that is completely Debian/Ubuntu-specific (using tools like update-alternatives, for example). That way, upstream won't be able to steal your patch, and users of this software will have to switch to Ubuntu if they want your new feature. * If the software is dual-licensed, license your patches under only one of the licenses, to make it even less likely that upstream will integrate them. * When writing the changelog, make sure to forget about some changes, to make it less likely that the Debian maintainer will cherry-pick some interesting changes. * And of course, never contact the Debian maintainer during the whole process, even if you find bugs in the Debian package. Many thanks to Neil Wilson and Mathias Gug for preparing and uploading libgems-ruby 1.3.0~RC1-0ubuntu1, ignoring my concerns raised in LP#145267. This package provides perfect examples for each of the above points. Nice slap in the face. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |
signature.asc
Description: Digital signature
-- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
