Difference between revisions of "Release:Packaging Guide"

From GIMP Developer Wiki
Jump to: navigation, search
Line 1: Line 1:
Being a small team, GIMP developers cannot provide builds for all operating systems and their variants out there. Moreover, there seems to be a demand for 3rd party builds that provide extra features not available in upstream GIMP releases.
+
== Coverage ==
  
 
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.
 
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.
Line 5: Line 5:
 
For simplicity's sake we refer to the GIMP project, although realistically the guide covers both GIMP, GEGL, and babl projects.
 
For simplicity's sake we refer to the GIMP project, although realistically the guide covers both GIMP, GEGL, and babl projects.
  
== Packaging As-Is ==
+
== Background ==
 +
 
 +
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 [https://bugzilla.gnome.org/ 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).
 +
 
 +
== Packaging ==
 +
=== Packaging As-Is ===
  
 
* '''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.
 
* '''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.
Line 11: Line 28:
 
* '''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.
 
* '''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 2 support.''' 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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
+
* '''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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
  
== Packaging with Source Code Changes ==
+
=== Packaging with Source Code Changes ===
  
* '''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.
+
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.
 
* '''Release patches that you applied to GIMP.''' Publishing changes to source code is a GPL requirement. We ask you to honor it.
Line 21: Line 40:
 
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.
 
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 support.''' Users should be able to contact you and report bugs.
+
* '''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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
  
* '''Provide Level 2 support.''' 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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
+
=== Packaging with 3rd Party Extensions ===
  
== 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.
 
* '''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 support.''' Users should be able to contact you and report bugs.
+
* '''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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
 
+
* '''Provide Level 2 support.''' 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 [https://bugzilla.gnome.org/ GNOME's Bugzilla].
+

Revision as of 22:09, 6 June 2016

Coverage

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.

Background

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).

Packaging

Packaging As-Is

  • 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.