I have made a schedule for GIMP 2.8 with the main purpose of being a tool to help us decide what features to include or exclude. The schedule will also let us track project progress and assist "third parties" in their planning, such as the documentation team and distro package maintainers.

The schedule is very simple. It contains a list of things we want to do for GIMP 2.8 and an estimate of the time each task will take in the unit "8-hour workdays". The sum of all tasks is then multiplied with a "days worked per week" factor to give us an estimate on the number of days left until GIMP 2.8 is ready. Including the things we originally wanted in GIMP 2.8, the ETA for GIMP 2.8 is 2012-01-23. I don't think anyone of us wants to wait that long, so we need to take a few features out. If we take out:

* Vector layers
* Unified transform tool
* Cairo drawing on canvas
* Free transform tool
* A bunch of bugs on the 2.8 milestone list

Then the ETA of GIMP 2.8 becomes 2010-12-02 which is more reasonable. There is of course a large degree of inaccuracy in these numbers, we should iteratively refine them. There are a few things I would like to point out regarding this schedule:

* No pressure, that will take the fun out of GIMP development * It is optional to bother about this schedule * There are no tasks assigned to specific persons * It is intentionally very simple
* It will become more useful over time

Right now the schedule can be found at [1]. My proposal is that we version control the OpenOffice.org Calc document in the devel-docs directory in GIMP git.

So, what do you guys say about doing the above de-scoping and version controlling the schedule in git?

/ Martin

[1] http://www.chromecode.com/gimp/gimp-2-8-schedule.ods

Gerald Friedland wrote:

Hi,

I think we owe it to Google that all the Google Summer of Code stuff be put into GIMP 2.8 (or earlier).

Hi Gerald

If you want the SIOX improvements in 2.8 you should help us integrate it. For me the code on the branch didn't even compile last time I tried.

The first step is to merge 'master' to 'soc-2009-siox-drb' so we get a small diff when we eventually merge 'soc-2009-siox-drb' to 'master'.

Thanks for any help!

Best regards, Martin Nordholts

Alexia Death wrote:

In general, its wonderful. A few notes tho. The format. It does not really facilitate discussion and is a bit inconvenient to follow. Perhaps a wiki format, tho I assume calc was selected because of the eta math? Versioning is a good idea regardless.

Next, It currently assumes there is only one person at work. Wouldn't it make more sense to track estimated time of completion as provided by people working on a feature, or yes, a time estimate for no caretaker or hard to assess items? If something has no caretaker an no estimate of completion its likely to be left out.

Lastly, items on this list could use some numbered markings so one could add a comment with a reference, say this depends on item X, cant be started before its done etc.

Hi Kaja,

Yes, I used OO.org Calc because there are calculations that needs to be made. It would be nice to have it more accessible but I think we can live with it when I've added it to ./devel-docs.

The scheme does not assume there is only one person at work, the current factor "3 days worked per week" is what I estimate that the GIMP community currently produces together.

And IMHO, adding numbers to allow references and dependencies would create more complexity than we currently need.

/ Martin

Liam R E Quin wrote:

"clean up on-text editing", is there a better description?

Not yet, but everyone is free to look into exactly what we need to do and come up with more detailed tasks. On-canvas text editing simply needs to work a bit better than it currently does. Just by using it it's possible to find things that could work better.

/ Martin

Alexandre Prokoudine wrote:

On 1/11/10, Martin Nordholts wrote:

Then the ETA of GIMP 2.8 becomes 2010-12-02 which is more reasonable.

And still somewhat scary :)

The plan however does not seem to mention Python scripting improvements branch. (which will make estimations only scarier :))

Yes, if I recall correctly, Lars said there was still work left to do which he would not have time to fix for 2.8. I might be wrong though.

/ Martin

Nelson A. de Oliveira wrote:

Can donations (money) to GIMP somehow speed up its development, please?

Currently, money donated to GIMP as a project will not be used to pay people for writing code, but is instead used for doing things like paying flight tickets to e.g. Libre Graphics Meeting.

In order to speed up development then, you would have to hire a specific person.

BR,
Martin

Martin Nordholts wrote:

I have made a schedule for GIMP 2.8 with the main purpose of being a tool to help us decide what features to include or exclude.

I've commited the schedule now, it can be downloaded from http://git.gnome.org/browse/gimp/plain/devel-docs/gimp-schedule.ods?id=038ea9474d9f0fe6877376d1cc3640b1bde8d3b8

I've de-scoped some features but left a few in 2.8 still such as vector layers. We should let a few weeks pass to see how the ETA date moves. If the estimates are right, the ETA in the file will stay the same as time passes and as we update it. We'll need to remove further things on the 2.8 milestone list but that can wait a bit.

/ Martin

On 01/25/2010 12:00 PM, Alexandre Prokoudine wrote:

The somewhat scary thing about this schedule is that neither 2.8, nor 2.10-3.0 section mentions GEGL at all :)

Hi Alexandre!

There will be no further integration of GEGL for GIMP 2.8, and the 2.10/3.0 section does not contain things planned for 2.10/3.0, only things originally planned for 2.8 but posponed.

And I think that you overrated work on release notes a bit :) I don't know how much time it took Sven and Michael to refine the text I banged up for 2.4 and how much time it took Jimmac to produce screenshots, but my part was just IIRC four or five hours. With a well organized effort this could be a matter of day really, not three days.

It's not three days, it's three man-days. Three persons working full time a single-day on writing release notes should be recorded as 3 working days in the schedule. Based on my experience with compiling the release notes for 2.6 it can easily take 3 days worth of work to produce high quality comprehensive release notes.

Regards, Martin