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

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann <simone lisanet de> wrote:
> 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.

Well, this is up to you to decide. I know everyone of us, developers,
think we are right, at least at first. And maybe you even really are
(= maybe your building solution is nicer than Clayton's, I just have
no idea). But in the end, being right does not matter compared to the
benefits of collaboration. GIMP would be nothing compared to what it
is now if it had stuck to be a single-man project.
Stubbornness is usually a good thing... up to one point. :-)
But yes in the end, you are to decide what you want to do.

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

Thanks. I'll see what Clayton thinks about these.

> > Would you accept to contribute them to us?
>
> if we could negotiate an what to use …. :-)

Well on our side, we have not much to give, or "negotiate". We just
want to collaborate with as much packagers as possible, so that they
become actual upstream contributors and save everyone's time, but also
give a much better user experience to all users.

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

Well I wish you could also see the other side of the story. Now I
don't know your exact cases of course, but I am a Free Software
contributor too. And I got all sort of disappointment with it too. I
got a lot of rejected patches in my life and the developers would not
seem to care about my explanations. Well maybe they simply had another
vision of the software as I. And as I said before, the problem is not
to be right or wrong. Who am I to say they are?
I even got patches totally ignored, even though I repeatedly came back
and abandoned in the end. Very frustrating too.
I also got rewritten patches in ways I disagreed, or even patches
taken as is, but with authorship changed to a developer's name!
Well that's all too bad, but that's life. Developers/maintainers are
all human, just like you. Some have not enough time and forget your
patches or misread them, some are not that skilled, some are actual
asses (doing FOSS does not prevent you from being an ass), some just
forgot to check a patch because they are not well organized, some
simply disagree and even though they would like to please anyone, you
can't always do so, and so on. Also all can do mistakes, even the best
ones! That's important to note.

Basically it's hard to contribute to FOSS, because it's still human
relationship, and it requires some patience on everyone's side. But
the rewards is very good. There is still so much you can do alone. And
in the end, working upstream instead of maintaining what are basically
mini-forks of that many programs is so much powerful: you touch all
users (and not only a small user-base), you are ensured your changes
will survive any rewriting, you don't have to always maintain them… In
other words, you can carry on, proceed to other issues at hand and
forget about these past issues. That's so much better than constantly
having to maintain the same boring past issues, which is extremely
limiting and like being glued to a status-quo.
So I really hope you will reconsider contributing upstream, not only
for GIMP but for the many projects you seem to have patches for. Once
again, I think none of the widly used FOSS programs would be even half
of what they currently are if all contributors had stuck to themselves
and made forks.

> I got the impression that, with a few exceptions, nobody wants to contribute to the Mac version.

I think the main point is that there are less Mac developers in Free
Software historically. They are rather using Free OSes (Linux, BSD,
etc.). So it's not that they don't want it, it's just they don't use,
so we just wait for a contributor actually on this OS to step in. This
said, it changes, and I see more FOSS developers with a Mac.

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

I don't think many people would disagree with you. It is obvious that
integration in any OS is more than just doing a copy-paste from
another platform. I think there is enough OSX-specific code in GIMP to
show that we believe it too.
But we still need to start somewhere. And this start is at the common
code, that can be further specialized. Also we want to do things well,
which still means have as most common code as possible, and push down
specific code to layers down (GTK+, glib, etc.). Doing things well
takes time but ensures less bad surprises in the future.
In any case we welcome any patches to go further in integration!

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

Well bugs, we won't ever totally get rid of them. This is nearly by
definition! :-) There are bugs on GIMP, whatever the platform. :-P
That's why we welcome contributors even more.

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

I don't really like IRC either, mostly because I don't like much
chatting. Or rather the opposite: I don't like to have to "wait" there
and nothing happening (I prefer people to send me a message, IM or
email, when they need it). But that's how they do in GIMP. So I am not
*always* in the IRC channel, but I go sometimes when I think about it.
Often indeed nothing happens. But sometimes, well I can get some shit
done because I was there. So I feel better.
Again sometimes collaboration means you have to do compromises because
this is a 2-way thing. :-)

Jehan

> Regards
> Simone Karin
>
> —
> stay hungry, stay foolish
>
>
>
> _______________________________________________
> gimp-developer-list mailing list
> List address:    gimp-developer-list gnome org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list