gimp

[Genes MailLists]

  Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ?

[Richard Shaw]

On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists <lists(a)sapience.com&gt; wrote:
>   Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ? 
Is there a specific reason to? The home page states that the whole
2.7.x series should be considered unstable.

Richard

[Ilyes Gouta]

> >  Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ?
>
>  Is there a specific reason to? The home page states that the whole
>  2.7.x series should be considered unstable. 
Alright, would then the 2.8.x series be in F16?

-Ilyes

>  Richard
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Michał Piotrowski]

2011/8/23 Ilyes Gouta <ilyes.gouta(a)gmail.com&gt;:
> >>  Are there any plans to bring gimp 2.7.x -> 2.8 into F16
> ?
> >
> > Is there a specific reason to? The home page states that the whole
> > 2.7.x series should be considered unstable.
>
>  Alright, would then the 2.8.x series be in F16? 
I'm afraid that it is not the right list for this question - you have
to ask GIMP developers when they want to release 2.8. If they want to
release 2.8.x in next month or so, I guess that it will be possible to
package this version for F16 - but it is all up to GIMP devs - not
Fedora devs.

>  -Ilyes
>
> >
> > Richard
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> >
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  


-- 
Best regards,
Michal

http://eventhorizon.pl/

[Rahul Sundaram]

On 08/24/2011 01:57 AM, Ilyes Gouta wrote:
> >>  Are there any plans to bring gimp 2.7.x -> 2.8 into F16
> ?
> > Is there a specific reason to? The home page states that the whole
> > 2.7.x series should be considered unstable.
>  Alright, would then the 2.8.x series be in F16? 
That depends on when it is released. 
http://fedoraproject.org/wiki/Updates_Policy

Rahul

[itamar]

On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists
> <lists(a)sapience.com&gt; wrote:
> >
> >  Are there any plans to bring gimp 2.7.x -> 2.8 into F16 ?
>
>  Is there a specific reason to? The home page states that the whole
>  2.7.x series should be considered unstable.
>  
is this a good reason ?



http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...


------------

Itamar Reis Peixoto
msn, google talk: itamar(a)ispbrasil.com.br
[phone] (FIXO SP)
[phone] (TIM)
[phone] (OI)
[phone] (FIXO MG)

[Rahul Sundaram]

On 08/24/2011 02:04 AM, Itamar Reis Peixoto wrote:
>  is this a good reason ?
>
>
>
>
> http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...
Not to push a unstable release without knowing when the stable release
will be.

Rahul

[Nicu Buculei]

On 08/23/2011 11:34 PM, Itamar Reis Peixoto wrote:
>  On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw wrote:
> > On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists wrote:
> >>
> >>   Are there any plans to bring gimp 2.7.x ->  2.8 into F16 ?
> >
> > Is there a specific reason to? The home page states that the whole
> > 2.7.x series should be considered unstable.
>
>  is this a good reason ?
>
>
> http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...
No, that single window mode is not such a good reason, the feature is... 
cute but not excessively useful, the real reason is the 2.8 release is 
long overdue (expected since last December) and quite a few features 
were added: more gegl integration, better usability, linked layers etc.
And we the people using it for real work still remember the times when 
Fedora used to be a bleeding edge distro and had such GIMP updated... 
happy old times...

Hopefully Luya will update his unofficial build: 
http://repos.fedorapeople.org/repos/luya/gimp/

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/

[Kevin Kofler]

Nicu Buculei wrote:
>  And we the people using it for real work still remember the times
> when
>  Fedora used to be a bleeding edge distro and had such GIMP updated... 
+1

The new update strategy (because it IS new, contrary to what some lazy 
maintainers who always refused to follow the old policy out of sheer 
laziness are claiming) just makes no sense, is the exact opposite of what 
more than ⅔ of our users are asking for (see the FedoraForum poll on the 
subject, made prior to the change) and is destroying what used to be a major 
selling point for Fedora.

