Difference between revisions of "Release:Packaging Guide"

From GIMP Developer Wiki
Jump to: navigation, search
Line 2: Line 2:
  
 
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.
 +
 +
For simplicity's sake we refer to the GIMP project, although realistically the guide covers both GIMP, GEGL, and babl projects.
  
 
== Packaging As-Is ==
 
== Packaging As-Is ==
Line 8: Line 10:
  
 
* '''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].
  
 
== Packaging with Source Code Changes ==
 
== Packaging with Source Code Changes ==
Line 16: Line 20:
  
 
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 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 ==
  
 
* '''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 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 20:53, 6 June 2016

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.

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.

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 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 GNOME's Bugzilla.

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.
  • 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 support. Users should be able to contact you and report bugs.
  • 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 GNOME's Bugzilla.

Packaging with 3rd Party Extensions

  • 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 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 GNOME's Bugzilla.