Working with upstream

Sometimes, when a submitted project bears a strong relationship with another project ("upstream"), we ask the submitter to consider working with that other project, instead of working separately with a distinct project.

Such cases include:

developing a new feature for a project: maybe the original package maintainers would like to include it directly in their repository, perhaps in the form of a branch, rather than seeing you maintain a distinct version of their package.
project translation: this is commonly done by maintaining .po files in the original package, rather than in a separate project.
internationalization ("i18n") effort: this is similar to adding a new feature—for example, adding support for Asian or Indian writing systems, which is more difficult than just providing Unicode support. If you develop your i18n effort separately, you will have to follow the development of the upstream package, and you'll probably end up maintaining an incompatible version. It is more efficient to work with the upstream maintainers to directly improve their package i18n features.

Of course there are exceptions, e.g.:

it is not easy to get write access to the upstream repository;
you cannot work with patches, because the new feature is an effort involving multiple co-workers.

When Savannah can offer a useful service to your project, we will gladly provide you a group (provided your project meets our hosting criteria, of course).

Do not take it badly if we ask why you need a Savannah group—often we get submissions for people who did not see the cons in working separately or did not think about working with the upstream maintainers. We just make sure that this option was considered.

Our goal is not to get as many Savannah groups but as many quality pieces of free software as possible :)