It is also utterly ridiculous and pointless if you consider the fact that 
the Firefox maintainers are allowed to push major (first digit! Not minor 
like 2.6 to 2.8) version increments as "security" updates… (Ironically, 
Firefox used to be one of those odd packages NOT doing feature upgrades when 
the rest of the distro was getting them. They seem to have fun always doing 
the exact opposite of Fedora policy.)

        Kevin Kofler

[Gerald Henriksen]

On Wed, 24 Aug 2011 13:41:41 +0200, you wrote:

> Nicu Buculei wrote:
> > And we the people using it for real work still remember the times when
> > Fedora used to be a bleeding edge distro and had such GIMP updated...
>
> +1
>
> The new update strategy (because it IS new, contrary to what some lazy 
> maintainers who always refused to follow the old policy out of sheer 
> laziness are claiming) just makes no sense, is the exact opposite of what 
> more than ? of our users are asking for (see the FedoraForum poll on the 
> subject, made prior to the change) and is destroying what used to be a major 
> selling point for Fedora. 
In addition to the warning that Gimp 2.7.* is considered unstable and
not to be used in production (aka in a distribution), it comes with a
warning that they are cleaning up the API's and thus 3rd party plugins
and scripts can be broken.

So you are saying Fedora should go against the wishes of the Gimp
developers, as well as endure the significant risk that
plugins/scripts that users rely on may not work?

> It is also utterly ridiculous and pointless if you consider the fact
> that 
> the Firefox maintainers are allowed to push major (first digit! Not minor 
> like 2.6 to 2.8) version increments as "security" updates… (Ironically, 
> Firefox used to be one of those odd packages NOT doing feature upgrades when 
> the rest of the distro was getting them. They seem to have fun always doing 
> the exact opposite of Fedora policy.) 
It's not the Firefox maintainers, it is Mozilla who have decided that
release numbers are irrelevant and that the bug fix release for
Firefox 5 is Firefox 6.

[Genes MailLists]

  It could be built to be installed in parallel with 2.6 - which would
allow those who want to test/play with it.

[Richard Shaw]

On Wed, Aug 24, 2011 at 9:33 AM, Genes MailLists <lists(a)sapience.com&gt; wrote:
>   It could be built to be installed in parallel with 2.6 - which
> would
>  allow those who want to test/play with it. 
The other option is for someone to build packages and host them on
fedorapeople.org as a personal repository.

I certainly wouldn't mind trying 2.7+ but I would like the ability to
easily revert if I run into problems.

Richard

[Jeffrey Ollie]

On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  On Wed, Aug 24, 2011 at 9:33 AM, Genes MailLists
> <lists(a)sapience.com&gt; wrote:
> >  It could be built to be installed in parallel with 2.6 - which would
> > allow those who want to test/play with it.
>
>  The other option is for someone to build packages and host them on
>  fedorapeople.org as a personal repository.
>
>  I certainly wouldn't mind trying 2.7+ but I would like the ability to
>  easily revert if I run into problems. 
You mean something like this?

http://repos.fedorapeople.org/repos/luya/gimp/

-- 
Jeff Ollie

[Richard Shaw]

On Wed, Aug 24, 2011 at 11:48 AM, Jeffrey Ollie <jeff(a)ocjtech.us&gt; wrote:
>  On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw
> <hobbes1069(a)gmail.com&gt; wrote:
> > The other option is for someone to build packages and host them on
> > fedorapeople.org as a personal repository.
> >
> > I certainly wouldn't mind trying 2.7+ but I would like the ability to
> > easily revert if I run into problems.
>
>  You mean something like this?
>
>  http://repos.fedorapeople.org/repos/luya/gimp/ 
Yup! It's at 2.7.2, but I'm downloading the SRPM to updated it to 2.7.3...

Richard

[Richard Shaw]

