Team Organization?
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
Team Organization? | Stephen Greenwalt | 26 Jan 07:15 |
Team Organization? | Martin Nordholts | 26 Jan 07:42 |
Team Organization?
I have been reviewing Gimp / GEGL source code . . . to get familiar with everything . . . so that I have some context to understand where I might help the project.
But I am operating in a "void" because I don't understand:
- How the development effort is organized.
- Is there a team leader?
- What tools, etc. are being used to manage things such as:
- Feature requests, bug reports, etc.
- Component development.
- Testing.
- And all the other usual stuff.
- What the development priorities are, and where programmer resources are needed.
The main Gimp website says that the new priority is expansion of the GEGL engine.
But, does that mean that major feature development for main Gimp app is being stopped until the GEGL engine is ready?
I, for one, love Gimp but would really like to see one or new features such as:
- Support for sub-layers (i.e. nesting of layers in tree-style control).
- Ability to delete multiple layers at the same time, rather than
one-by-one.
- Layer-by-layer history . . . so that you can undo changes within the
current layer only.
Should I offer help in those areas?
Again, I just need some context.
Thanks,
Steve Greenwalt
Team Organization?
On 01/26/2011 08:15 AM, Stephen Greenwalt wrote:
I have been reviewing Gimp / GEGL source code . . . to get familiar with everything . . . so that I have some context to understand where I might help the project.
But I am operating in a "void" because I don't understand:
* How the development effort is organized.
o Is there a team leader?
Strategic decisions are taken in concert, although due to human nature, the opinions of some individuals have more weight depending on their reputation. We have two official maintainers, cat MAINTAINERS.
o What tools, etc. are being used to manage things such as: +
Feature requests, bug reports, etc.
We prefer feature requests on this mailing list, so that they can be discussed and evaluated, in particular in the context of our product vision [1]
Bug reports are managed in GNOME Bugzilla [2]
+ Component development.
In general, all development happens on the git master branch directly, although personally I think we should review our development methodology for GIMP 3.0 because we have problems in our 2.8 development cycles due to this.
+ Testing.
I have a long term goal of improving the GIMP development environment, and have lately put efforts into writing regression tests for both old and new functionality, and I have been setting up a nightly builder that runs all our tests [3]. Curiously enough, you'll notice make distcheck failed tonight due to changes yesterday, but I already fixed that...
* What the development priorities are, and where programmer resources are needed.
Right now, the priority is getting GIMP 2.8 out. The two major work areas left is finishing the implementations of layer groups and single-window mode, see [4] for the main missing bits.
After that, we will start working on GIMP 3.0, which will be GIMP 2.8 running on GTK+ 3.0 and using GEGL-buffers for all data. That is, we will throw out our 8-bit only image/tile data structures. For GIMP 3.2 we will start looking into serious support for non-destructive editing.
The main Gimp website says that the new priority is expansion of the GEGL engine.
But, does that mean that major feature development for main Gimp app is being stopped until the GEGL engine is ready?
See above
I, for one, love Gimp but would really like to see one or new features such as:
* Support for sub-layers (i.e. nesting of layers in tree-style control).
Fundamental support for that is already in place in git master
* Ability to delete multiple layers at the same time, rather than one-by-one.
Yes that would be nice, but support for higher bit depths and non-destructiveness has higher priority
* Layer-by-layer history . . . so that you can undo changes within the current layer only.
Sounds like a work-around for GIMP not having non-destructive editing yet
Should I offer help in those areas?
Any help is greatly appreciated.
Best regards, Martin
[1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision
[2] http://bugzilla.gnome.org/browse.cgi?product=GIMP
[3] http://gimptest.flamingtext.com:8012/waterfall
[4]
https://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&target_milestone=2.8