GIMP 2.8 schedule

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

Hi Martin,

I am happy to do that. Last time we asked though people said there is no time...

I wonder when you tried integrating it? It should definitely compile...

Gerald

--
Dr. Gerald Friedland
International Computer Science Institute
1947 Center Street, Suite 600
CA-94704 Berkeley, USA
http://www.gerald-friedland.org
--
Sent from Berkeley, CA, United States


On Mon, Jan 11, 2010 at 2:11 PM, Martin Nordholts <enselic@gmail.com> wrote:
> 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
>
>

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

On Monday 11 January 2010 22:53:06 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.
...snip...
> 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?

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.

--Alexia

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

On Mon, 2010-01-11 at 21:53 +0100, Martin Nordholts wrote:

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

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

This could usefully be put somewhere people could sign up
for things.

Some of the bugs appear to have been fixed already (eg.
595537, Text tool crashes GIMP
568445, Closing the Toolbox causes the program to close

Some others (e.g. downscaling) may take a lot longer than
you've marked, I think.

Maybe we need to have some gimp-love days, of people
checking to see if they can reproduce bugs, and adding
steps-to-reproduce if they can. I'd be happy to help
with that from time to time. Same with tagging resources.

Liam

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

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

Alexandre

On Wed, Jan 13, 2010 at 8:57 AM, Alexandre Prokoudine
<alexandre.prokoudine@gmail.com> 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 :))
>
I thought that had already been merged.
Was it only a partial merge?

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

Hi!

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

Thank you!

Best regards,
Nelson

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

On 1/14/10, Patrick Horgan wrote:

>> In order to speed up development then, you would have to hire a specific
>> person.
>
> In the lilypond list they have this great thing. People that want a
> particular feature offer to sponser it, and say how much they are willing to
> pay. Occasionally others then say me too and up the ante. Developers with
> interest in that area contact them individually. It seems to work great. A
> number of features have gotten into lilypond in this way.

But it doesn't work for Ardour :), where MIDI tracks are much like
GEGL in GIMP.

Alexandre

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 Mon, Jan 11, 2010 at 11:53 PM, Martin Nordholts wrote:

> 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:

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

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.

Alexandre

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