Re: [Gimp-developer] Setting Up a Release Procedure
Hi, On Tue, Dec 10, 2013 at 5:00 AM, Sam Gleske wrote: > On Mon, Dec 2, 2013 at 11:09 AM, Sam Gleske wrote: > >> What are the Windows packagers using for the build? If they're using a >> proprietary package system I suggest moving to a more open one such as NSIS >> and customizing that. Windows builds can easily be automated using NSIS. >> Another advantage of using NSIS is checking the scriptable installer code >> into SCM. >> > > Does this mean that nobody on this list knows what the release process is > on Windows for building installers? As Michael answered too, of course we have people in charge of the Windows release procedure. Simply I am hoping we can improve it by merging efforts, since several people are also known to do their own quality release outside us. And our procedure is far from perfect. I wish it were more systematic and without a fault. But we do have an existing procedure since we do have releases and code for it in our repo. And we are slowly improving it (for instance you may have noticed the recent improvement: now all releases go in the ftp, instead of using a third party provider). Jehan > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
Sam Gleske wrote: >On Mon, Dec 2, 2013 at 11:09 AM, Sam Gleske >wrote: >Does this mean that nobody on this list knows what the release process >is on Windows for building installers? Innosetup is used for the installers, and the scripts for it are in the git repository, under the build/windows/ directory. -- Regards, Michael ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
On Mon, Dec 2, 2013 at 11:09 AM, Sam Gleske wrote: > What are the Windows packagers using for the build? If they're using a > proprietary package system I suggest moving to a more open one such as NSIS > and customizing that. Windows builds can easily be automated using NSIS. > Another advantage of using NSIS is checking the scriptable installer code > into SCM. > Does this mean that nobody on this list knows what the release process is on Windows for building installers? ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
What are the Windows packagers using for the build? If they're using a proprietary package system I suggest moving to a more open one such as NSIS and customizing that. Windows builds can easily be automated using NSIS. Another advantage of using NSIS is checking the scriptable installer code into SCM. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
Hi, On Sun, Dec 1, 2013 at 12:44 PM, Jehan Pagès wrote: > On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann > wrote: >> 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. We had a quick look with Mitch on the patches for GIMP specifically. Many of them are obsolete now. For instance we already switched to the Cocoa platform since 2.8.10 (commit e56344294c90e1ba97de5c134b50c4c522f0808f which includes code from you already!). And some like the save/export, we obviously won't integrate, as you can guess. But the "color display change" for instance seems promising. :-) If you have other contributions you would like to see upstream, I would really suggest discussing them with us and providing us patches. This would really improve everyone's process! Thanks anyway. Jehan ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
Hi, On Sun, Dec 1, 2013 at 2:50 AM, Simone Karin Lehmann wrote: > Hi, > > Am 30.11.2013 um 12:26 schrieb Jehan Pagès : > >> 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
Re: [Gimp-developer] Setting Up a Release Procedure
This wasn't a Mavericks bug; it can happen on linux too. For some reason, this only triggered on clang. Anyway, I just fixed it in gimp git (see commit 95becc7615c7e9cf2f6135c8d5b0fe1cca86648f). So, this will be fixed for the next release. -- drawoc On Sat, Nov 30, 2013 at 9:26 AM, Maurizio Loreti wrote: > On Sat, 30 Nov 2013 11:37:05 +0100, Simone Karin Lehmann de> wrote: > > 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. > > > Don't blame OS X Mavericks. Under Mavericks GIMP 2.8.6 pencils and brushes > work like a charm. > > -- > > (@_ | > > //\ | Maurizio Loreti - Retired physicist, happy grandfather > > V_/_ | of two grandsons, wanderer and amateur photographer... > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
On Sat, 30 Nov 2013 11:37:05 +0100, Simone Karin Lehmann wrote: 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. Don't blame OS X Mavericks. Under Mavericks GIMP 2.8.6 pencils and brushes work like a charm. -- (@_ | //\ | Maurizio Loreti - Retired physicist, happy grandfather V_/_ | of two grandsons, wanderer and amateur photographer... ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
Hi, Am 30.11.2013 um 12:26 schrieb Jehan Pagès : > 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 ment
Re: [Gimp-developer] Setting Up a Release Procedure
Hi, On Sat, Nov 30, 2013 at 11:37 PM, Simone Karin Lehmann wrote: > > Am 28.11.2013 um 22:25 schrieb Jehan Pagès : > 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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
Am 28.11.2013 um 22:25 schrieb Jehan Pagès : 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. > 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. 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. New OS versions introduce new bugs. See the pencil / brush issue I mentioned above. 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. 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
Re: [Gimp-developer] Setting Up a Release Procedure
Jehan Pagès (jehan.marmott...@gmail.com) wrote: > 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! Indeed :) Sven N. hasn't been very active in Gimp development for quite a while now. He is currently focussing on different things. I met him a few weeks ago and he is alive and well - just not in the GIMP universe :) > I completely understand that each individual enjoys being a maintainer — > and thus the main actor! I for one would not enjoy maintainership :) Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
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 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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
On Wed, Nov 27, 2013 at 5:16 PM, Alexandre Prokoudine wrote: > 27 нояб. 2013 г. 5:14 пользователь "Jehan Pagès" > написал: > >> >> Also I propose that before a build is officially released, they are >> first listed on this page for willing people to test it and an email >> should also be sent on the dev mailing list. If all goes well, all >> tasks done, and all builds are tested and look good, then we can >> publicly announce a release and distribute builds that have been >> actually tested first. >> >> What do you think? > > I think you deserve Medal of Honour, sir :) Hahaha. Well let's hope that others agree then. It would be good to have a better release organization. Jehan > > Alexandre > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Setting Up a Release Procedure
27 нояб. 2013 г. 5:14 пользователь "Jehan Pagès" написал: > > Also I propose that before a build is officially released, they are > first listed on this page for willing people to test it and an email > should also be sent on the dev mailing list. If all goes well, all > tasks done, and all builds are tested and look good, then we can > publicly announce a release and distribute builds that have been > actually tested first. > > What do you think? I think you deserve Medal of Honour, sir :) Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
