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


It was sent to me only. I imagine that's a small mistake, so I'll
answer back to the whole list. :-)

On Fri, Nov 29, 2013 at 7:41 AM, scl <scl gplus gmail com> wrote:
Hi Jehan,

I am ... impressed ;-)

Yes, the release procedure is something that has potential to improve
and I'm happy you took the time and elaborated a procedure.
I fully agree with you that we need more testing before a release.
As yet I had a glance over your proposal and hope I will find more time
next for a more comprehensive answer. Currently I'm fully stretched
with real life tasks, getting a deeper understanding of the color topic,
the UI theme and Jenkins.

Well actually the 4 main points are:
1/ testing: right now, releases are sudden, out of nowhere, and we
discover release issues afterwards. Not only program bugs, but really
release bugs (like the fontconfig ones on Windows). Seriously if the
Windows package had been first released in beta, I would have tested
these specific fontconfig issues (because I spent quite some time
trying to debug these), and would have reported them immediately (so
they would not have happened in the finale release).
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.
3/ No knowledge passing down: even though everyone knows how to
compile GIMP, it looks only the package maintainers know how to make
OSX/Windows installers (each with its different procedure). First it
means I can't make a package for testing. But even if it were made
very easy to produce installers, we could even propose users to test
fixes and debug versions on Bugzilla when we are trying to debug
issues. Right now we are totally dependent, and if the packagers
disappear, we have to guess the procedure from the start.
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. On the other hand,
all together, I know we can simplify complicated tasks a lot. With
scripts, automatization, and sharing work. That's what usually happens
when a lot of tech people work together. Ideally it should be so easy
to package a new version with a simple command, we go get a coffee and
get back in 2 minutes and... tadaa!!

Eventually the procedure should find Mitch's agreement.

Of course. I just wanted to give a little push. Because just saying it
would make nobody move, I feel. Maybe starting with a wiki page ready
to be filled by the various packagers could be a small first start to
collaborate (since people like wiki). Of course if nobody cares, well
it will just stay a dead wish and I'll remove the pages in some time.

BTW: Thanks for the compliments about the benevolent maintainer.
I wasn't aware that I am seen as a maintainer like Mitch
(who is our real code guru here ;-), am I? Let's also not forget

Oh right. I just checked again. In the AUTHORS page, there is actually
a Sven Neumann as maintainer alongside Mitch. I actually realize I
made a mistake, because that's another Sven! And since I don't see him
much (I think, but with people's nickname, maybe I do!), I assumed it
was you and did not pay attention to the family name. :p Well good you
took it well. Hopefully nobody took it bad too!

our eager packagers Jernej, Drawoc, Clayton, Simone and Partha ;-)

Of course, I have listed them in the wiki page for instance. :-) I
completely understand that each individual enjoys being a maintainer —
and thus the main actor! — on their own piece of code (the
installers). And that's great, but that's also the reason I fear some
might not like work together and share the title. Maybe? In any case,
I really wish everyone could be happy by still being more efficient
together. That's the goal. And I really hope we can reach it.

Anyway let's wait and see how it goes.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]