Re: [Gimp-developer] Testers requested for our new Mac OS X DMG release!,

[scl <scl gplus gmail com>]

On  28.12.2015 at 8:54 PM Kristian Rietveld wrote:
> Hi Sven,
>
> Thanks for your feedback!
>
> > On 28 Dec 2015, at 10:19, scl <scl gplus gmail com> wrote:
> >
> > 2. Is this build with the latest dependency versions?
>
> No, the first step was to reproduce a build using your instructions on my system. Your detailed instructions 
> have been very helpful, thanks for that!

Nice to read that my work helped someone :-)

> The next step is to upgrade dependencies and to build a WebKit-enabled GIMP so we can ship with a working 
> help system.

Good idea. IIRC building Webkit was at least not so easy when I tried.
I considered making the switch to WebKit2. Perhaps WebkitGTK+ is also
an alternative.

> And the steps after that are to automate the process

This reminds me of my attempts to integrate an OS X build slave
into the Jenkins continuous build environment. Sam Gleske or
Tobias Vogel might be able to tell you more about the current state.

> and to look into doing regular 2.9.x builds.
Yes, that would be nice.
How do you think about preponing the 2.9.2 build right after
the dependencies are updated? So the GIMP team could offer
the awaited 2.9.2 build a bit earlier.

I you need somebody to test your OS X build related commits,
I can be there.

Some more thoughts about the build process, but I leave it up
to the GIMP people what to do with them:

- Avoiding to git clone babl, gegl and GIMP during the JHBuild
process and instead build all into the existing prefix. Thus it
would be easier to test local changes, even in local branches,
without pushing them untested to the public git repository first.
- Splitting the 2.8 and master builds in the modulesets and
moving the master builds into the GIMP master branch.
- @GIMP team: I remember that at the time I was more active
new versions came out of a sudden when Mitch had time to
bump a release and the releases were made later. This has the
effect that users who read the announcement have to wait
again and thus are disappointed after a long period of waiting
for a release.
How about reorganizing the process of release builds and
version announcements by
1. negotiating a release date internally,
2. completing the release docs (NEWS, 
http://wiki.gimp.org/index.php?title=Special%3APrefixIndex&prefix=Release%3A&namespace=0)
3. bumping the version number,
4. making and testing the builds and
5. as last step announcing the release?

Many words, but I hope I could give some useful inspiration.
If desired I can try to help.


Greetings and have all a happy new year,

Sven