Tomboy for FC6 not being updated... why?

[Valent Turkovic]

I use Tomboy all the time on my work FC6 and my home F7 and I didn't
check before but I now noticed that Tomboy on FC6 is still 0.4.1 version
when in F7 it is 0.6 version.

Tomboy 0.7.1 version came out recently... so my question is this: is
there a reason or some policy why Tomboy on FC6 is leftout from being
updated to some newer version?

Thank you,
Valent.

[Nicu Buculei]

Valent Turkovic wrote:
>  I use Tomboy all the time on my work FC6 and my home F7 and I
> didn't
>  check before but I now noticed that Tomboy on FC6 is still 0.4.1 version
>  when in F7 it is 0.6 version.
>  
>  Tomboy 0.7.1 version came out recently... so my question is this: is
>  there a reason or some policy why Tomboy on FC6 is leftout from being
>  updated to some newer version? 
Tomboy is not a stand-alone application, it is part of the GNOME 
Desktop, so its version will match your GNOME version.

On top of that, 0.7.1 is an unstable version.

Use the development branch if you want such cutting-edge versions of 
your applications.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

[Valent Turkovic]

Nicu thank you for your answer.

On Thu, 2007-07-12 at 11:35 +0300, Nicu Buculei wrote:
>  
>  Tomboy is not a stand-alone application, it is part of the GNOME 
>  Desktop, so its version will match your GNOME version. 
I didn't know that.
So do you know how tomboy releases match gnome releases?

>  On top of that, 0.7.1 is an unstable version.
>   
Yes, but tomboy 0.6.3 is a stable one.

>  Use the development branch if you want such cutting-edge versions of
>
>  your applications.  
Oh, so you are saying that in FC6 devel repository I can find a newer
version of Tomboy? I'm off the to look for it... thank you.

Hm, why does yum spit out errors when I try to enable
extras-developement repository? Do extras exist for FC6 or are they also
meing merged to core as in F7?

[Nicu Buculei]

Valent Turkovic wrote:
>  Nicu thank you for your answer.
>  
>  I didn't know that.
>  So do you know how tomboy releases match gnome releases? 
 From their FTP site:
GNOME 2.16 -> Tomboy 0.4.1
http://ftp.gnome.org/pub/GNOME/desktop/2.16/2.16.3/sources/
Gnome 2.18 -> Tomboy 0.6.3
http://ftp.gnome.org/pub/GNOME/desktop/2.18/2.18.3/sources/

Normally, being part of the desktop, Tomboy should adopt the same 
numbering scheme, but this is up to their developers.

> > On top of that, 0.7.1 is an unstable version.
>  
>  Yes, but tomboy 0.6.3 is a stable one. 
I have not checked this, but it may have dependence on certain versions 
of other GNOME/GTK+ libraries

> > Use the development branch if you want such cutting-edge versions
> of 
> > your applications. 
>  
>  Oh, so you are saying that in FC6 devel repository I can find a newer
>  version of Tomboy? I'm off the to look for it... thank you. 
There is no such thing as FC6 devel repo, there is only one devel repo 
and it is heading to Fedora 8

>  Hm, why does yum spit out errors when I try to enable
>  extras-developement repository? Do extras exist for FC6 or are they also
>  meing merged to core as in F7? 
After the merger, Extras still exists only for older releases, not for 
current or development.

-- 
nicu :: http://nicubunu.ro :: http://nicubunu.blogspot.com
Cool Fedora wallpapers: http://fedora.nicubunu.ro/wallpapers/
Open Clip Art Library: http://www.openclipart.org
my Fedora stuff: http://fedora.nicubunu.ro

[Valent Turkovic]

On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote:
>  I have not checked this, but it may have dependence on certain
>  versions 
>  of other GNOME/GTK+ libraries  
I have abandoned my attempts to compile tomboy 0.6.3 and 0.7.1 from
source because that gave me too much dependency errors!

I installed tomboy 0.7.1 from developement repository without any
dependencies and it works great!

Now even conduit works with it an I can sync my notes across different
machines and different users! I love it!

if you have FC6 and want new tomboy just do this as root:

yum update tomboy --enablerepo=development

[Valent Turkovic]

