Hi, 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@xxxxxxxxx> 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. Jehan > > Greetings, > > Sven > > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
