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

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

Hi,

On Sat, Nov 30, 2013 at 11:37 PM, Simone Karin Lehmann
<simone lisanet de> wrote:
> Am 28.11.2013 um 22:25 schrieb Jehan Pagès <jehan marmottard gmail com>:
> Hi,
>
> > Well actually the 4 main points are:
> > 1/ testing: right now, releases are sudden, out of nowhere, and we
> > discover release issues afterwards.
>
> yes, we really need a test cycle before a release goes public. Especially if there’s not only a new GIMP 
> source, but a new OS version as well, like it is on OS X. I just discovered a new bug, which is IMO release 
> critical. On OS X Mavericks, the pencil and brushes outline doesn’t show, so it’s almost impossible to 
> paint, clone and brush.

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

> > 2/ Work duplication: as you noted, many people on OSX are doing the
> > same thing. On Windows, well there are Drawoc and Ender which have 2
> > different procedures too.
>
> well, I’ve tried to answer this in another thread. So let’s give it a new try.
>
> > 4/ It looks like it is complicated for each of these individual
> > packager. When I see for instance Simone Karin Lehmann saying that she
> > just made a release and wouldn't do it again immediately (probably
> > because too boring/annoying task), that is too bad.
>
> 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). 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?
Would you accept to contribute them to us?

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

> Further in the past I’ve tried to test that new sources fit into the „Mac standards“ and wrote patches to 
> do so. E.g. moving the config directory to it’s proper location in ~/Library/Application Support.

Well this one is indeed useless now. :-)

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

> Pushing releases in such short cycles forces me to „just run my scripts“ to get a new package out and 
> satisfy all users who start asking for the new packages. I already have a lot of requests for a SnowLeopard 
> version.  This leaves no room for testing or fixing already known issues. And that was the only thing I 
> wanted to say when I wrote that I don’t want to redo some work. Sorry for not writing that clearly enough 
> in the first place.

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?

I see you add some photo editing plugins. Is that, along with the
third party patches, all the difference?

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

Jehan

> Simone Karin
> _______________________________________________
> gimp-developer-list mailing list
> List address:    gimp-developer-list gnome org
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list