On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote:
>  I have not checked this, but it may have dependence on certain
>  versions 
>  of other GNOME/GTK+ libraries  
Just a followup:
http://kernelreloaded.blog385.com/index.php/archives/howto-install-latest...

tinyurl:
http://tinyurl.com/273mxo

[Rahul Sundaram]

Valent Turkovic wrote:
>  On Thu, 2007-07-12 at 12:16 +0300, Nicu Buculei wrote:
> > I have not checked this, but it may have dependence on certain
> > versions 
> > of other GNOME/GTK+ libraries 
>  
>  Just a followup:
>
> http://kernelreloaded.blog385.com/index.php/archives/howto-install-latest...
>   
Note that development repository is headed for the next release and in 
general is not a good place to get later versions. If tomboy depends on 
newer GNOME development libraries which can happen at any point of time 
the yum command on your blog will result in breakage. Many other 
packages might also have debug options enabled which will slow down 
performance. Fair warning.

Rahul

[Brian Pepple]

On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote:
>  I use Tomboy all the time on my work FC6 and my home F7 and I
> didn't
>  check before but I now noticed that Tomboy on FC6 is still 0.4.1 version
>  when in F7 it is 0.6 version.
>  
>  Tomboy 0.7.1 version came out recently... so my question is this: is
>  there a reason or some policy why Tomboy on FC6 is leftout from being
>  updated to some newer version? 
FC6 isn't rawhide. IMO the only updates to FC6 should be security
related.

Later,
/B
-- 
Brian Pepple <bpepple(a)fedoraproject.org&gt;

http://fedoraproject.org/wiki/BrianPepple
gpg --keyserver pgp.mit.edu --recv-keys 810CC15E
BD5E 6F9E 8688 E668 8F5B  CBDE 326A E936 810C C15E

[Christopher Aillon]

Brian Pepple wrote:
>  On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote:
> > I use Tomboy all the time on my work FC6 and my home F7 and I didn't
> > check before but I now noticed that Tomboy on FC6 is still 0.4.1 version
> > when in F7 it is 0.6 version.
> > 
> > Tomboy 0.7.1 version came out recently... so my question is this: is
> > there a reason or some policy why Tomboy on FC6 is leftout from being
> > updated to some newer version?
>  
>  FC6 isn't rawhide. IMO the only updates to FC6 should be security
>  related. 
Agreed.  And that should happen for F7 as well at some point, too... 
though I suppose it's not entirely clear when that ought to happen.

[Jon Ciesla]

>  Brian Pepple wrote:
> > On Thu, 2007-07-12 at 09:57 +0200, Valent Turkovic wrote:
> >> I use Tomboy all the time on my work FC6 and my home F7 and I didn't
> >> check before but I now noticed that Tomboy on FC6 is still 0.4.1
> >> version
> >> when in F7 it is 0.6 version.
> >>
> >> Tomboy 0.7.1 version came out recently... so my question is this: is
> >> there a reason or some policy why Tomboy on FC6 is leftout from being
> >> updated to some newer version?
> >
> > FC6 isn't rawhide. IMO the only updates to FC6 should be security
> > related.
>
>  Agreed.  And that should happen for F7 as well at some point, too...
>  though I suppose it's not entirely clear when that ought to happen. 
My understanding was that updates, both security-related and
non-security-related would continue for F-N until F-N+1 was released.  At
that point, F-N would join F-N-1 in a security-only mode until EOL. 
People expect churn on Fedora, so stay on the bleeding edge (not so
bleeding as rawhide, mind you). Is that not correct?

>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
novus ordo absurdum

[Jesse Keating]

On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote:
>  My understanding was that updates, both security-related and
>  non-security-related would continue for F-N until F-N+1 was released.  At
>  that point, F-N would join F-N-1 in a security-only mode until EOL.
>  People expect churn on Fedora, so stay on the bleeding edge (not so
>  bleeding as rawhide, mind you). Is that not correct? 
Well, since the old end of life was F-N+2 Test2, we talked about making /that/ 
the security only point and the no new packages point.  We could move it back 
to F-N but that is a short time frame, 6 months.  Something to re-visit in 
FESCo

