Testers requested for our new Mac OS X DMG release!,
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.
Testers requested for our new Mac OS X DMG release!,
Hi
Kristian, thank you for stepping in and making an OS X build! Especially the DMG creation command and fixing some of the nasty Poppler and DBus problems are impressing me.
You asked for testers and here are some of my test results:
1. The GIMP build comes with the G'Mic plug-in. Sadly it is crashing. I suddenly get the message:
"Plug-in crashed: "gmic_gimp" (/Users/$my_user_name/Library/Application Support/GIMP/2.8/plug-ins/gmic_gimp)
The dying plug-in may have messed up GIMP's internal state. You may want to save your images and restart GIMP to be on the safe side."
Including this plug-in is well-meaning but I think it's a pitfall
for the GIMP team because users might think it would be part of
GIMP and therefore report G'Mic bugs to the GIMP team instead to
the G'Mic people.
Avoiding this was the reason I made a stock build of GIMP 2.8.14 with
no extra plug-ins.
2. Is this build with the latest dependency versions?
3. To be honest and fair it would be good to name Kristian as the
creator of the 2.8.16 build on the download page and not me anymore
for the older build.
How about mentioning the patched and extended builds of other eager
contributors like Partha and skl or even Gimp Paint Studio and
CinePaint in a separate fork section of the Download page?
If I find more I'll try to report to Bugzilla.
Anyway, I know how hard it is and how much time it takes to provide a working OS X build - thanks for your work!
Greetings
Sven
Testers requested for our new Mac OS X DMG release!,
On 2015-12-28 10:19 (+0100), scl wrote:
1. The GIMP build comes with the G'Mic plug-in. Sadly it is crashing. I suddenly get the message:
The official app bundle for GIMP 2.8.16 from wgo does not include the G'Mic plug-in.
Regards, V
Testers requested for our new Mac OS X DMG release!,
On Mon, Dec 28, 2015 at 12:19 PM, scl wrote:
How about mentioning the patched and extended builds of other eager contributors like Partha and skl or even Gimp Paint Studio and CinePaint in a separate fork section of the Download page?
The general agreement in the team is that we don't feel comfortable promoting builds whose packagers do not provide information about changes they introduced (if any). To make this more transparent for the community, we are preparing a document on packaging requirements that we'd like (but don't demand) GIMP packagers to meet.
GIMP Paint Studio is currently unmaintained.
Cinepaint is an inactive project.
Alex
Testers requested for our new Mac OS X DMG release!,
On 28.12.2015 at 11:01 AM Su V wrote:
On 2015-12-28 10:19 (+0100), scl wrote:
1. The GIMP build comes with the G'Mic plug-in. Sadly it is crashing. I suddenly get the message:
The official app bundle for GIMP 2.8.16 from wgo does not include the G'Mic plug-in.
Thanks for this hint. I checked back and indeed, the G'Mic plug-in was a leftover from a former G'Mic test on my own system. Sorry for the confusion.
Sven
Testers requested for our new Mac OS X DMG release!,
Hi Alex,
While I am not against your policy, this is first I am hearing about this agreement. Of course this may have been a verbal agreement within the team.
Anyway, I am happy to provide any information the team needs about my builds.
Note that I provide my builds as a community service without asking for any remuneration whatsoever in return.
Thanks, Partha
On Mon, Dec 28, 2015 at 5:16 AM, Alexandre Prokoudine wrote:
On Mon, Dec 28, 2015 at 12:19 PM, scl wrote:
How about mentioning the patched and extended builds of other eager contributors like Partha and skl or even Gimp Paint Studio and CinePaint in a separate fork section of the Download page?
The general agreement in the team is that we don't feel comfortable promoting builds whose packagers do not provide information about changes they introduced (if any). To make this more transparent for the community, we are preparing a document on packaging requirements that we'd like (but don't demand) GIMP packagers to meet.
GIMP Paint Studio is currently unmaintained.
Cinepaint is an inactive project.
Alex _______________________________________________ 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
Testers requested for our new Mac OS X DMG release!,
On Mon, Dec 28, 2015 at 4:13 PM, Partha Bagchi wrote:
Hi Alex,
While I am not against your policy, this is first I am hearing about this agreement. Of course this may have been a verbal agreement within the team.
Most team discussions take place on IRC.
Anyway, I am happy to provide any information the team needs about my builds.
Excellent :)
Note that I provide my builds as a community service without asking for any remuneration whatsoever in return.
Of course :)
Alex
Testers requested for our new Mac OS X DMG release!,
On Mon, Dec 28, 2015 at 5:16 AM, Alexandre Prokoudine wrote:
On Mon, Dec 28, 2015 at 12:19 PM, scl wrote:
How about mentioning the patched and extended builds of other eager contributors like Partha and skl or even Gimp Paint Studio and CinePaint in a separate fork section of the Download page?
The general agreement in the team is that we don't feel comfortable promoting builds whose packagers do not provide information about changes they introduced (if any). To make this more transparent for the community, we are preparing a document on packaging requirements that we'd like (but don't demand) GIMP packagers to meet.
On 28.12.2015 at 2:13 PM Partha Bagchi wrote: > While I am not against your policy, this is first I am hearing about > this agreement. Of course this may have been a verbal agreement within > the team.
There was also a similar agreement at the LGM 2014, see http://wiki.gimp.org/wiki/LGM2014Minutes#Malicious_and_reputation-damaging_installers_and_apps, 3):
"3) How do we deal with GIMP builds that come with additional plug-ins, such as Simone Karin Lehmanns or Partha Bagchis build?
Agreement to 3) 3rd party plug-ins and improvements to OS-integration (OS X, Windows, etc.) are ok. ? Shall they become part of the official build? Changing GIMPs designed behaviour, like modifications to the Save-Export-behaviour must not become part of the official GIMP builds."
Neither your nor skl's builds are considered as malware. The question came up when we discussed public GIMP builds with modifications. I hope this helps a bit.
Greetings
Sven
Testers requested for our new Mac OS X DMG release!,
Hi Sven,
Thanks for your feedback!
On 28 Dec 2015, at 10:19, scl 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!
The next step is to upgrade dependencies and to build a WebKit-enabled GIMP so we can ship with a working help system.
And the steps after that are to automate the process and to look into doing regular 2.9.x builds.
thanks,
-kris.
Testers requested for our new Mac OS X DMG release!,
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 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
Testers requested for our new Mac OS X DMG release!,
On 31 Dec 2015, at 14:13, scl 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.
Weve 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.
regards,
-kris.
Testers requested for our new Mac OS X DMG release!,
Hi,
On 4.1.2016 at 9:23 AM Kristian Rietveld wrote:
On 31 Dec 2015, at 14:13, scl 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.
Weve been in contact with Tobias indeed.
And to which result?
- @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.
Lately I heard of AppImages, self-contained application packages like
apps or dmg, but for Linux.
For the Ubuntu part I think all it takes is to contact "Otto
Kesselgulasch", the maintainer of the GIMP PPA on Ubuntu.
Perhaps staying in touch with the package maintainers of other
distros could be helpful.
Greetings
Sven
Testers requested for our new Mac OS X DMG release!,
On Mon, Jan 4, 2016 at 11:23 AM, Kristian Rietveld wrote:
- @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.
Was thinking of exact same thing lately :) But I'd take it further than that.
Not only we have lagging Win/Mac/Linux builds, we also have lagging user manual releases.
For instance, gimp-help 2.8.0 was released as a tarball in June 2012, a month after GIMP 2.8.0 release. The installers for Windows only appeared in August, and we don't even have official OSX builds of the user manual at all (the ones by Simone are outdated and only available for a few languages).
Hence I'd like to propose the following change to the release policy, using Sven's proposal as a basis:
1. Negotiate a release date between mitch (GIMP maintainer), pippin (GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).
2. Finalize a list of changes that should be covered in the user manual and in the docs for developers.
3. Announce a strings freeze at least a month before releasing to give translators and docs writers do their job.
4. Complete all release related docs.
5. Bump version number for both GEGL/babl, GIMP, and gimp-help.
6. Make and test all builds for all supported systems.
7. Update the 'testing' branch of the website (download links, announcements), update docs.gimp.org, check everything.
8. Merge all changes from the 'testing' branch into the 'master' branch of wgo.
9. Announce.
To specifically aid #2, since December, there's a changelog targeted at user manual writers:
http://wiki.gimp.org/wiki/Release:2.10_changelog
Needless to say, it's WIP, but it's getting there.
Alex
Testers requested for our new Mac OS X DMG release!,
On Sun, Jan 10, 2016 at 3:11 AM, Alexandre Prokoudine wrote:
1. Negotiate a release date between mitch (GIMP maintainer), pippin (GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).
Also, I think whoever is in charge of the user manual these days should have a say here, but the problem is that I have no idea who that person is (Julien?), and I don't think this person is ever on IRC where most communication is taking place. It would be _amazing_ to have stakeholders connected to the release procedure and tuned to actual gimp development.
Alex
Testers requested for our new Mac OS X DMG release!,
On 10.1.2016 at 1:21 AM Alexandre Prokoudine wrote:
On Sun, Jan 10, 2016 at 3:11 AM, Alexandre Prokoudine wrote:
1. Negotiate a release date between mitch (GIMP maintainer), pippin (GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).
Also, I think whoever is in charge of the user manual these days should have a say here, but the problem is that I have no idea who that person is (Julien?), and I don't think this person is ever on IRC where most communication is taking place. It would be _amazing_ to have stakeholders connected to the release procedure and tuned to actual gimp development.
Alex
I fully agree to your two posts, Alex.
Greetings
Sven
Release procedure (was: Testers requested for our new Mac OS X DMG release!)
On 10.1.2016 at 1:11 AM Alexandre Prokoudine wrote:
On Mon, Jan 4, 2016 at 11:23 AM, Kristian Rietveld wrote:
>> On 31 Dec 2015, at 14:13, scl wrote:
- @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.
Hence I'd like to propose the following change to the release policy, using Sven's proposal as a basis:
1. Negotiate a release date between mitch (GIMP maintainer), pippin (GEGL/babl maintainer), Jernej (Win builds), and Kris (OSX builds).
2. Finalize a list of changes that should be covered in the user manual and in the docs for developers.
3. Announce a strings freeze at least a month before releasing to give translators and docs writers do their job.
4. Complete all release related docs.
5. Bump version number for both GEGL/babl, GIMP, and gimp-help.
6. Make and test all builds for all supported systems.
7. Update the 'testing' branch of the website (download links, announcements), update docs.gimp.org, check everything.
8. Merge all changes from the 'testing' branch into the 'master' branch of wgo.
9. Announce.
To specifically aid #2, since December, there's a changelog targeted at user manual writers:
http://wiki.gimp.org/wiki/Release:2.10_changelog
Needless to say, it's WIP, but it's getting there.
lately in IRC the idea of documenting and scripting our deployment processes at LGM came up. I support this idea and like to bring up the topic of rethinking our release procedure again. It would be nice if you could discuss it at LGM. Well, I'm not attending LGM but if you need me I'm ready to take the time and be there in our chat room or answer by mail.
Greetings
Sven