On Wed, Aug 24, 2011 at 1:17 PM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
>  On Wed, Aug 24, 2011 at 11:48 AM, Jeffrey Ollie
> <jeff(a)ocjtech.us&gt; wrote:
> > On Wed, Aug 24, 2011 at 9:36 AM, Richard Shaw <hobbes1069(a)gmail.com&gt; wrote:
> >> The other option is for someone to build packages and host them on
> >> fedorapeople.org as a personal repository.
> >>
> >> I certainly wouldn't mind trying 2.7+ but I would like the ability to
> >> easily revert if I run into problems.
> >
> > You mean something like this?
> >
> > http://repos.fedorapeople.org/repos/luya/gimp/
>
>  Yup! It's at 2.7.2, but I'm downloading the SRPM to updated it to 2.7.3...
I've got builds of 2.7.3 based on the SRPM from the above link.

http://hobbes1069.fedorapeople.org/gimp/

Richard

[Luya Tshimbalanga]

>  > You mean something like this?
>  >
>  > http://repos.fedorapeople.org/repos/luya/gimp/ 
That repo is updated to 2.7.3.

Regards,

Luya

[Kevin Kofler]

Gerald Henriksen wrote:
>  In addition to the warning that Gimp 2.7.* is considered unstable
> and
>  not to be used in production (aka in a distribution), 
That's why my point is that F16 should ship with 2.6 and get upgraded to 2.8 
once it is stable.

>  it comes with a warning that they are cleaning up the API's and
> thus 3rd
>  party plugins and scripts can be broken. 
That might be a problem though…

But then again those Firefox "security updates" are also breaking 3rd-party 
extensions.

>  It's not the Firefox maintainers, it is Mozilla who have decided
> that
>  release numbers are irrelevant and that the bug fix release for
>  Firefox 5 is Firefox 6. 
If Firefox were following the update policy, they'd backport the security 
fixes, not push the new versions.

And it's not just release NUMBERS which are "irrelevant" for upstream,
it's 
the whole concept of release cycles and stable branches. They'll just throw 
together feature upgrades and security fixes the way they feel like. Now I 
don't really have anything against this (see also the next paragraph), but 
you have to understand that the change is definitely not only about numbers, 
the numbering changed for a reason. The new versions really CAN contain new 
major version material. (But they don't necessarily do, Mozilla is just 
always incrementing the same integer no matter what they actually changed.)

Now, don't get me wrong, I think pushing the Firefox upgrades is actually a 
GOOD thing, but I think this should be the general rule in Fedora and not an 
exception for Firefox alone!

        Kevin Kofler

[Rahul Sundaram]

On 08/25/2011 04:56 AM, Kevin Kofler wrote:
>  If Firefox were following the update policy, they'd backport the
> security 
>  fixes, not push the new versions. 
That is just not true

https://fedoraproject.org/wiki/Updates_Policy#Security_fixes

"If upstream does not provide security fixes for a particular release,
and if backporting the fix would be impractical, then a package may be
rebased onto a version that upstream supports. The definition of
practicality is left to the judgement of FESCO and the packager. "

Rahul

[Petr Machata]

Kevin Kofler <kevin.kofler(a)chello.at&gt; writes:

> > It's not the Firefox maintainers, it is Mozilla who have
> decided that
> > release numbers are irrelevant and that the bug fix release for
> > Firefox 5 is Firefox 6.
>
>  If Firefox were following the update policy, they'd backport the security 
>  fixes, not push the new versions. 
Is that actually possible?  I seem to recall that the reason why Firefox
can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is
that we ship vanilla upstream.

PM

[Petr Machata]

Petr Machata <pmachata(a)redhat.com&gt; writes:

>  Kevin Kofler <kevin.kofler(a)chello.at&gt; writes:
>
> >> It's not the Firefox maintainers, it is Mozilla who have decided that
> >> release numbers are irrelevant and that the bug fix release for
> >> Firefox 5 is Firefox 6.
> >
> > If Firefox were following the update policy, they'd backport the security 
> > fixes, not push the new versions.
>
>  Is that actually possible?  I seem to recall that the reason why Firefox
>  can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is
>  that we ship vanilla upstream. 
(Not that this would be sufficient grounds for breaking the policy, of
course.)

PM

[Kevin Kofler]

Petr Machata wrote:
>  Is that actually possible?  I seem to recall that the reason why
> Firefox
>  can be called Firefox in Fedora, and not, say, Iceweasel or whatever, is
>  that we ship vanilla upstream. 
I have always said that if we can't ship Firefox with that name while 
following the Fedora policies, the right thing to do is to just rename it, 
not give it exceptions to our policies.