-- 
Jesse Keating
Release Engineer: Fedora

[Ralf Corsepius]

On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote:
>  On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote:
>  > My understanding was that updates, both security-related and
>  > non-security-related would continue for F-N until F-N+1 was released.  At
>  > that point, F-N would join F-N-1 in a security-only mode until EOL.
>  > People expect churn on Fedora, so stay on the bleeding edge (not so
>  > bleeding as rawhide, mind you). Is that not correct?
>  
>  Well, since the old end of life was F-N+2 Test2, we talked about making /that/ 
>  the security only point and the no new packages point. 
Well, IMO, Fedora's
purpose should be "stable while following upstream
without API/ABI breakages of existing packages". 

In practice, this means "frequent updates", "adopt early", "fix
ASAP" ("fixed rawhide" and "fixed upstream" should be banned in
Fedora)
on a "stable foundation (API/ABIs)". 

It's one fundamental point rendering Fedora interesting. Another one
closely related to it is "exposure of user-contributed/developed
packages".

IMO, users wanting a "security-only updated" distro should probably
better choose EPEL or an even more "boring" Linux distro.

Ralf

[Till Maas]

On Do Juli 12 2007, Ralf Corsepius wrote:

>  Well, IMO, Fedora's purpose should be "stable while
> following upstream
>  without API/ABI breakages of existing packages".
>
>  In practice, this means "frequent updates", "adopt early", "fix
>  ASAP" ("fixed rawhide" and "fixed upstream" should be banned in
> Fedora)
>  on a "stable foundation (API/ABIs)".
>
>  It's one fundamental point rendering Fedora interesting. Another one
>  closely related to it is "exposure of user-contributed/developed
>  packages".
>
>  IMO, users wanting a "security-only updated" distro should probably
>  better choose EPEL or an even more "boring" Linux distro. 
I agree totally,

regards,
Till

[Jon Ciesla]

>  On Do Juli 12 2007, Ralf Corsepius wrote:
>
> > Well, IMO, Fedora's purpose should be "stable while following upstream
> > without API/ABI breakages of existing packages".
> >
> > In practice, this means "frequent updates", "adopt early",
> "fix
> > ASAP" ("fixed rawhide" and "fixed upstream" should be banned
> in Fedora)
> > on a "stable foundation (API/ABIs)".
> >
> > It's one fundamental point rendering Fedora interesting. Another one
> > closely related to it is "exposure of user-contributed/developed
> > packages".
> >
> > IMO, users wanting a "security-only updated" distro should probably
> > better choose EPEL or an even more "boring" Linux distro.
>
>  I agree totally, 
+1

>  regards,
>  Till
>
>  --
>  fedora-devel-list mailing list
>  fedora-devel-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-devel-list
>  

-- 
novus ordo absurdum

[Christopher Aillon]

Ralf Corsepius wrote:
>  On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote:
> > On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote:
> > > My understanding was that updates, both security-related and
> > > non-security-related would continue for F-N until F-N+1 was released.  At
> > > that point, F-N would join F-N-1 in a security-only mode until EOL.
> > > People expect churn on Fedora, so stay on the bleeding edge (not so
> > > bleeding as rawhide, mind you). Is that not correct?
> > 
> > Well, since the old end of life was F-N+2 Test2, we talked about making /that/ 
> > the security only point and the no new packages point.
>  Well, IMO, Fedora's purpose should be "stable while following upstream
>  without API/ABI breakages of existing packages".  
But we also practice don't fix what isn't broken.  This is one of the 
reasons we don't force mass rebuilds of all packages for each release: 
packages are a known quantity and changing them might fix some bugs but 
break other things.  I get this in Firefox updates all the time, and 
those _are_ security fixes.  I'd bet other packages do as well.

If someone files a bug which happens to be fixed in the latest stable 
upstream, feel free to take the version bump if you think it's right. 
But don't simply assume that users are seeing the bug when the version 
bump can introduce more problems than it fixes (how many times have we 
seen various upstreams make a release only to follow it up with a new 
release the next day to correct "serious problems"?  updates-testing 
helps here, but that assumes that users of your package use 
updates-testing which we cannot guarantee).

[Kevin Kofler]

