Difference between revisions of "Release:Packaging Guide"
|Line 22:||Line 22:|
== Packaging ==
== Packaging ==
=== Packaging As-Is ===
=== Packaging As-Is ===
Revision as of 12:10, 17 January 2017
This guide aims to establish better communication between GIMP developers and 3rd party packagers and provide the latter with our understanding what we consider a good packaging practice.
For simplicity's sake we refer to the GIMP project, although realistically the guide covers both GIMP, GEGL, and babl projects.
GIMP is free software, and it's within your right to modify it as long as you publish your changes along with builds you provide, under the same license. As much as we'd like to see people contributing to the upstream project rather maintaining forks, we respect your freedom to act within what GPL allows.
Moreover, we'd rather see a community where maintainers of forks (created for whatever reason) sticked around. This is because better communication between the upstream and the downstream helps providing great user experience at all ends of the spectrum.
As the upstream team, we have a history of looking at forks and creating cleaner, better designed implementations of modifications found in forks. We think it would be a much better use of time and human resources, if the upstream and the downstream worked off the same code base, exchanged bug reports, and provided user support.
Staying in the Loop with the Upstream Team
We recommend the following steps to keep up with the upstream team:
- Subscribe to bugs reported to GNOME's Bugzilla for the 'GIMP' product.
- Show up in the #gimp IRC channel at irc.gimp.net.
- Follow suggestions listed below (matching the kind of 3rd party packages you provide).
- Stay current! If you provide builds, chances are that you maybe become a known source for builds for a specific platform or distro. We recommend to keep your builds as current as is feasible on the platform you are building for (at a certain point, the availability of dependencies will limit what can reasonably be provided; GIMP tends to be rather conservative especially in its stable versions, though). Providing old releases is OK, trailing behind a branch in active development for a few days or maybe a week is OK as well. Trailing behind an actively developed branch for months is NOT RECOMMENDED - in this case, please indicate that your builds are outdated, or pull them altogether.
- Make it obvious what version you are providing! This is all about labeling the packages you provide. If you label them "2.8.18", a user (and the GIMP developers) will expect to find exactly 2.8.18 inside. If you are building something that doesn't have a fixed version number - i.e. anything between two actual GIMP releases - please include the abbreviated commit Id as well.
- Provide as many stock features as possible. While you can build GIMP without certain features and keep the list of dependencies low, we ask packagers to provide as complete builds as possible. This is to make sure that users get all the features they see advertised in the user manual and various tutorials online.
- Make unstable builds available alongside stable builds. If you provide unstable (Git master) builds of GIMP, it should be possible to install it alongside with a stable GIMP release. This is because we make unstable releases for people who are eager to try new features and provide sensible bug reports, while using the stable release for actual daily work.
- Provide Level 1 and 2 support. Users should be able to contact you and report bugs. If you receive reports that are not related to specifics of the packaging, your should report those bugs to the upstream GIMP project. This requires having an account at GNOME's Bugzilla.
Packaging with Source Code Changes
The general idea is that people who publish modified builds of GIMP have responsibilities they should honor. The upstream project will fix bugs discovered in modified 3rd party builds, but only if those bugs are not caused by 3rd party modifications.
- Document and publish your changes for end-users. Some packagers are known to build GIMP with tweaks that change the behavior of GIMP or add/remove features. Users should be able to know what exactly they are getting. Therefore, we ask packagers to provide a list of changes for users, in plain language.
- Release patches that you applied to GIMP. Publishing changes to source code is a GPL requirement. We ask you to honor it.
We recommend creating a page that would list changes (e.g. in an itemized list) and link to source code patches available as diff files on per-feature basis.
- Provide Level 1 and 2 support. Users should be able to contact you and report bugs. If you receive reports for bugs that are not caused by either your patches or packaging, please reports those bugs to the upstream GIMP project. This requires having an account at GNOME's Bugzilla.
Packaging with 3rd Party Extensions
Much like with source code changes, packagers who add extra features into the bundle have responsibilities. The upstream team cannot be held responsible for bugs in 3rd party code.
- List the 3rd party plugins and scripts that you bundled with GIMP. We are interested to understand what kind of existing plugins that are not part of GIMP are in a high demand by users. We cannot realistically check every 3rd party build out there, so we would appreciate a list of 3rd party extensions and plugins that you ship with your build. This helps us providing better out-of-box user experience.
- Provide Level 1 and 2 support. Users should be able to contact you and report bugs. If you receive reports for bugs that are not caused by your patches, please reports those bugs to the upstream GIMP project. This requires having an account at GNOME's Bugzilla.