In particular, I find it unacceptable that the packages in the Mozilla stack 
are the ONLY packages to which provenpackagers can't commit. And that 
Firefox repeatedly gets permission to bundle some libraries only because 
upstream refuses to support using the system version, even though it would 
work just fine. And so on…

        Kevin Kofler

[Rahul Sundaram]

On 08/24/2011 05:11 PM, Kevin Kofler wrote:
>  It is also utterly ridiculous and pointless if you consider the fact
>  that the Firefox maintainers are allowed to push major (first digit!
>  Not minor like 2.6 to 2.8) version increments as "security" updates…
>  (Ironically, Firefox used to be one of those odd packages NOT doing
>  feature upgrades when the rest of the distro was getting them. They
>  seem to have fun always doing the exact opposite of Fedora policy.) 
I am sure you know better.  Mozilla changed their release scheme. 
Blaming Fedora Firefox maintainers for that is just silly.   Claiming
this is being done for fun is insulting.  Stop doing that.

Rahul

[Nils Philippsen]

On Wed, 2011-08-24 at 10:15 +0300, Nicu Buculei wrote:
>  On 08/23/2011 11:34 PM, Itamar Reis Peixoto wrote:
>  > On Tue, Aug 23, 2011 at 5:24 PM, Richard Shaw wrote:
>  >> On Tue, Aug 23, 2011 at 11:50 AM, Genes MailLists wrote:
>  >>>
>  >>>   Are there any plans to bring gimp 2.7.x ->  2.8 into F16 ?
>  >>
>  >> Is there a specific reason to? The home page states that the whole
>  >> 2.7.x series should be considered unstable.
>  >
>  > is this a good reason ?
>  >
>  >
> http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...
>  
>  No, that single window mode is not such a good reason, the feature is... 
>  cute but not excessively useful, the real reason is the 2.8 release is 
>  long overdue (expected since last December) and quite a few features 
>  were added: more gegl integration, better usability, linked layers etc.
>  And we the people using it for real work still remember the times when 
>  Fedora used to be a bleeding edge distro and had such GIMP updated... 
>  happy old times... 
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.

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.

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).

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

[Genes MailLists]

On 08/25/2011 10:28 AM, Nils Philippsen wrote:

>  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  

  I really wish developers would not do that - every app should be
installable in <path>/app-name-version - and then we use something  like
the alternates system (soft links) to get the version we want to run ...
we should require this of every app in my view ...

[Miloslav Trmač]

On Thu, Aug 25, 2011 at 5:58 PM, Genes MailLists <lists(a)sapience.com&gt; wrote:
>  On 08/25/2011 10:28 AM, Nils Philippsen wrote:
>
> > 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
>
>   I really wish developers would not do that - every app should be
>  installable in <path>/app-name-version - and then we use something  like
>  the alternates system (soft links) to get the version we want to run ...
>  we should require this of every app in my view ... 
That only helps if you are the
system administrator of the system and
if you know about alternatives.  Ordinary users are at mercy of either
their system administrator, or the distribution author.
   Mirek

[Genes MailLists]

On 08/25/2011 12:00 PM, Miloslav Trmač wrote:
>  On Thu, Aug 25, 2011 at 5:58 PM, Genes MailLists
> <lists(a)sapience.com&gt; wrote:
> > On 08/25/2011 10:28 AM, Nils Philippsen wrote:
> >
> >> 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
> >
> >  I really wish developers would not do that - every app should be
> > installable in <path>/app-name-version - and then we use something  like
> > the alternates system (soft links) to get the version we want to run ...
> > we should require this of every app in my view ...
>  That only helps if you are the system administrator of the system and
>  if you know about alternatives.  Ordinary users are at mercy of either
>  their system administrator, or the distribution author.
>     Mirek 
  If an app is installable in its own area - it can just as well be
/home/foo/ ... just put link (or script or whatever is needed) to have
the app know where its base is).