Christopher Aillon <caillon <at> redhat.com> writes:
>  If someone files a bug which happens to be fixed in the latest stable
>
>  upstream, feel free to take the version bump if you think it's right. 
>  But don't simply assume that users are seeing the bug when the version 
>  bump can introduce more problems than it fixes (how many times have we 
>  seen various upstreams make a release only to follow it up with a new 
>  release the next day to correct "serious problems"?  updates-testing 
>  helps here, but that assumes that users of your package use 
>  updates-testing which we cannot guarantee). 
But your suggestion assumes users actually file the bugs they're seeing, which 
unfortunately we cannot guarantee either.

Also, new versions often come with nice new features. For example, XChat 2.8.4 
can now save the scrollback buffer for the session and display it as context 
the next time you open that chan or dialog window. The KDE 3.5.x updates also 
came with small feature additions like that.

        Kevin Kofler

[Rahul Sundaram]

Kevin Kofler wrote:
  The KDE 3.5.x updates also
>  came with small feature additions like that.
>   
It also broke IMAP filters in Kmail. Robustness is a factor to consider 
when pushing updates. Sometimes the advantages of new features are 
outweighed by new bugs.

Rahul

[Kevin Kofler]

Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
>  It also broke IMAP filters in Kmail. 
I know. I was fully aware of this regression, as were Than and Rex, we decided 
to push the update anyway in the KDE SIG meeting because we all felt the 
benefits of the update outweighed the regressions we knew about. Maybe we could 
have handled this in some better way (how? unpushing the update which was 
already in the buildroots (dist-fc7-override) and causing lots of chaos? 
letting the update and all the updates built against it stay in testing for 
weeks (until we have a fix)? pushing only portions of 3.5.7 (like kdelibs) and 
not others (like kdepim)?), but this regression wasn't a surprise to us.

        Kevin Kofler

[Till Maas]

On Fr Juli 13 2007, Kevin Kofler wrote:

