gimp

Nils Philippsen nils at redhat.com
Mon Aug 29 16:23:03 UTC 2011


On Mon, 2011-08-29 at 15:03 +0300, Nicu Buculei wrote:
> On 08/25/2011 05:28 PM, Nils Philippsen wrote:
> >
> > You're probably referring to the updates 2.2->2.4 in '07 and 2.4->2.6 in
> > '08 but please keep in mind that we're stuck with 2.6.x as the stable
> > branch since then, so there's no reason to be gloomy about the Fedora
> > side just yet.
> 
> I remember how we tracked the 2.3-2.4 development in Rawhide, which 
> allowed me at the time to write articles (previews, tutorials) based on 
> our official packages and, of course, allowed the entire community to 
> contribute with testing and feedback.

We didn't track development at that time, these were release candidates
of 2.4, see the RPM changelog:

...
* Wed Oct 24 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-1
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-0.rc3.2
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-0.rc3.1
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-0.rc2.2
...
* Tue Sep 04 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-0.rc2.1
...
* Thu Aug 16 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.4.0-0.rc1.1
...
* Fri Jul 13 2007 Nils Philippsen <nphilipp at redhat.com> - 2:2.2.17-1
...

These versions already used the same file names as proper 2.4.x did,
right now I know that much of this _will_ change when 2.8 is released,
which incidentally impacts packaging the most (rather than normal code
changes).

> > While we mightn't have had an explicit update policy for Fedora in the
> > time, these packages only went in after thorough testing on top of that
> > upstream managed to keep things as backwards-compatible as could be
> > expected -- the built-in scheme interpreter became a bit more strict in
> > 2.6, which was a documented break with 2.4 which could easily be fixed
> > by fixing affected 3rd party scripts.
> 
> Testing is the "magic" word, we want to test it.

Foremost, I want to have packages tested that actually have a more than
even chance of ending up in the stable release. Right now I don't feel
as confident about getting 2.8 in time for F-17 as I felt about 2.4 for
F-8. If you look at the development schedule on
http://tasktaste.com/projects/Enselic/gimp-2-8 you'll notice some fairly
sizable tasks left which account for 15-18 workdays of people who'll
likely do this in their spare time, which is projected right now for
about 81 realtime days from now. I haven't seen much activity on the
listed topics though in the last time (not critiquing upstream devs
here, I'm a bit surprised to see only 2 real tasks left on that
schedule), so this might slip even a bit more. "It's ready when it's
ready" and all that. Rest assured that I'll push packages when we get to
a point where inclusion is probable.

> > Considering that upstream to a large part isn't interested in working on
> > 2.6 anymore -- the last commit by a core developer to this branch was in
> > February this year -- I don't expect to see another 2.6 bugfix release.
> > As well, installing both stable versions side-by-side isn't an option as
> > you can't install them into the same prefix: the libraries have the same
> > SONAME, the new ones are expected to be ABI compatible. Therefore I
> > don't see a real alternative to rebasing to 2.8 in stable Fedora
> > releases when it finally is available, after thoroughly testing it of
> > course (which I already do to a certain extent, I can e.g. confirm that
> > the ufraw gimp plugin built with 2.6 works with a private installation
> > of current git master).
> 
> In the meantime I feel there is some duplicate effort wasted here: the 
> maintainer (Nils) is doing his own testing in private, another 
> contributor (Luya) is struggling (and hitting walls) with building an 
> external repo, people don't know what and from where to use.

I'll think about making "gimp-beta" packages and putting them on
fedorapeople, but their relevance for testing in Fedora will be rather
limited as they have to be installed into a different prefix
(e.g. /opt), so all 3rd party stuff won't work without user intervention
(i.e. symlinks into /usr/...).

Nils
-- 
Nils Philippsen      "Those who would give up Essential Liberty to purchase 
Red Hat               a little Temporary Safety, deserve neither Liberty
nils at redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011



More information about the devel mailing list