> On 31 Dec 2015, at 14:13, scl <scl.gp...@gmail.com> wrote:
>> 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.

We’ve been in contact with Tobias indeed.

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

It would be great if you could help with testing new DMG release before we 
officially release them!

> - Splitting the 2.8 and master builds in the modulesets and
> moving the master builds into the GIMP master branch.

I was thinking of doing that too.

> - @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?

More coordinated releases would be a good thing to have IMHO. Releasing Windows 
& Mac binaries and perhaps Debian/Ubuntu and Fedora packages at the same time 
as a new tarball release would be great.



gimp-developer-list mailing list
List address:    gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Reply via email to