[Daniel P. Berrange]

On Thu, Aug 25, 2011 at 11:58:29AM -0400, Genes MailLists wrote:
>  On 08/25/2011 10:28 AM, Nils Philippsen wrote:
>  
>  > 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 
>  
>    I really wish developers would not do that - every app should be
>  installable in <path>/app-name-version - and then we use something  like
>  the alternates system (soft links) to get the version we want to run ...
>  we should require this of every app in my view ... 
The GIMP developers do not prevent that. You can easily install
multiple versions of GIMP in their own <path>/$appname-$version.
GIMP is acutally better than most, because it also uses a versioned
directory in $HOME/.gimp-X.Y  for preferences, so a new install
does not fubar the preferences of an old install & vica-verca.
It is simply that the Fedora policy is to always install apps
into a fixed /usr location, and not /opt/$appname-$version or
anything like that.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

[Nils Philippsen]

On Thu, 2011-08-25 at 11:58 -0400, Genes MailLists wrote:
>  On 08/25/2011 10:28 AM, Nils Philippsen wrote:
>  
>  > 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 
>  
>  
>    I really wish developers would not do that - every app should be
>  installable in <path>/app-name-version - and then we use something  like
>  the alternates system (soft links) to get the version we want to run ...
>  we should require this of every app in my view ... 
Side-by-side means into the same prefix. You can only have one gimp
version installed into the /usr prefix, you're free to install a
different one into /opt/gimp-x.y or somewhere into your home if you're
an ordinary user.

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

[Genes MailLists]

On 08/25/2011 01:18 PM, Nils Philippsen wrote:

>  
>  Side-by-side means into the same prefix. You can only have one gimp
>  version installed into the /usr prefix, you're free to install a
>  different one into /opt/gimp-x.y or somewhere into your home if you're
>  an ordinary user.
>  
>  Nils 
 Ah thats better .. thanks :-)

[Nicu Buculei]

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.

>  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.

>  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.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com/

[Nils Philippsen]

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(a)redhat.com&gt; - 2:2.4.0-1
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 2:2.4.0-0.rc3.2
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 2:2.4.0-0.rc3.1
...
* Fri Sep 07 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 2:2.4.0-0.rc2.2
...
* Tue Sep 04 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 2:2.4.0-0.rc2.1
...
* Thu Aug 16 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 2:2.4.0-0.rc1.1
...
* Fri Jul 13 2007 Nils Philippsen <nphilipp(a)redhat.com&gt; - 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(a)redhat.com       nor Safety."  --  Benjamin Franklin, 1759
PGP fingerprint:      C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011

[Matthew Miller]

On Tue, Aug 23, 2011 at 05:34:00PM -0300, Itamar Reis Peixoto wrote:
>  is this a good reason ?
>
> http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...
That's a great example of what shouldn't happen _inside_ a release. New
releases come out twice a year -- we shouldn't release updates with huge UI
changes to the already-out versions.

It might be time to start working on getting the update into rawhide,
targetted for F16 or F17.

-- 
Matthew Miller <mattdm(a)mattdm.org&gt;
Senior Systems Architect -- Instructional & Research Computing Services
Harvard School of Engineering & Applied Sciences

[Nils Philippsen]

On Thu, 2011-08-25 at 21:29 -0400, Matthew Miller wrote:
>  On Tue, Aug 23, 2011 at 05:34:00PM -0300, Itamar Reis Peixoto wrote:
>  > is this a good reason ?
>  >
> http://tech.slashdot.org/story/11/08/23/1355225/The-GIMP-Now-Has-a-Workin...
>  
>  That's a great example of what shouldn't happen _inside_ a release. New
>  releases come out twice a year -- we shouldn't release updates with huge UI
>  changes to the already-out versions. 
The single window mode is optional, but not the default.

>  It might be time to start working on getting the update into
> rawhide,
>  targetted for F16 or F17. 
F17 is my guess. Despite any possible (minor) UI changes, I'll probably
have to rebase in F-15/6 then if we want to get bugfixes because (core)
upstream pretty much ignores the 2.6.x branch.

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