2019 project report
This discussion is connected to the gimp-user-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
2019 project report | Alexandre Prokoudine via gimp-user-list | 05 Jan 09:18 |
2019 project report | Shlomi Fish | 05 Jan 10:31 |
2019 project report | C R via gimp-user-list | 05 Jan 10:49 |
2019 project report | Christopher Curtis via gimp-user-list | 05 Jan 16:22 |
2019 project report | Alexandre Prokoudine via gimp-user-list | 05 Jan 17:46 |
2019 project report | Tom Williams via gimp-user-list | 05 Jan 17:53 |
2019 project report
Hello,
Our annual GIMP/GEGL report is out:
https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/
Enjoy :)
Alex
2019 project report
On Sun, 5 Jan 2020 12:18:25 +0300 Alexandre Prokoudine via gimp-developer-list wrote:
Hello,
Our annual GIMP/GEGL report is out:
https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/
Enjoy :)
Alex
Thanks for writing that and sharing.
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Shlomi Fish https://www.shlomifish.org/ Perl Elems to Avoid - https://perl-begin.org/tutorials/bad-elements/ * Backward compatibility is your worst enemy. * Backward compatibility is your users’ best friend. — http://www.shlomifish.org/humour/fortunes/osp_rules.html Please reply to list if it's a mailing list post - http://shlom.in/reply .
2019 project report
Thanks to everyone for all the hard work in 2019!
-C
On Sun, 5 Jan 2020, 09:19 Alexandre Prokoudine via gimp-developer-list, < gimp-developer-list@gnome.org> wrote:
Hello,
Our annual GIMP/GEGL report is out:
https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/
Enjoy :)
Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
2019 project report
Alex,
Thanks for putting together this report, I know it's a lot of work and never much fun.
I was very intrigued by the opening remarks and "lessons learned" re: more frequent releases.
In this spirit, I would like to resurrect a long dead thread, reference: https://marc.info/?l=gimp-developer&m=134556216910609&w=2
At that time, Mark Shuttleworth was advocating that all FOSS projects adopt a timed release process like Ubuntu's 6-month cycle. I believe Fedora does this. One of his arguments was that regular releases makes planning easier for distributors, but from your report I think that GIMP developers also see the value in regular incremental releases.
In that thread from 2012 I proposed a 3-month release cycle. This is, and was, a slightly slower pace than that used by the Linux kernel. The number is arbitrary but I still think the results will be worthwhile. With 3 releases in 2019, a 4-month process may be a good place to start.
There are issues and challenges to doing this, and I think there are answers to both, but I suggest this only to see if the interest is real.
Chris
PS - I use GIMP infrequently these days, but +1 on suggestion for a better text tool. Given recent font tech (ligatures, font feature settings), it seems something similarly sophisticated may be warranted here as well. Perhaps direct import of HTML+CSS makes the most sense, even if it means bundling an entire browser engine ... then maybe even a text edit tool written in Electron? That can use browser-based editors? Short justification: the web is defining modern typography, and raster applications need to compete. Embrace and subsume...
On Sun, Jan 5, 2020 at 4:19 AM Alexandre Prokoudine via gimp-developer-list wrote:
Hello,
Our annual GIMP/GEGL report is out:
https://www.gimp.org/news/2020/01/04/gimp-and-gegl-in-2019/
Enjoy :)
Alex _______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
2019 project report
On Sun, Jan 5, 2020 at 7:22 PM Christopher Curtis wrote:
In that thread from 2012 I proposed a 3-month release cycle. This is, and was, a slightly slower pace than that used by the Linux kernel. The number is arbitrary but I still think the results will be worthwhile. With 3 releases in 2019, a 4-month process may be a good place to start.
Personally, I can see this happening for the stable series, i.e. what is now the 2.10.x branch. Our build process is now more or less automated for flatpak (Linux) and dmg (macOS), and we think we can do that for WIndows eventually. That simplifies quite a lot of work, although the last few Win/Mac updates required manual intervention. In fact, we recently put two updated Windows installers — one because of an important fix in GEGL, and one because of a fix for a broken 3rd party component.
As for the release frequency, we try to make a release around LGM time, which is usually April-May, we did 2.10.6 and 2.10.12 in the summer time, and we did 2.10.8 and 2.10.14 in late autumn before the Xmas madness. That already sounds like a plan.
That said, I don't think it's entirely possible for the unstable branch. Mitch keeps uncovering bad code all the time, and once you start pulling a funny-smelling rope, there's always a chance there's a rotting corpse on the other end of it, if you pardon my analogy :)
Alex
2019 project report
On 1/5/20 9:46 AM, Alexandre Prokoudine via gimp-user-list wrote:
On Sun, Jan 5, 2020 at 7:22 PM Christopher Curtis wrote:
In that thread from 2012 I proposed a 3-month release cycle. This is, and was, a slightly slower pace than that used by the Linux kernel. The number is arbitrary but I still think the results will be worthwhile. With 3 releases in 2019, a 4-month process may be a good place to start.
(snip)
That said, I don't think it's entirely possible for the unstable branch. Mitch keeps uncovering bad code all the time, and once you start pulling a funny-smelling rope, there's always a chance there's a rotting corpse on the other end of it, if you pardon my analogy :)
Alex
Love the analogy. I'll have to borrow that from you, if you don't mind. :)
Peace...
Tom
/When I leave, I don't know what I'm hoping to find, And when I leave, I don't know what I'm leaving behind.../