Re: [Gimp-developer] Setting Up a Release Procedure

[Simone Karin Lehmann <simone lisanet de>]

Hi,

Am 30.11.2013 um 12:26 schrieb Jehan Pagès <jehan marmottard gmail com>:

> Well... that's why I was proposing testing and collaborating *before*
> releasing, and not after. :-/

yes. Sadly, now the „no-outline-issue“ is another showstopper.


> > It’s not about building. I wrote a couple of scripts which automates that quite well. But in the last 
> > years I’ve made a lot of OS X specific patches (don’t ask, why some of them are not upstream…. long story) 
> > and making a new release requires to adapt these patches and to test if the are still needed and if they 
> > still fix the addressed issue. Two examples:  years ago on X11 it took me for ages to fix the file chooser 
> > sorting bug. Well, on Mavericks it’s back again. Second: using the Cocoa based version of 
> > gtk-mac-integration to get properly working menus and keyboard shortcuts.
>
> Well that would still be a lot better for the users *and* for you if
> we could all collaborate. If these patchs on third party are really
> necessary to prevent major bugs, we'll appreciate having them in our
> source tree as well (we have a directory build/osx/ where we save
> build-specific data, like third-party software patches).

yes, I’ll share them. But IMO this needs to get committed about what build system we use on OS X. Clayton 
uses jhbuild. I use a slightly hacked version of MacPorts and some bash scripts to ease the process of 
building on Mavericks down to SnowLeopard and even cross compile to 32bit and it helps me manage about 100 
packages needed to build my bundles. As far as I’m concerned, I’d like to stay with that and not to switch to 
something else I’m not used to and from what I don’t know if it fits my needs and gives me all functionality 
I already have.

> This way, we
> can share these patchs will all packagers, and doing so will also save
> you time as we would take on us to check and adapt the patches.
> Could we know more about your patches, and what they fix exactly?

e.g. 
glib, gtk2, cairo
using Coca instead of Carbon, fixes paths to fit into Mac standards, etc.
gtk-mac-integration:
use Cocoa, fix some issues, don’t hide the delegate and notification protocols to enable easier app 
development on the application side.
gimp:
Cocao, working help system with reduced config options, using some system provided libraries instead of build 
them from source, Mac shortcuts, lightly different behavior of lcms to recognize more icc profiles, working 
dock menus :-), hide / unhide Gimp, and a „right-out-of-hell-and-never-will-be-included-patch“ about the save 
/ export issue ;-)

Here’s the link to the current epository  (not totally complete, I’ll update this if I find some time…. and I 
know, some code looks ugly …)

https://sourceforge.net/p/gimponosx/code/HEAD/tree/

> Would you accept to contribute them to us?

if we could negotiate an what to use …. :-)

> All this said, the preferred politics is indeed to contribute upstream
> if possible. What is the reason why you did not propose your patches
> upstream? You can make the short version of the story if you like :-).

hhhmm, what should I say, I don’t want to revive these zombies, but I’ll try a short version. (you’ve been 
warned :-) )

In the „old days“ of the Mac packaging community most things were fine. But then patches or plugins got 
rejected with a simple „No, we don’t include this, because we are the official packagers“. Other patches were 
silently taken and rewritten without asking why I did it in this specific way. No discussion about why I did 
things or how to improve things, all of a sudden, everybody only wanted packages. No one was interested in 
going deeper. Although I asked for help to fix a long standing issue (using the help system, install the user 
manual locally, get rid of the „GIO/GFVS“ error. (BTW, all of this is now fixed, it took me years…)) … 
nothing happened. I got the impression that, with a few exceptions, nobody wants to contribute to the Mac 
version. And then came this discussion about a „native“ build. Everybody thought that a native version will 
automagically solve all problems they have. But „native“ is IMO much more than simply dropping X11 and have a 
menu bar at the top. It’s about using OS X functionality like ColorSync, the print system, system provided 
libraries, using Cocoa not Carbon.
Again, I got the impression that there are only very few people interested in contributing to the Mac 
version. Most people only wanted to build a package and to have the menu bar at the top. So I decided to do 
it on my own. Last zombie: for a short time the link to my site was dropped in favour of a „native" build 
with the menu bar on top. And although GIMP now being "officially native“, well, there are only few things 
from other OS X developers and packagers to port more code to native OS X functionality.
But now let the zombies rest in peace and give the OS X version a new try.

> > New OS versions introduce new bugs. See the pencil / brush issue I mentioned above.
>
> I saw the email and the bug report from the contributor. Have you been
> able to reproduce it also?

sadly, yes.

> No problem. But this is exactly why it would be a lot better if you
> could discuss with our team OSX packager (Clayton Walker). I'm sure a
> collaboration into a single OSX release could save you time and allow
> to do better testing.
> May I ask exactly what is different with your release and the ones
> that Clayton Walker do?

mainly the above mentioned patches, a lot of plugins, my packages are signed with an Apple Developer ID.

> Maybe you could also drop by IRC (#gimp on irc.gimp.org) and discuss
> with us some way to improve the situation?

puuh, I don’t like IRC because of my bad english (I’m just to slow to keep up…) and it’s mainly about not 
having enough time. Sorry. I try to do my best, but now I need to do some other work (keeping the house clean 
and prepare for a business meeting and trip next week). Again, I’ll try to collaborate as much as I can.

Regards
Simone Karin

— 
stay hungry, stay foolish