>  I know. I was fully aware of this regression, as were Than and Rex,
> we
>  decided to push the update anyway in the KDE SIG meeting because we all
>  felt the benefits of the update outweighed the regressions we knew about.
>  Maybe we could have handled this in some better way (how? unpushing the 
Is this about the KDE 3.5.7 update? In this case, you could habe included this 
information in the update announce mail.

Regards,
Till

[Rahul Sundaram]

Kevin Kofler wrote:
>  Rahul Sundaram <sundaram <at> fedoraproject.org> writes:
> > It also broke IMAP filters in Kmail.
>  
>  I know. I was fully aware of this regression, as were Than and Rex, we decided 
>  to push the update anyway in the KDE SIG meeting because we all felt the 
>  benefits of the update outweighed the regressions we knew about 
I migrated to Thunderbird in the system I was using Kmail on because 
receiving thousands of mails on the inbox instead of carefully filtered 
mails into dozens of folders was completely unacceptable to me. I might 
take filtering out of mail clients entirely and I am planning to use pan 
and gmane since that appears to be the better path atleast for fedora 
lists but neverthless I don't think the decision to let this into 
regression knowingly into updates was a right one. I went back and read 
after this happened the KDE SIG meeting minutes and it was very 
surprising to me that the team would have made such a decision. Not to 
harp on KDE SIG but it does seem that we don't value robustness as much 
as we should for updates in general and that is worrisome to me as I 
rely on Fedora everyday as a end user to get work done.

Rahul

[Nicolas Mailhot]

Le Ven 13 juillet 2007 09:50, Rahul Sundaram a écrit :
>  Not to
>  harp on KDE SIG but it does seem that we don't value robustness as
>  much
>  as we should for updates in general and that is worrisome to me as I
>  rely on Fedora everyday as a end user to get work done. 
There is a worrying tendency to systematically push updates to every
Fedora version under the sun. Fedora-devel is supposed to get this
stuff and spend a few months stabilizing it before the next Fedora
release. Users that want the latest and greatest should use devel.
Users that want regular releases + some bleeding-edge enhancements
should selectively install rawhide packages. Users that just want to
use stable Fedora releases without worrying about compatibility
breakage between release bumps should be entitled to configure
stable+updates without needing any dangerous update filtering.

The argument is always "but if I'm the only one doing this I'm not
destabilising Fedora too much, and the result is less user-hostile
than Devel". It's basic premise is wrong - why should other packagers
restrict themselves just so some can go update-happy safely? And if
they don't restrict themselves, how stable is the result going to be?

If users are not getting new versions fast enough the Fedora cycle
needs to be shortened, not bypassed. If it's not possible to shorten
the cycle while preserving stability, how is delivering rawhide bits
piecemeal without any devel staging is going to be any more stable and
user-friendly?

Fedora is merged now. Cycle length is in the community's hand. There's
no need to workaround a RedHat-controlled cycle length like in the
Fedora Core  + Third party repositories days. If needs be we can add
RHEL-like in-cycle coordinated (& tested) minor release pushes.
Anything that strengths the "RHEL alpha" perception that turns out
vast numbers of potential users is bad for the project.

-- 
Nicolas Mailhot

[Ralf Corsepius]

On Thu, 2007-07-12 at 13:31 -0400, Christopher Aillon wrote:
>  Ralf Corsepius wrote:
>  > On Thu, 2007-07-12 at 09:52 -0400, Jesse Keating wrote:
>  >> On Thursday 12 July 2007 09:43:08 Jon Ciesla wrote:
>  >> > My understanding was that updates, both security-related and
>  >> > non-security-related would continue for F-N until F-N+1 was released.  At
>  >> > that point, F-N would join F-N-1 in a security-only mode until EOL.
>  >> > People expect churn on Fedora, so stay on the bleeding edge (not so
>  >> > bleeding as rawhide, mind you). Is that not correct?
>  >> 
>  >> Well, since the old end of life was F-N+2 Test2, we talked about making /that/ 
>  >> the security only point and the no new packages point.
>  > Well, IMO, Fedora's purpose should be "stable while following upstream
>  > without API/ABI breakages of existing packages". 
>  
>  But we also practice don't fix what isn't broken. 
Well, ... the crucial
point about this is the definition of
"brokenness".

In practice, many packages contain many (mostly unknown) tiny bugs,
which only hit (and limit a package's usability) on occasion. In most
cases, they are gradually being addressed/fixed by upstream and/or a
package's Fedora maintainer.

The point we are discussing here is: When and how to propagate these
fixes to current users? 

A responsibly acting maintainer will balance between tradeoffs.
In some cases (seemingly most of mine) pushing updates immediately is
possible, in some cases, other issues will outweigh a bugfix.

As a user, to me, the nagging cases however are those Fedora maintainers
who claim to have fixed bugs "rawhide"/"upstream", even in obvious
cases, without having released new packages. 
To put it bluntly, I consider these maintainers to be acting grossly
negligent and them to be harmful to Fedora.

>    This is one of the 
>  reasons we don't force mass rebuilds of all packages for each release: 
>  packages are a known quantity and changing them might fix some bugs but 
>  break other things.  I get this in Firefox updates all the time, and 
>  those _are_ security fixes.  I'd bet other packages do as well. 
This doesn't apply to the packages I maintain. For them, it's primarily
"upstream finds+fixes bugs", no Fedora user has ever reported and fixes
them as part of their on-going upstream development flow (in many cases
in "very simple and obvious" manners).

>  If someone files a bug which happens to be fixed in the latest stable
>
>  upstream, feel free to take the version bump if you think it's right. 
Right,
IMO, "Trying to fix what's known to be broken ASAP" should be the
default policy, but maintainers acting responsibly also should be taken
for granted. 

>  But don't simply assume that users are seeing the bug when the
> version 
>  bump can introduce more problems than it fixes (how many times have we 
>  seen various upstreams make a release only to follow it up with a new 
>  release the next day to correct "serious problems"? 
Right, but .. judging
upon upstream development and letting upstream
work flow back into Fedora in reasonable manners should be a package's
maintainer's task and responsibility.

Changing the workflow in such a way that "Fedora should receive security
updates only" would be silly, IMO.

>    updates-testing 
>  helps here, but that assumes that users of your package use 
>  updates-testing which we cannot guarantee). 
My opinion on "testing"
probably is known ;)

Ralf