Hello,
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
Thanks
Christoph
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
-- Rex
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Eli
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
Eli
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
On Saturday 03 July 2010 08:00:32 Eli Wapniarski wrote:
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote: > just a short question, will there be a kdepim 4.5 beta1 build > for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
Oh... kdepim 4.5 would be a perfect candidate for a "kde-redhat development" repo.
Eli
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Saturday 03 July 2010 08:00:32 Eli Wapniarski wrote:
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote: > Christoph Kaulich wrote: > > just a short question, will there be a kdepim 4.5 beta1 build > > for fc13? > > When it is provided by it's upstream. > > Turns out just yesterday, some preliminary kdepim-4.5-beta1 > tarballs were provided to packagers, so we'll get to work on > those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
Oh... kdepim 4.5 would be a perfect candidate for a "kde-redhat development" repo.
I guess you confuse what is more dangerous for people here. If we put it in rawhide it is then in F-14 (not written in stone, i know). In kde-unstable, *you* decide if you want to test it or not. You will have to deal with kdepim4.5 anyways, if sooner or later, that's your decision.
If you dont want to deal with it now: yum --exclude=foo update
On Saturday 03 July 2010 09:27:28 Thomas Janssen wrote:
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Saturday 03 July 2010 08:00:32 Eli Wapniarski wrote:
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
> On Friday 02 July 2010 18:03:10 Rex Dieter wrote: >> Christoph Kaulich wrote: >> > just a short question, will there be a kdepim 4.5 beta1 build >> > for fc13? >> >> When it is provided by it's upstream. >> >> Turns out just yesterday, some preliminary kdepim-4.5-beta1 >> tarballs were provided to packagers, so we'll get to work on >> those, and get into rawhide and kde-unstable asap. > > Errr.... What does that say about stability? If I recall > correctly there were serious issues with kdepim 4.5 that > delayed the release with kde 4.5. Does that mean the developers > think that they have been resolved? If not is it wise to > include kdepim 4.5 so deep in the release cycle?
Kdepim 4.5 will be released (the final version) together with KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's ready then, what it look like from a todays POV). Means yes, it is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
Oh... kdepim 4.5 would be a perfect candidate for a "kde-redhat development" repo.
I guess you confuse what is more dangerous for people here. If we put it in rawhide it is then in F-14 (not written in stone, i know). In kde-unstable, *you* decide if you want to test it or not. You will have to deal with kdepim4.5 anyways, if sooner or later, that's your decision.
If you dont want to deal with it now: yum --exclude=foo update
Yes, that can be done. But why do we need to deal with something that we know is broken? The kde developers themselves say it isn't ready. So why play with it? When the developers say its ready then... fine.... But until then....
Eli
If you dont want to deal with it now: yum --exclude=foo update
Yes, that can be done. But why do we need to deal with something that we know is broken? The kde developers themselves say it isn't ready. So why play with it? When the developers say its ready then... fine.... But until then....
Eli
How do you know that it is broken? AFAIK, they have taken some time (1 extra month) to fix up the things, so that we get a good quality release. Moreover as told by Rex and Thomas, it will be in Rawhide and Kde-unstable and I think these repositories are for bleeding edge software only. I don't think they will push PIM-4.5 in stable repositories, until its really stable.
Thanks, Anoop
On Sat 3 July 2010 10:02:21 am Eli Wapniarski wrote:
On Saturday 03 July 2010 09:27:28 Thomas Janssen wrote:
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Saturday 03 July 2010 08:00:32 Eli Wapniarski wrote:
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote:
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote: > On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski > eli@orbsky.homelinux.org
wrote: > > On Friday 02 July 2010 18:03:10 Rex Dieter wrote: > >> Christoph Kaulich wrote: > >> > just a short question, will there be a kdepim 4.5 beta1 > >> > build for fc13? > >> > >> When it is provided by it's upstream. > >> > >> Turns out just yesterday, some preliminary kdepim-4.5-beta1 > >> tarballs were provided to packagers, so we'll get to work on > >> those, and get into rawhide and kde-unstable asap. > > > > Errr.... What does that say about stability? If I recall > > correctly there were serious issues with kdepim 4.5 that > > delayed the release with kde 4.5. Does that mean the > > developers think that they have been resolved? If not is it > > wise to include kdepim 4.5 so deep in the release cycle? > > Kdepim 4.5 will be released (the final version) together with > KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's > ready then, what it look like from a todays POV). Means yes, it > is wise to include it in the release cycle of rawhide.
OK then here are my real questions... Will kdepim 4.4 accompany kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not beyond the realm of possibilities given kdepim's 4.x's history and what is already known about kdepim 4.5) then how to downgrade back to 4.4 and not screw up kdepim and akonadi due to all the configuration changes that no doubt will accompany the upgrade to 4.5? As asked previously... Is it wise to include kdepim 4.5 so late in the release cycle when we already know that it isn't going to be included in the final release of kde 4.5? And since I really do not want to run kdepim 4.5 on my computer because I know it doesn't work anywhere close to where it should will I be able to maintain the current kdepim 4.4 with kde 4.5 as things stand at the moment?
Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
Oh... kdepim 4.5 would be a perfect candidate for a "kde-redhat development" repo.
I guess you confuse what is more dangerous for people here. If we put it in rawhide it is then in F-14 (not written in stone, i know). In kde-unstable, *you* decide if you want to test it or not. You will have to deal with kdepim4.5 anyways, if sooner or later, that's your decision.
If you dont want to deal with it now: yum --exclude=foo update
Yes, that can be done. But why do we need to deal with something that we know is broken? The kde developers themselves say it isn't ready. So why play with it? When the developers say its ready then... fine.... But until then....
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta* tarballs!
Eli
Ryan
On Saturday 03 July 2010 10:57:59 Ryan Rix wrote:
On Sat 3 July 2010 10:02:21 am Eli Wapniarski wrote:
On Saturday 03 July 2010 09:27:28 Thomas Janssen wrote:
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski eli@orbsky.homelinux.org
wrote:
On Saturday 03 July 2010 08:00:32 Eli Wapniarski wrote:
On Saturday 03 July 2010 01:36:16 Ryan Rix wrote:
On Fri 2 July 2010 11:02:27 pm Eli Wapniarski wrote: > On Friday 02 July 2010 20:25:33 Thomas Janssen wrote: > > On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski > > eli@orbsky.homelinux.org > > wrote: > > > On Friday 02 July 2010 18:03:10 Rex Dieter wrote: > > >> Christoph Kaulich wrote: > > >> > just a short question, will there be a kdepim 4.5 beta1 > > >> > build for fc13? > > >> > > >> When it is provided by it's upstream. > > >> > > >> Turns out just yesterday, some preliminary kdepim-4.5-beta1 > > >> tarballs were provided to packagers, so we'll get to work > > >> on those, and get into rawhide and kde-unstable asap. > > > > > > Errr.... What does that say about stability? If I recall > > > correctly there were serious issues with kdepim 4.5 that > > > delayed the release with kde 4.5. Does that mean the > > > developers think that they have been resolved? If not is it > > > wise to include kdepim 4.5 so deep in the release cycle? > > > > Kdepim 4.5 will be released (the final version) together with > > KDE SC 4.5.1 or 4.5.2 (of course if the developers think it's > > ready then, what it look like from a todays POV). Means yes, > > it is wise to include it in the release cycle of rawhide. > > OK then here are my real questions... Will kdepim 4.4 accompany > kde 4.5 in unstable? If kdepim 4.5 turns out to be unusable (not > beyond the realm of possibilities given kdepim's 4.x's history > and what is already known about kdepim 4.5) then how to > downgrade back to 4.4 and not screw up kdepim and akonadi due > to all the configuration changes that no doubt will accompany > the upgrade to 4.5? As asked previously... Is it wise to > include kdepim 4.5 so late in the release cycle when we already > know that it isn't going to be included in the final release of > kde 4.5? And since I really do not want to run kdepim 4.5 on my > computer because I know it doesn't work anywhere close to where > it should will I be able to maintain the current kdepim 4.4 > with kde 4.5 as things stand at the moment? > > Rawhide fine.... kde-unstable???? hmmmmm... I dunnoooo.
This is kde-unstable you're talking about right? The same repo that has shipped alphas, betas, and release candidates for every recent SC release? The repo that is designed for those who want to test this software, and has the ability to downgrade and report on any packages which may have issues? *THat* one? If you can't run unstable things, then you shouldn't be running kde- redhat/unstable, sorry.
> Eli
Ryan
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing. And these packages are still in beta and rc status. Again, we are reasonably certain that Beta means beta and RC candidates are rc candidates. There may some bugs, but they work overall. And we usually don't see alpha versions. Besides, kdepim 4.5 is pre alpha. We know that it simply does not work. It doesn't belong there. If I'm not mistaken, kde-redhat is more of a fedora packaging testing environment rather than a kde development environment.
Eli
Oh... kdepim 4.5 would be a perfect candidate for a "kde-redhat development" repo.
I guess you confuse what is more dangerous for people here. If we put it in rawhide it is then in F-14 (not written in stone, i know). In kde-unstable, *you* decide if you want to test it or not. You will have to deal with kdepim4.5 anyways, if sooner or later, that's your decision.
If you dont want to deal with it now: yum --exclude=foo update
Yes, that can be done. But why do we need to deal with something that we know is broken? The kde developers themselves say it isn't ready. So why play with it? When the developers say its ready then... fine.... But until then....
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta* tarballs!
But it isn't going to be released with kde 4.5. Only a later version and we're testing kde 4.5 over here. Not kde 4.5.1 or 2 or whatever.
Eli
On 07/03/2010 09:59 AM, Eli Wapniarski wrote: <snip>
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta* tarballs!
But it isn't going to be released with kde 4.5. Only a later version and we're testing kde 4.5 over here. Not kde 4.5.1 or 2 or whatever.
qt 4.7 is in unstable. It is not going to be released with kde 4.5 either. I think you are missing the point of kde-unstable.
Eli
Patrick Boutilier wrote:
qt 4.7 is in unstable. It is not going to be released with kde 4.5 either. I think you are missing the point of kde-unstable.
Yeah. kde-unstable is basically Rawhide's KDE for released Fedora, so you can test the latest and greatest (and sometimes unstable, that's why it's called "unstable") KDE without all the other, unrelated breakage in Rawhide.
You can cherry-pick stuff from there if you want to test only specific things. It might not always work, and sometimes the exact exclude= or include= lines to use are not obvious, but we try to make it possible, e.g. the KDE 4.5 packages in kde-unstable are built against Qt 4.6, not 4.7.
Kevin Kofler
On Saturday 03 July 2010 16:05:13 Patrick Boutilier wrote:
On 07/03/2010 09:59 AM, Eli Wapniarski wrote:
<snip>
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta* tarballs!
But it isn't going to be released with kde 4.5. Only a later version and we're testing kde 4.5 over here. Not kde 4.5.1 or 2 or whatever.
qt 4.7 is in unstable. It is not going to be released with kde 4.5 either. I think you are missing the point of kde-unstable.
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat. Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
Eli
On Sat, Jul 3, 2010 at 6:56 PM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Saturday 03 July 2010 16:05:13 Patrick Boutilier wrote:
On 07/03/2010 09:59 AM, Eli Wapniarski wrote:
<snip>
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta* tarballs!
But it isn't going to be released with kde 4.5. Only a later version and we're testing kde 4.5 over here. Not kde 4.5.1 or 2 or whatever.
qt 4.7 is in unstable. It is not going to be released with kde 4.5 either. I think you are missing the point of kde-unstable.
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat.
Look Eli, if you want stable or relatively stable, then keep your fingers off of -testing and -unstable in general. Both says clearly what you get. The first stuff you can test with no big risk and the latter *unstable* stuff. Depends on what it is, you might have to deal with crashes and other problems.
If you're not willing/able to deal with it, just keep it *disabled*. That's totally fine. Some people want it, some not.
Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
I really don't understand that. Nothing changed in kde-redhat.
On 07/03/2010 06:56 PM, Eli Wapniarski wrote:
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat. Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
You're not making any sense there, to be honest.
The situation with kdepim is that it won't be ready to be released with KDE 4.5.0, but only a bit later; it is going to be released with 4.5.1 or 4.5.2. Hence kdepim is currently at beta1, while the rest of the KDE SC is already at rc1.
However, kde-unstable has already shipped both KDE SC 4.5 beta1 and beta2 (as well as betas of previous KDE SC releases, including the respective kdepim betas!), so kde-unstable is obviously OK to cary beta-level KDE releases for a long time.
There's a beta of a kdepim release. It's going into kde-unstable. Just like the beta of kdepim 4.4. And 4.3. And 4.2. ...
There's nothing unusual about this, except that the production release of kdepim 4.5 is delayed a bit beyond the release of the rest of the SC.
Eli
On Saturday 03 July 2010 23:43:40 Eike Hein wrote:
On 07/03/2010 06:56 PM, Eli Wapniarski wrote:
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat. Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
You're not making any sense there, to be honest.
The situation with kdepim is that it won't be ready to be released with KDE 4.5.0, but only a bit later; it is going to be released with 4.5.1 or 4.5.2. Hence kdepim is currently at beta1, while the rest of the KDE SC is already at rc1.
However, kde-unstable has already shipped both KDE SC 4.5 beta1 and beta2 (as well as betas of previous KDE SC releases, including the respective kdepim betas!), so kde-unstable is obviously OK to cary beta-level KDE releases for a long time.
There's a beta of a kdepim release. It's going into kde-unstable. Just like the beta of kdepim 4.4. And 4.3. And 4.2. ...
There's nothing unusual about this, except that the production release of kdepim 4.5 is delayed a bit beyond the release of the rest of the SC.
Eli
The fuss is.... The developers are saying that kdepim 4.5 is not ready for prime time and will not be released with kde 4.5. In unstable we have the kde 4.5 packages. We are all testing kde 4.5 not 4.5.1. It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop. Could be they are not part of the mailing list. Or missed the statements that kdepim is not going to be released with 4.5. Now.... lets assume that there are even minor changes to the way kdepim talks to akonadi. The database changes. Queries change. Imap databases get corrupted. Addressbook data gets modified. Now.... rollback. Exactly how does one propse that gets done.
Yes there is the risk that can happen with schedualed for release versions. Its happened already. Hasn't it?
Eli
Eli
On 07/04/2010 01:53 AM, Eli Wapniarski wrote:
On Saturday 03 July 2010 23:43:40 Eike Hein wrote:
On 07/03/2010 06:56 PM, Eli Wapniarski wrote:
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat. Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
You're not making any sense there, to be honest.
The situation with kdepim is that it won't be ready to be released with KDE 4.5.0, but only a bit later; it is going to be released with 4.5.1 or 4.5.2. Hence kdepim is currently at beta1, while the rest of the KDE SC is already at rc1.
However, kde-unstable has already shipped both KDE SC 4.5 beta1 and beta2 (as well as betas of previous KDE SC releases, including the respective kdepim betas!), so kde-unstable is obviously OK to cary beta-level KDE releases for a long time.
There's a beta of a kdepim release. It's going into kde-unstable. Just like the beta of kdepim 4.4. And 4.3. And 4.2. ...
There's nothing unusual about this, except that the production release of kdepim 4.5 is delayed a bit beyond the release of the rest of the SC.
Eli
The fuss is.... The developers are saying that kdepim 4.5 is not ready for prime time and will not be released with kde 4.5. In unstable we have the kde 4.5 packages. We are all testing kde 4.5 not 4.5.1. It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop. Could be they are not part of the mailing list. Or missed the statements that kdepim is not going to be released with 4.5. Now.... lets assume that there are even minor changes to the way kdepim talks to akonadi. The database changes. Queries change. Imap databases get corrupted. Addressbook data gets modified. Now.... rollback. Exactly how does one propse that gets done.
Yes there is the risk that can happen with schedualed for release versions. Its happened already. Hasn't it?
People use kde-unstable on a production desktop? :-)
Eli
Eli
Quoting Patrick Boutilier boutilpj@ednet.ns.ca:
On 07/04/2010 01:53 AM, Eli Wapniarski wrote:
On Saturday 03 July 2010 23:43:40 Eike Hein wrote:
On 07/03/2010 06:56 PM, Eli Wapniarski wrote:
Fine. K. then. I guess I am getting confused. But that means that I will not always know what package goes with what package which means that I will not be able to rely on the relative stability of whats coming out of kde-redhat. Bummer really since I've been with the repo for a very very long time. Bummer, because I won't have the resources to be able to help, what little I can, because I'm never going to be sure of how tight the integration between all the packages are going to be in the repo that they're sitting in. Bummer since kde-redhat has become an extension of the kde release cycle rather than the kde packaged for fedora release cycle. I guess that once 4.5 goes gold I will have to rely only on Fedora's stable packaging. I guess that's OK, because I know that the final product when its finally going to be released is going to be great. Really a bummer for me though, because I have enjoyed very much watching how each full release has progressed over time.
You're not making any sense there, to be honest.
The situation with kdepim is that it won't be ready to be released with KDE 4.5.0, but only a bit later; it is going to be released with 4.5.1 or 4.5.2. Hence kdepim is currently at beta1, while the rest of the KDE SC is already at rc1.
However, kde-unstable has already shipped both KDE SC 4.5 beta1 and beta2 (as well as betas of previous KDE SC releases, including the respective kdepim betas!), so kde-unstable is obviously OK to cary beta-level KDE releases for a long time.
There's a beta of a kdepim release. It's going into kde-unstable. Just like the beta of kdepim 4.4. And 4.3. And 4.2. ...
There's nothing unusual about this, except that the production release of kdepim 4.5 is delayed a bit beyond the release of the rest of the SC.
Eli
The fuss is.... The developers are saying that kdepim 4.5 is not ready for prime time and will not be released with kde 4.5. In unstable we have the kde 4.5 packages. We are all testing kde 4.5 not 4.5.1. It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop. Could be they are not part of the mailing list. Or missed the statements that kdepim is not going to be released with 4.5. Now.... lets assume that there are even minor changes to the way kdepim talks to akonadi. The database changes. Queries change. Imap databases get corrupted. Addressbook data gets modified. Now.... rollback. Exactly how does one propse that gets done.
Yes there is the risk that can happen with schedualed for release versions. Its happened already. Hasn't it?
People use kde-unstable on a production desktop? :-)
Eli
When Rex releases. I trust. Its been that way ever since Redhat 8. So yes, people do (at least I do) use kde-unstable. Mostly because of the amazingly good work initiated by Rex and kde-redhat. And kde 4.5 RC1 works with little if any annoyances. And for me qt 4.7 fixed Akonadi / kontact startup. For me... Rex releases. I trust.
kde-redhat has always been a testing ground for integration previously with redhat and currently with fedora. It is not a QA environment for kde. Please don't turn it into one. My feeling is that it will negatively impact on the number of people willing to install and test initially built packages for fedora. And if the developers themselves are not willing to endorse.
But maybe that's me. Could be that I'm weird :)
Eli
On 7/4/2010 4:34 PM, Eli Wapniarski wrote:
It is not a QA environment for kde.
It's a QA environment for upcoming Fedora releases, since it contains backports from the development branch of Fedora.
kde-unstable's only relationship with production desktops is to make sure future production desktops - i.e., those that will eventually run Fedora 14 - will work smoothly.
On Sunday 04 July 2010 11:37:23 Patrick Boutilier wrote:
People use kde-unstable on a production desktop? :-)
Some, like me, have more than one desktop, and use one for testing, but if you use IMAP mail anything that happens on the test box will affect the rest. I should be able to choose whether I take that risk or not, without simply shutting off all testing packages.
There are genuine issues here. When the developers say so, we should be listening.
I was under the impression that KDE-fedora did actually want us to test packages. Of course we could all play safe and go hom, but is that really what you want?
Anne
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing. Further it creates a feedback loop: People would only even more get the impression that kde-unstable is suitable for production desktops, which would put the KDE SIG under even more pressure to keep it suitable for pro- duction desktops. Thus making the problem even bigger.
This would have bad repercussions for Fedora KDE in at least two ways: Less pre-release testing, and less pressure to do the work to get stuff into the main tree because everyone is using kde-unstable anyway.
I've seen that happen at other distros, were the KDE team or other teams create personal repositories, and lose the discipline to do proper release integration work. It's a downward spiral, let's not let that happen.
Bottom line: Unstable means *unstable*.
Why is everyone so interested in kdepim-4.5? What will it contain that is not in kdepim-4.4?
On Sun, Jul 4, 2010 at 8:06 PM, Timothy Murphy gayleard@eircom.net wrote:
Why is everyone so interested in kdepim-4.5?
Kmail-2.0
What will it contain that is not in kdepim-4.4?
Kmail in PIM-4.5 will use Akonadi.
-Anoop
Quoting Eike Hein hein@kde.org:
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing. Further it creates a feedback loop: People would only even more get the impression that kde-unstable is suitable for production desktops, which would put the KDE SIG under even more pressure to keep it suitable for pro- duction desktops. Thus making the problem even bigger.
This would have bad repercussions for Fedora KDE in at least two ways: Less pre-release testing, and less pressure to do the work to get stuff into the main tree because everyone is using kde-unstable anyway.
I've seen that happen at other distros, were the KDE team or other teams create personal repositories, and lose the discipline to do proper release integration work. It's a downward spiral, let's not let that happen.
Bottom line: Unstable means *unstable*.
Yes it does. But unstable in what context. Sorry about sounding philosophical about this. But if your talking about kdepim 4.5 release in the context of kde development then yes its unstable. If your talking about kdepim 4.5 in terms of fedora release then your talking about unusable. Why... because the developers have said that this is not for release.
Others have pointed out to me that if one needs to test whether a package will build correctly then koji scratch builds are ideal.
Eli
Eli
On 7/4/2010 4:39 PM, Eli Wapniarski wrote:
Why... because the developers have said that this is not for release.
You keep repeating this, and it keeps being untrue. It's a beta release. There's a plan for when the final release can be expected (alongside KDE SC 4.5.1 or 4.5.2). kde- unstable has carried all the other beta-level KDE SC 4.5 packages so far.
If you understand "beta" as "this is not for release" and thus "not for kde-unstable", then kde-unstable should ne- ver carry any KDE SC beta packages. But it has done so for years. Same for Qt betas. Heck, even Qt Technical Previews.
Let's get to the bottom here: You're interested in an ar- bitrary decision being made that suits your personal pre- ference, not making a decision consistent with how kde-un- stable has been run so far and its purpose.
On Sunday 04 July 2010 22:43:11 Eike Hein wrote:
On 7/4/2010 4:39 PM, Eli Wapniarski wrote:
Why... because the developers have said that this is not for release.
You keep repeating this, and it keeps being untrue. It's a beta release. There's a plan for when the final release can be expected (alongside KDE SC 4.5.1 or 4.5.2). kde- unstable has carried all the other beta-level KDE SC 4.5 packages so far.
If you understand "beta" as "this is not for release" and thus "not for kde-unstable", then kde-unstable should ne- ver carry any KDE SC beta packages. But it has done so for years. Same for Qt betas. Heck, even Qt Technical Previews.
Let's get to the bottom here: You're interested in an ar- bitrary decision being made that suits your personal pre- ference, not making a decision consistent with how kde-un- stable has been run so far and its purpose.
Excuse me.... This last part is a bit of troll. But I will repsond. No.. I'm not asking for an arbitrary decision. You are asking for one that breaks with what has been typical for kde-redhat for years. kde-redhat is not a qa environement for kde. It is a qa environment for up and coming releases of kde in (previously) redhat / (now) fedora. We are currently testing 4.5 as RC1 not 4.5.1 (vaporware). To make the correction that you've pointed out. kdepim 4.5 (I wouldn't be surprised to find that the version get bumped up to 4.5.1 as well if it gets released with kde 4.5.1) will not get released until kde 4.5.1 putting kdepim 4.5 along side kde 4.5 breaks the testing environment. And it will generate noise that shouldn't be seen yet. After kde 4.5 gets pushed to testing fine put kdepim 4.5 in unstable; a compromise which I can't stand personally, it would be better to wait until it is packaged with the version that the developers say that its good to go with.
Eli
On 7/4/2010 10:11 PM, Eli Wapniarski wrote:
Excuse me.... This last part is a bit of troll.
And repeatedly implying that KDE SIG members and KDE developers are dishonest about their intentions and referring to KDE SC 4.5.1 as "vaporware" is not a troll?
But I will repsond. No.. I'm not asking for an arbitrary decision. You are asking for one that breaks with what has been typical for kde-redhat for years. kde-redhat is not a qa environement for kde. It is a qa environment for up and coming releases of kde in (previously) redhat / (now) fedora. We are currently testing 4.5 as RC1 not 4.5.1 (vaporware). To make the correction that you've pointed out. kdepim 4.5 (I wouldn't be surprised to find that the version get bumped up to 4.5.1 as well if it gets released with kde 4.5.1) will not get released until kde 4.5.1 putting kdepim 4.5 along side kde 4.5 breaks the testing environment. And it will generate noise that shouldn't be seen yet. After kde 4.5 gets pushed to testing fine put kdepim 4.5 in unstable; a compromise which I can't stand personally, it would be better to wait until it is packaged with the version that the developers say that its good to go with.
Your argument seems to boil down to "the kdepim developers have released a beta, but that beta is not supposed to be tested by anyone, because the KDE release that will be out by the time the kdepim final release is out has not been released yet". Sweet logical fallacy, Batman.
The kdepim 4.5 beta is out now. It's supposed to be used for testing together with KDE SC 4.5 RC1 (because that's what's there now and it's what kdepim has been developed against). That's the combination that Rex intends to put into kde-unstable. That combination consists of pre-re- leases the KDE SIG expects to see in Fedora 14 as final releases.
You've so far completely failed to make a coherent argu- ment as to why kdepim 4.5 beta1 is not supposed to be tested in the same way any other KDE beta release has been when it came out.
Eli
On Sunday 04 July 2010 23:35:27 Eike Hein wrote:
On 7/4/2010 10:11 PM, Eli Wapniarski wrote:
Excuse me.... This last part is a bit of troll.
And repeatedly implying that KDE SIG members and KDE developers are dishonest about their intentions and referring to KDE SC 4.5.1 as "vaporware" is not a troll?
Never did and never would. So please accept and honest and passionate disagreement as this. Believe me when I tell you I would not be dealing with kde-redhat or fedora if I did not believe that I was dealing with honest and intelligent people.
Eli
On Sunday 04 July 2010 20:43:11 Eike Hein wrote:
On 7/4/2010 4:39 PM, Eli Wapniarski wrote:
Why... because the developers have said that this is not for release.
You keep repeating this, and it keeps being untrue. It's a beta release. There's a plan for when the final release can be expected (alongside KDE SC 4.5.1 or 4.5.2). kde- unstable has carried all the other beta-level KDE SC 4.5 packages so far.
If you understand "beta" as "this is not for release" and thus "not for kde-unstable", then kde-unstable should ne- ver carry any KDE SC beta packages. But it has done so for years. Same for Qt betas. Heck, even Qt Technical Previews.
Let's get to the bottom here: You're interested in an ar- bitrary decision being made that suits your personal pre- ference, not making a decision consistent with how kde-un- stable has been run so far and its purpose.
OK, let's have some facts from the horse's mouth.
Thus quoth Allen Winter on the 29th June -
As you are probably aware, kdepim will be withheld from the upcoming KDE SC 4.5 Release.
You should be able to use kdepim 4.4 along with the kdepim 4.4 translations with the rest of KDE SC 4.5; ie. kdepim 4.4 should compile and work with the libraries from kdelibs 4.5 and kdepimlibs 4.5.
We hope to make a production-ready kdepim 4.5 available concurrently with KDE SC 4.5.1 or KDE SC 4.5.2, depending on how well our beta testing goes.
A first beta for kdepim 4.5 will be tagged and a tarball created (and put on the FTP servers) within the next couple days. With the second beta due 2 weeks thereafter.
The schedule is (perhaps overly optimistic): 30 Jun: kdepim 4.5 beta1 15 Jul: kdepim 4.5 beta2 29 Jul: kdepim 4.5 rc1 12 Aug: kdepim 4.5 rc2 26 Aug: kdepim 4.5 final (I believe KDE SC 4.5.1 will also be tagged this day) </quote>
Right, there are the facts. Now can you ensure that we will be able to make our own decision about the degree of risk, or do we go elsewhere?
Anne
Eli Wapniarski wrote:
Yes it does. But unstable in what context. Sorry about sounding philosophical about this. But if your talking about kdepim 4.5 release in the context of kde development then yes its unstable. If your talking about kdepim 4.5 in terms of fedora release then your talking about unusable. Why... because the developers have said that this is not for release.
Nonsense. * It's a beta release. So is most other stuff which goes into kde-redhat unstable (e.g. KDE betas, Qt TPs and betas, application betas etc.). It's called unstable for a reason. * It comes with minor feature regressions compared to what's in the targeted Fedora release. So does most other stuff which goes into kde-redhat unstable (e.g. KDE 4 for F8, Amarok 2, KOffice 2 etc.). It's called unstable for a reason. * It's released on its own schedule, not KDE SC's. So is most other stuff which goes into kde-redhat unstable (e.g. Qt betas, betas of Amarok and other applications etc.). This doesn't make it any more or less stable. kde- redhat unstable is about QA for the next FEDORA relase, NOT the next KDE SC release. It allows you to test ALL new stuff, not just what will be released with the next KDE SC. It has ALWAYS been like that. So how's kdepim 4.5 special?
We will NOT drop kdepim 4.5 from kde-redhat unstable. Please quit wasting our time with that useless discussion!
Kevin Kofler
On Sunday 04 July 2010 15:19:13 Eike Hein wrote:
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
I beg to differ. kde-unstable is branched off into next release and current 2 releases. It is there to test the schedualed to be released as part of the current working versions of Fedora. Otherwise, there would only be a rawhide version (currently F14) which is not the case. kdepim is schedualed never to be released. We may see version 4.5.1. If things go well.
Eli
On Sunday 04 July 2010 19:59:27 Eli Wapniarski wrote:
On Sunday 04 July 2010 15:19:13 Eike Hein wrote:
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
.... kdepim is schedualed never to be released. We may see version 4.5.1. If things go well.
Oops. I meant to say kdepim 4.5 is schedualed never to be released....
Eli
On 7/4/2010 7:02 PM, Eli Wapniarski wrote:
Oops. I meant to say kdepim 4.5 is schedualed never to be released....
No, you misunderstood that. The current kdepim 4.5 beta packages are not a beta for a release that is never going to happen (how would that make *any* sense?). It's a beta for the final release, which is expected alongside 4.5.1 or 4.5.2.
You can read about the schedule here: http://mail.kde.org/pipermail/release-team/2010-June/003956.html
On Sunday 04 July 2010 22:45:26 Eike Hein wrote:
On 7/4/2010 7:02 PM, Eli Wapniarski wrote:
Oops. I meant to say kdepim 4.5 is schedualed never to be released....
No, you misunderstood that. The current kdepim 4.5 beta packages are not a beta for a release that is never going to happen (how would that make *any* sense?). It's a beta for the final release, which is expected alongside 4.5.1 or 4.5.2.
OK... not never.... But you've pretty much made my point. And I quote
And I quote
"We hope to make a production-ready kdepim 4.5 available concurrently with KDE SC 4.5.1 or KDE SC 4.5.2, depending on how well our beta testing goes."
We are currently testing kde 4.5. Not kde 4.5.1
Eli
On 07/04/2010 05:01 PM, Eli Wapniarski wrote:
On Sunday 04 July 2010 22:45:26 Eike Hein wrote:
On 7/4/2010 7:02 PM, Eli Wapniarski wrote:
Oops. I meant to say kdepim 4.5 is schedualed never to be released....
No, you misunderstood that. The current kdepim 4.5 beta packages are not a beta for a release that is never going to happen (how would that make *any* sense?). It's a beta for the final release, which is expected alongside 4.5.1 or 4.5.2.
OK... not never.... But you've pretty much made my point. And I quote
And I quote
"We hope to make a production-ready kdepim 4.5 available concurrently with KDE SC 4.5.1 or KDE SC 4.5.2, depending on how well our beta testing goes."We are currently testing kde 4.5. Not kde 4.5.1
We are currently testing kde 4.5, qt 4.7, kdepim 4.5, etc....
Eli
On 7/4/2010 10:01 PM, Eli Wapniarski wrote:
OK... not never.... But you've pretty much made my point. And I quote
And I quote
"We hope to make a production-ready kdepim 4.5 available concurrently with KDE SC 4.5.1 or KDE SC 4.5.2, depending on how well our beta testing goes."We are currently testing kde 4.5. Not kde 4.5.1
We're currently testing what the KDE SIG believes will be part of future Fedora releases; this includes the future kdepim release of which there is a beta now.
The KDE SIG likes to closely track pre-releases of fu- ture KDE releases. This way, it can have the required packaging changes figured out by the time the final rolls around, and can help upstream by providing feed- back on the pre-releases.
(Contrast that with e.g. Debian, who started work on KDE 4.4 packaging when 4.4.0 was released, and were surprised about dependency changes that the Fedora KDE SIG had figured out *months* earlier.)
Spec files for KDE pre-releases for which the final is expected to make it in time for the upcoming Fedo- ra release (as is the case for kdepim 4.5 btw, you read the schedule, and read Thomas' mail) get commit- ted to rawhide. Then they are usually also built for the current stable releases and put into kde-unstable, so the Fedora KDE community can provide feedback and assist without testing without having to run all of rawhide (see Kevin's mail).
You're asking for an exception to this process to be made for the kdepim 4.5 beta. If you were granted this exception, the kdepim 4.5 packages which the KDE SIG expects to be in Fedora 14 will receive less testing than they otherwise would, since they're less accessible to the Fedora KDE community. That's not conducive to the quality of Fedora 14. The fact is simply that kdepim 4.5 is the future, and we better make sure it's a good future, and that's what kde- unstable is for. If you don't want to help testing - that's fine, of course - don't use kde-unstable.
Eli
On Sunday 04 July 2010 21:23:18 Eike Hein wrote:
You're asking for an exception to this process to be made for the kdepim 4.5 beta.
No we are not, and you are constantly mis-quoting us. We are asking only for assurance that you will do what the developers asked you to do - to release it in a way that allows us to choose whether to use it or not. And if you say once more that using the testing repos means we don't have that choice, expect to lose a lot of your testers.
Anne
Eli Wapniarski wrote:
We are currently testing kde 4.5. Not kde 4.5.1
We are currently testing all sorts of things, KDE SC 4.5 being just one of them. It's called kde-redhat unstable, not kde-redhat next-kde-sc-branch.
In addition, testing KDE SC 4.5 or 4.5.1 is the exact same thing now because the SAME branch will become KDE SC 4.5 at one point and 4.5.1 a month later.
Kevin Kofler
On Monday 05 July 2010 00:09:36 Kevin Kofler wrote:
Eli Wapniarski wrote:
We are currently testing kde 4.5. Not kde 4.5.1
We are currently testing all sorts of things, KDE SC 4.5 being just one of them. It's called kde-redhat unstable, not kde-redhat next-kde-sc-branch.
In addition, testing KDE SC 4.5 or 4.5.1 is the exact same thing now because the SAME branch will become KDE SC 4.5 at one point and 4.5.1 a month later.
Kevin Kofler
The following is not being communicated with any sense of ill feelings, nor with any sense of disparagement towards you, but rather my feelings as to my ability to keep up with what everybody is doing here.
Fine people... Fine... as indicated do as you please. But however, now I'm completely confused as to the contents of kde-redhat. I guess I have to stop trying to do the limited testing that I am able to. I guess I just can't keep up with what belongs with what. After kde 4.5 goes gold, I will have to drop kde-redhat repos. Also, because I am so confused by what's being communicated in this mailing list I will need to drop it. And because I will no longer be communicating I would request that somebody take over the 4 packages I'm maintaining.
I'm sorry, I just feel that there isn't much more that I can contribute here. Best of luck and I look forward to seeing the results of your work in fedora stable.
With great admiration and respect
Eli
On Mon, Jul 5, 2010 at 6:31 AM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Monday 05 July 2010 00:09:36 Kevin Kofler wrote:
Eli Wapniarski wrote:
We are currently testing kde 4.5. Not kde 4.5.1
We are currently testing all sorts of things, KDE SC 4.5 being just one of them. It's called kde-redhat unstable, not kde-redhat next-kde-sc-branch.
In addition, testing KDE SC 4.5 or 4.5.1 is the exact same thing now because the SAME branch will become KDE SC 4.5 at one point and 4.5.1 a month later.
Kevin Kofler
The following is not being communicated with any sense of ill feelings, nor with any sense of disparagement towards you, but rather my feelings as to my ability to keep up with what everybody is doing here.
Fine people... Fine... as indicated do as you please. But however, now I'm completely confused as to the contents of kde-redhat. I guess I have to stop trying to do the limited testing that I am able to. I guess I just can't keep up with what belongs with what. After kde 4.5 goes gold, I will have to drop kde-redhat repos. Also, because I am so confused by what's being communicated in this mailing list I will need to drop it. And because I will no longer be communicating I would request that somebody take over the 4 packages I'm maintaining.
Your decision. If you want to, just drop a note here and orphan the packages in pkgdb. I will take care of them.
Quoting Thomas Janssen thomasj@fedoraproject.org:
On Mon, Jul 5, 2010 at 6:31 AM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Monday 05 July 2010 00:09:36 Kevin Kofler wrote:
Eli Wapniarski wrote:
We are currently testing kde 4.5. Not kde 4.5.1
We are currently testing all sorts of things, KDE SC 4.5 being just one of them. It's called kde-redhat unstable, not kde-redhat next-kde-sc-branch.
In addition, testing KDE SC 4.5 or 4.5.1 is the exact same thing now because the SAME branch will become KDE SC 4.5 at one point and 4.5.1 a month later.
Kevin Kofler
The following is not being communicated with any sense of ill feelings, nor with any sense of disparagement towards you, but rather my feelings as to my ability to keep up with what everybody is doing here.
Fine people... Fine... as indicated do as you please. But however, now I'm completely confused as to the contents of kde-redhat. I guess I have to stop trying to do the limited testing that I am able to. I guess I just can't keep up with what belongs with what. After kde 4.5 goes gold, I will have to drop kde-redhat repos. Also, because I am so confused by what's being communicated in this mailing list I will need to drop it. And because I will no longer be communicating I would request that somebody take over the 4 packages I'm maintaining.
Your decision. If you want to, just drop a note here and orphan the packages in pkgdb. I will take care of them.
-- LG Thomas
Thanks Thomas
Eli
On 7/4/2010 6:59 PM, Eli Wapniarski wrote:
On Sunday 04 July 2010 15:19:13 Eike Hein wrote:
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
I beg to differ. kde-unstable is branched off into next release and current 2 releases. It is there to test the schedualed to be released as part of the current working versions of Fedora. Otherwise, there would only be a rawhide version (currently F14) which is not the case. kdepim is schedualed never to be released. We may see version 4.5.1. If things go well.
I found this paragraph to be really hard to parse and am not sure if the following will answer the embedded questions, but I'll try:
kde-unstable usually contains builds of rawhide (or rawhide-derived, if changes are necessary) specs for the current stable releases, thereby allowing users of those stable releases to test software that the KDE SIG is preparing for the upcoming Fedora release without having to test all of rawhide.
Evidence for that is that kde-unstable frequently contains software for which no main repo update for the current release is intended to be submitted, e.g. KOffice 2.x for the longest time was only there.
Further confirmation would be found in Kevin Kofler's mail in this thread (he's a KDE SIG member) or Thomas Janssen's (another KDE SIG member) first mail to his thread, where he interpreted your question about whether kdepim 4.5 would be fit for the release cycle as applying to rawhide.
I mean, if multiple KDE SIG developers tell you you are wrong, isn't that cause to go "huh, maybe I got it wrong?" for you?
I think that addresses your argument that if kde-un- stable were for rawhide testing there would only be a rawhide branch of it.
Eli
On Sunday 04 July 2010 22:57:54 Eike Hein wrote:
On 7/4/2010 6:59 PM, Eli Wapniarski wrote:
On Sunday 04 July 2010 15:19:13 Eike Hein wrote:
On 07/04/2010 06:53 AM, Eli Wapniarski wrote:
It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
kde-unstable is not for production desktops. If kde-unstable were to cater to production desktops, it would not be able to fulfill the pur- pose it currently serves, which is to test software that is expected to be part of the next Fedora release.
I beg to differ. kde-unstable is branched off into next release and current 2 releases. It is there to test the schedualed to be released as part of the current working versions of Fedora. Otherwise, there would only be a rawhide version (currently F14) which is not the case. kdepim is schedualed never to be released. We may see version 4.5.1. If things go well.
I found this paragraph to be really hard to parse and am not sure if the following will answer the embedded questions, but I'll try:
kde-unstable usually contains builds of rawhide (or rawhide-derived, if changes are necessary) specs for the current stable releases, thereby allowing users of those stable releases to test software that the KDE SIG is preparing for the upcoming Fedora release without having to test all of rawhide.
Evidence for that is that kde-unstable frequently contains software for which no main repo update for the current release is intended to be submitted, e.g. KOffice 2.x for the longest time was only there.
Further confirmation would be found in Kevin Kofler's mail in this thread (he's a KDE SIG member) or Thomas Janssen's (another KDE SIG member) first mail to his thread, where he interpreted your question about whether kdepim 4.5 would be fit for the release cycle as applying to rawhide.
I mean, if multiple KDE SIG developers tell you you are wrong, isn't that cause to go "huh, maybe I got it wrong?" for you?
I think that addresses your argument that if kde-un- stable were for rawhide testing there would only be a rawhide branch of it.
Eli
I give up. Do what you want. My feeling is its a mistake.
Eli
On 7/4/2010 10:22 PM, Eli Wapniarski wrote:
I give up. Do what you want. My feeling is its a mistake.
I think it would be a mistake not to. I'd rather kdepim is a rough ride in kde-unstable than in a stable release, and testing it early enough is what the KDE SIG and Fedora KDE can do to make sure that doesn't happen.
I understand and appreciate that you feel that putting a hypothetical broken kdepim into kde-unstable would be harmful. But if this kdepim is broken, that's something we actually have to find out! And that's what kde-unsta- ble is for, too. I tried to talk earlier about how in my mind it would end up being *more* harmful to give up on kde-unstable as the place we can use for this (like we have done so far) and instead turn it into the "bleeding edge, but nothing too upsetting" repo. That's really a downward spiral in how it removes pressure from packagers to work toward integrating stuff into the main repo. I've really seen that happen at many other distros and it's a mess and takes a toll on overall package quality.
I guess we'll just have to agree to disagree.
Eli
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Anne
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Why kdepimTP? If one don't want to test kdepim4.5 on a testmachine as you stated some people have, why have it installed along with kdepim4.4? If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update? And if i'm willing to test, i want to test everything, including the update from 4.4 to 4.5. That's part of testing.
This whole thread gets slowly ridiculous.
Test it or leave it.
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Why kdepimTP?
A logical suggestion for a Technical Preview, thout it was obviously a suggestion which makes your remark fatuous.
If one don't want to test kdepim4.5 on a testmachine as you stated some people have, why have it installed along with kdepim4.4?
You know perfectly well that the ability to install alongside is simply that either one could be chosen without impact on the rest of the SC. Of course3 it doesn't make sense to use both, so why are you suggesting that we are idiots? The packages are tested to make sure they use the same dependencies, AIUI.
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
And if i'm willing to test, i want to test everything, including the update from 4.4 to 4.5. That's part of testing.
This whole thread gets slowly ridiculous.
It does indeed, seeing the lengthy fatuous defences and complete refusal to give the assurance we need.
Test it or leave it.
Whether I choose to test it or not is my decision, not yours. If I can't trust Fedora to follow the requests of the developers, I'll go elsewhere.
Anne
On 7/4/2010 11:30 PM, Anne Wilson wrote:
A logical suggestion for a Technical Preview, thout it was obviously a suggestion which makes your remark fatuous.
It's a beta, not a Technical Preview. If it was mislabeled, please complain to the kdepim developers. The mailing list message you quoted (and which I linked to earlier in this thread, before you quoted it) makes no mention of it being a Technical Preview.
Whether I choose to test it or not is my decision, not yours. If I can't trust Fedora to follow the requests of the developers, I'll go elsewhere.
Developers release betas with the implied request that people test them. Fedora is complying with that request by making it available to users in kde-unstable.
I should point out that I'm a KDE developer, not a Fedora developer. I'm a Fedora user. I'm very happy that Fedora is doing the right thing here, obviously.
Anne
Eike Hein wrote:
It's a beta, not a Technical Preview. If it was mislabeled, please complain to the kdepim developers. The mailing list message you quoted (and which I linked to earlier in this thread, before you quoted it) makes no mention of it being a Technical Preview.
In addition, Qt Technical Previews are also provided through kde-redhat unstable as upgrades to the regular qt packages. This is just how kde-redhat unstable works.
Kevin Kofler
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Why kdepimTP?
A logical suggestion for a Technical Preview, thout it was obviously a suggestion which makes your remark fatuous.
No, it's not a Technical Preview, but a beta1. And you better watch your language. I'm not one of your hutchigutchis.
If one don't want to test kdepim4.5 on a testmachine as you stated some people have, why have it installed along with kdepim4.4?
You know perfectly well that the ability to install alongside is simply that either one could be chosen without impact on the rest of the SC. Of course3 it doesn't make sense to use both, so why are you suggesting that we are idiots? The packages are tested to make sure they use the same dependencies, AIUI.
I'm not suggesting you're idiots, just that you obviously completely miss the point of kde-unstable, as Eli does. If i would think you're idiots, i would write it clearly out. I don't hide anything behind my words. So don't read between the lines but what i write.
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
Why not? Do you run rawhide? If not, nobody holds a gun on your head and says "update to kdepim4.5". We still speak about kde-unstable.
And if i'm willing to test, i want to test everything, including the update from 4.4 to 4.5. That's part of testing.
This whole thread gets slowly ridiculous.
It does indeed, seeing the lengthy fatuous defences and complete refusal to give the assurance we need.
There's no assurance for rawhide or kde-unstable. If one can't/won't handle it, keep the fingers off. Or i suggest to read *man yum* since people don't want to accept the already mentioned: yum --exclude
Test it or leave it.
Whether I choose to test it or not is my decision, not yours. If I can't trust Fedora to follow the requests of the developers, I'll go elsewhere.
You still don't get it how rawhide and the release cycle or kde-unstable works. Since it's your decision (and of course it is) wht you test or not, what we put in our rawhide or kde-unstable is our decision not yours.
On Sunday 04 July 2010 22:49:48 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Why kdepimTP?
A logical suggestion for a Technical Preview, thout it was obviously a suggestion which makes your remark fatuous.
No, it's not a Technical Preview, but a beta1. And you better watch your language. I'm not one of your hutchigutchis.
Yet although it was not in that message, the developers have repeatedly referred to it as a technical preview, as I'm sure you are aware.
As for my language - it's standard English. Nothing wrong with what I wrote.
Kde-pim is central to work for many of us. In view of that we can't just make a snap, uninformed decision. If we were worried about a media-player or image application there would always be another to fall back on. This is simply not the same - for many of us it is of the utmost importance.
That some of us use testing packages benefits Fedora, which seems to be completely overlooked at the moment.
Anne
Anne Wilson wrote:
Yet although it was not in that message, the developers have repeatedly referred to it as a technical preview, as I'm sure you are aware.
Well, we also carry Technical Preview releases of Qt in kde-redhat unstable, and that's used by all of KDE including kdepim.
Kevin Kofler
Quoting Kevin Kofler kevin.kofler@chello.at:
Anne Wilson wrote:
Yet although it was not in that message, the developers have repeatedly referred to it as a technical preview, as I'm sure you are aware.
Well, we also carry Technical Preview releases of Qt in kde-redhat unstable, and that's used by all of KDE including kdepim.
Kevin Kofler
But we can roll back without breaking anything.
Eli
Eli Wapniarski wrote:
But we can roll back [Qt] without breaking anything.
Just as much as we can roll back kdepim. If e.g. a QList bug deletes all your mail, rolling back Qt won't help you any more than rolling back kdepim helps you if kdepim deletes all your mail. The risk of data loss is always there with prerelease software.
Kevin Kofler
2010/7/5 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 22:49:48 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
2010/7/4 Anne Wilson cannewilson@googlemail.com:
On Sunday 04 July 2010 13:19:13 Eike Hein wrote:
Keeping the kdepim 4.5 beta out of kde-unstable would create a dange- rous precedent for the future by hampering what kde-unstable has up until now been used for, and thus limiting its usefulness for pre- release testing, and thus limiting testing.
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
Why kdepimTP?
A logical suggestion for a Technical Preview, thout it was obviously a suggestion which makes your remark fatuous.
No, it's not a Technical Preview, but a beta1. And you better watch your language. I'm not one of your hutchigutchis.
Yet although it was not in that message, the developers have repeatedly referred to it as a technical preview, as I'm sure you are aware.
As for my language - it's standard English. Nothing wrong with what I wrote.
Kde-pim is central to work for many of us. In view of that we can't just make a snap, uninformed decision. If we were worried about a media-player or image application there would always be another to fall back on. This is simply not the same - for many of us it is of the utmost importance.
That some of us use testing packages benefits Fedora, which seems to be completely overlooked at the moment.
Quite interesting how you try to destroy our reputation in #akonadi on IRC freenode:
#akonadi
[08:55] <annew> I'm worried about the 4.5 kdepim coming to fedora [08:56] <annew> they are going to put it into updates-testing without any warning that it is a technical preview [08:56] <annew> and have even said on the ML that it isn't a technical preview, but a beta [08:56] <annew> and if you don't like it, complain to kde,not us. [08:56] <-- till has left this server (Quit: Leaving.). [08:57] <annew> their attitude is very worrying [08:57] <annew> it feels as though we are heading for another 4.0 situation [08:58] <annew> I feel strongly that people should be given the information to make their own judgement as to whether to test it
You better stop telling that kind of BS. If you're not able to understand what you read maybe you have to find a different business. Don't fuck everybody up, really. Stop telling others false information as you obviously like to do.
On 07/05/2010 09:13 AM, Thomas Janssen wrote:
[08:56]<annew> they are going to put it into updates-testingwithout any warning that it is a technical preview
That is an outright lie: kde-unstable is not updates-testing, and it has been mentioned multiple times in this thread that kde-unstable frequently carries packages that are never in- tended to be submitted to updates-testing for current stable releases.
On Monday 05 July 2010 11:37:23 Eike Hein wrote:
On 07/05/2010 09:13 AM, Thomas Janssen wrote:
[08:56]<annew> they are going to put it into updates-testingwithout any warning that it is a technical preview
That is an outright lie: kde-unstable is not updates-testing, and it has been mentioned multiple times in this thread that kde-unstable frequently carries packages that are never in- tended to be submitted to updates-testing for current stable releases.
I have already spoken on irc about this. I made a mistake in the naming, largely because I was rushing, just about to leave the building. I admit the mistake, and would have willingly corrected it. As it is I didn't see anything about this for many hours.
I do resent being called a liar - I have never deliberately told any lie, nor have I tried to ruin your reputation. The conversation you quoted was not even on a user channel, so if you had not chosen to quote it, most people would not have seen the mistake. It would have been more kind and honest to tell me that I had made a mistake, instead of using insulting language against me in this way.
I have been told that I must not help users on Fedora channels in future, so I will have rather more time for my other interests.
What I said accurately expressed my feelings from the long thread. It is hardly surprising that we were confused, after all the aggressive replies to our genuine concerns. I am happy to say, however, that the end result is that we have been given information that users can employ to safeguard themselves if they don't want to run the latest kdepim, and happy to hear that an announcement to that effect will be made at release time.
Anne
Anne Wilson wrote:
I have been told that I must not help users on Fedora channels in future, so I will have rather more time for my other interests.
I hope that is not true, as I have found you very helpful on several occasions.
On Monday 05 July 2010 21:21:16 Anne Wilson wrote:
I do resent being called a liar - I have never deliberately told any lie, nor have I tried to ruin your reputation. The conversation you quoted was not even on a user channel, so if you had not chosen to quote it, most people would not have seen the mistake. It would have been more kind and honest to tell me that I had made a mistake, instead of using insulting language against me in this way.
I have been told that I must not help users on Fedora channels in future, so I will have rather more time for my other interests.
Please note that mailing list are always bad to express any feeling. During any flamewar, such as this thread was, there are words that attain an unbounded expression.
Not only that but the real semantics of any word is even difficult to discern during the heat of the discussion. To talk is a tricky business. :-)
IMHO opinion this discussion goes like this, people have been burned during the 4.0 transition. Now that a structural desktop component is taking a similar transition that fear showed up again. kdepim-libs is an important component and one where some mistakes can mean a dataloss and that is not something to take light-heartily by any means. Some previous changes in the kdepim had showed that some of the assumptions made by developers like the removal of contact lists without an effective replacement were miscalculated (to say the least).
At the same time the developers need real cases uses to test the changes, it is not enough to test it with simple cases. As far as I understand from what I read this has been the case, the upgrade tools allows to left the previous configuration in place in case there is a need to downgrade.
In any case to complain here is the wrong place, kde-redhat is the (virtual) messenger. Assuming that the developers had asked for the testing of the new packages kde-redhat is continuing its path to better integrate kde into fedora (and derivatives).
This is how I read this whole thread but, as usual, I assume that I can be wrong. :-)
Regards,
On Tue, Jul 6, 2010 at 11:49 AM, dexter dex.mbox@gmail.com wrote:
2010/7/5 Anne Wilson <cannewilson googlemail.com>:
I have been told that I must not help users on Fedora channels in future
It'll be a sad day when you start to listen to these folk, btw who wields such power?
That's just a part of a sentence out of a long conversation on IRC. Of course that's the part she likes to share with you folks, to appear in a better light.
The monologue she has hold, i quoted here earlier in this thread, happened in an channel (#akonadi) with developers and users hanging around. And that was clearly a try to destroy our reputation there.
All this "mistake" talk doesn't change anything. People able to read and understand will see the "mistake that happened".
BTW, there was no real agreement about anything. All of what will happen what she quoted as her success, like the announcement that will happen, or the helpful commands (given from the beginning of this thread), are just actions/things that happens all the time on this ML.
Anne Wilson wrote:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
It's possible to put exclude= lines on specific repos' .conf files, too.
Kevin Kofler
On 7/4/2010 11:52 PM, Kevin Kofler wrote:
Anne Wilson wrote:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
It's possible to put exclude= lines on specific repos' .conf files, too.
In addition to that, if you don't want to edit config files, it's also possible to do this:
yum upgrade --disablerepo=kde-unstable yum upgrade --exclude=kdepim*
The first command will get the latest kdepim 4.4.x update (e.g. from kde-testing, where Rex just put 4.4.5), the second command will get all the updates from kde-unstable except for those packages starting with kdepim*.
Kevin Kofler
On Sunday 04 July 2010 22:58:05 Eike Hein wrote:
On 7/4/2010 11:52 PM, Kevin Kofler wrote:
Anne Wilson wrote:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
It's possible to put exclude= lines on specific repos' .conf files, too.
In addition to that, if you don't want to edit config files, it's also possible to do this:
yum upgrade --disablerepo=kde-unstable yum upgrade --exclude=kdepim*
The first command will get the latest kdepim 4.4.x update (e.g. from kde-testing, where Rex just put 4.4.5), the second command will get all the updates from kde-unstable except for those packages starting with kdepim*.
Now we're getting solutions to the problem :-) Thank you.
Anne
On Sunday 04 July 2010 22:52:49 Kevin Kofler wrote:
Anne Wilson wrote:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
If one is afraid of kdepim4.5, what is so hard to use: yum --exclude=kdepim update?
A lot - as I already remarked. Without some form of naming differentiation we could not get any bug-fix or security update for kdepim 4.4 if we did that.
It's possible to put exclude= lines on specific repos' .conf files, too.
I didn't know that. I would imagine that that would solve the problem nicely. Thanks.
Anne
On 7/4/2010 11:30 PM, Anne Wilson wrote:
Whether I choose to test it or not is my decision, not yours. If I can't trust Fedora to follow the requests of the developers, I'll go elsewhere.
Another thing that I feel bears repeating with regard to this one: It's been said multiple times now that kde-unstable pro- vides backports from rawhide, and what's in rawhide is intend- ed to be in the next Fedora release. Thus what ends up in kde- unstable depends on what the KDE SIG expects to be in the next Fedora release. And going by the schedule the kdepim devel- opers published, the final release of kdepim 4.5 will be out in time for it to comfortably be in Fedora 14. Thus this de- cision is very much based on the information the kdepim de- velopers have provided: If there was no chance that kdepim 4.5 would make it into Fedora 14, Rex probably wouldn't be putting it into kde-unstable.
It's been pointed out by Eli that kde-unstable is about Fedora QA, not KDE QA, and while he used that as part of an incorrect argument, it's a true statement by itself. kde-unstable is not for testing the KDE SC 4.5 + kdepim 4.4 combo because that's what KDE is releasing next. It's about testing what is going to be in the next Fedora, and what is going to be in the next Fedora is decided based on release schedules published by the upstream developers.
And that's nothing new, it goes for basically everything that ever goes into kde-unstable. The by now often-mentioned Qt 4.7 is a good example: Again the upstream release schedule puts it in a timeframe where the final release will make it into Fedo- ra 14, so kde-unstable shipped the pre-releases.
And if you're talking about not following developer's requests, take a look at cases like Mandriva and other distros shipping pre-release versions of the KDE 4 port of K3b while upstream expressly told distros not to do that - and Fedora didn't do it, and took flak from users for it. You can't please every- one.
Eike Hein wrote:
And if you're talking about not following developer's requests, take a look at cases like Mandriva and other distros shipping pre-release versions of the KDE 4 port of K3b while upstream expressly told distros not to do that
Alpha releases, in official stable repositories, I should add. And there we are, debating over a beta release of kdepim in an unofficial unstable repository.
Kevin Kofler
On Monday 05 July 2010 04:16:07 Kevin Kofler wrote:
Eike Hein wrote:
And if you're talking about not following developer's requests, take a look at cases like Mandriva and other distros shipping pre-release versions of the KDE 4 port of K3b while upstream expressly told distros not to do that
Alpha releases, in official stable repositories, I should add. And there we are, debating over a beta release of kdepim in an unofficial unstable repository.
I can live with a broken K3b, but less eaily with a broken kde-pim. But this is going off-topic.
Anne
Anne Wilson wrote:
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
We don't have any plans to rename the kdepim 4.5 packages at this time and it'd be a source of problems (the packages would have to Conflict, translations would be an issue etc.) and additional work.
The plan instead is to ship one version of kdepim per repository. For Rawhide and kde-redhat unstable, this is 4.5, which is now in beta stage.
Kevin Kofler
On Sunday 04 July 2010 22:16:22 Kevin Kofler wrote:
Anne Wilson wrote:
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice. What's wrong with that request? And if you planned to do it anyway, why can't you say so instead of mocking genuine concerns, as several people seem to think is the way to reply
We don't have any plans to rename the kdepim 4.5 packages at this time and it'd be a source of problems (the packages would have to Conflict, translations would be an issue etc.) and additional work.
The plan instead is to ship one version of kdepim per repository. For Rawhide and kde-redhat unstable, this is 4.5, which is now in beta stage.
OK, I can see your point, Kevin. We all want to avoid the problems that we had with KDE 4.0 release, though, so we need to address how people get the information they need to make a sensible decision on whether to upgrade to it or not.
It seems to me as though people are saying that either you take it, or you stop testing altogether. I don't see thatas being in Fedora's interests.
Anne
Last one from me... Follow the bouncing ball. Please note (and yes I know that kdepimlibs is not kdepim).
But in kdepimlibs 4.4.90 there are lots of packages dependent on it. Its not as simple as excluding kdepim from unstable.
rpm -qa | grep kdepim
kdepim-4.4.5-1.fc13.i686 kdepimlibs-4.4.90-1.fc13.i686 kdepimlibs-akonadi-4.4.90-1.fc13.i686 kdepim-runtime-4.4.5-1.fc13.i686 kdepim-libs-4.4.5-1.fc13.i686 kdepim-runtime-libs-4.4.5-1.fc13.i686 kdepim-runtime-devel-4.4.5-1.fc13.i686 kdepimlibs-devel-4.4.90-1.fc13.i686 kdepim3-libs-3.5.10-3.fc13.i686
rpm -e kdepimlibs kdepimlibs-akonadi kdepimlibs-devel error: Failed dependencies: libgpgme++-pthread.so.2 is needed by (installed) kdenetwork-libs-7:4.4.90-1.fc13.i686 libgpgme++-pthread.so.2 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libgpgme++-pthread.so.2 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libgpgme++-pthread.so.2 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libgpgme++.so.2 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkabc.so.4 is needed by (installed) kpilot-libs-5.3.0-4.fc13.i686 libkabc.so.4 is needed by (installed) kipi-plugins-1.3.0-1.fc13.i686 libkabc.so.4 is needed by (installed) digikam-1.3.0-1.fc13.i686 libkabc.so.4 is needed by (installed) kdenetwork-libs-7:4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdesdk-4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdeplasma-addons-4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdeutils-6:4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libkabc.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libkabc.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkabc.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkabc.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkabc.so.4 is needed by (installed) konversation-1.3.1-1.fc13.i686 libkblog.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkblog.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkcal.so.4 is needed by (installed) kpilot-libs-5.3.0-4.fc13.i686 libkcal.so.4 is needed by (installed) kipi-plugins-1.3.0-1.fc13.i686 libkcal.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libkcal.so.4 is needed by (installed) kdesdk-4.4.90-1.fc13.i686 libkcal.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkcal.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libkcal.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkcal.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkcal.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkholidays.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkholidays.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkholidays.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkimap.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkimap.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkldap.so.4 is needed by (installed) kdeadmin-7:4.4.90-1.fc13.i686 libkldap.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkldap.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkmime.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libkmime.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkmime.so.4 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libkmime.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libkmime.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkmime.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkmime.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkontactinterface.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkontactinterface.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkpimidentities.so.4 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libkpimidentities.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkpimidentities.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkpimtextedit.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkpimtextedit.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdeutils-6:4.4.90-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkpimutils.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkresources.so.4 is needed by (installed) kpilot-libs-5.3.0-4.fc13.i686 libkresources.so.4 is needed by (installed) kipi-plugins-1.3.0-1.fc13.i686 libkresources.so.4 is needed by (installed) digikam-1.3.0-1.fc13.i686 libkresources.so.4 is needed by (installed) kdenetwork-libs-7:4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdesdk-4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdeplasma-addons-4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdeutils-6:4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libkresources.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libkresources.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libkresources.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libkresources.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libkresources.so.4 is needed by (installed) konversation-1.3.1-1.fc13.i686 libktnef.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libmailtransport.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libmailtransport.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libmailtransport.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libmicroblog.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libmicroblog.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libqgpgme.so.1 is needed by (installed) kdenetwork-libs-7:4.4.90-1.fc13.i686 libqgpgme.so.1 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libqgpgme.so.1 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libqgpgme.so.1 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libsyndication.so.4 is needed by (installed) ktorrent-4.0.1-1.fc13.i686 libsyndication.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libsyndication.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libsyndication.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 kdepimlibs >= 4.4.90 is needed by (installed) kdeadmin-7:4.4.90-1.fc13.i686 kdepimlibs(x86-32) >= 4.4.90 is needed by (installed) kdebase-runtime-libs-4.4.90-1.fc13.i686 kdepimlibs(x86-32) >= 4.4.90 is needed by (installed) kdebase-libs-6:4.4.90-1.fc13.i686 kdepimlibs(x86-32) >= 4.4.90 is needed by (installed) kdesdk-4.4.90-1.fc13.i686 kdepimlibs(x86-32) >= 4.4.90 is needed by (installed) kdenetwork-7:4.4.90-1.fc13.i686 libakonadi-contact.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libakonadi-contact.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libakonadi-contact.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libakonadi-kabc.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libakonadi-kabc.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libakonadi-kcal.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libakonadi-kcal.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libakonadi-kcal.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libakonadi-kcal.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kpilot-libs-5.3.0-4.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdeplasma-addons-libs-4.4.90-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libakonadi-kde.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 libakonadi-kmime.so.4 is needed by (installed) kdebindings-4.4.90-1.fc13.i686 libakonadi-kmime.so.4 is needed by (installed) kdebase-workspace-4.4.90-1.fc13.i686 libakonadi-kmime.so.4 is needed by (installed) kdepim-runtime-4.4.5-1.fc13.i686 libakonadi-kmime.so.4 is needed by (installed) kdepim-6:4.4.5-1.fc13.i686 libakonadi-kmime.so.4 is needed by (installed) kdepim-libs-6:4.4.5-1.fc13.i686 kdepimlibs-akonadi(x86-32) >= 4.4.5 is needed by (installed) kdepim-runtime-libs-4.4.5-1.fc13.i686 kdepimlibs4-devel is needed by (installed) kdebase-devel-6:4.4.90-1.fc13.i686 kdepimlibs-devel is needed by (installed) kdesdk-devel-4.4.90-1.fc13.i686 kdepimlibs-devel is needed by (installed) kdepim-runtime-devel-4.4.5-1.fc13.i686
Eli Wapniarski wrote:
Last one from me... Follow the bouncing ball. Please note (and yes I know that kdepimlibs is not kdepim).
But in kdepimlibs 4.4.90 there are lots of packages dependent on it. Its not as simple as excluding kdepim from unstable.
Using kdepimlibs from 4.5 and kdepim and kdepim-runtime from 4.4 is actually what upstream is recommending for 4.5.0.
So this:
kdepim-4.4.5-1.fc13.i686 kdepimlibs-4.4.90-1.fc13.i686 kdepimlibs-akonadi-4.4.90-1.fc13.i686 kdepim-runtime-4.4.5-1.fc13.i686 kdepim-libs-4.4.5-1.fc13.i686 kdepim-runtime-libs-4.4.5-1.fc13.i686 kdepim-runtime-devel-4.4.5-1.fc13.i686 kdepimlibs-devel-4.4.90-1.fc13.i686 kdepim3-libs-3.5.10-3.fc13.i686
is fine.
Kevin Kofler
On 7/4/2010 11:08 PM, Anne Wilson wrote:
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice.
You made the choice to test beta-level KDE releases when you decided to use kde-unstable.
On Sunday 4 July 2010 22:30:49 Eike Hein wrote:
On 7/4/2010 11:08 PM, Anne Wilson wrote:
I really can't see what the big deal is. All we're asking is that you make sure it has a differentiated name - something like kde-pmTP would do it - so that we don't get it as an update, but as a deliberate choice.
You made the choice to test beta-level KDE releases when you decided to use kde-unstable.
This is how I see it,
If you don't want to test kdepim-4.5 then disable "kde-unstable" Bug fixes/security issues to for kdepim-4.4.x would be in "kde-testing" or straight into "kde-stable" if its a serious issue.
Personally I can't wait to get my hands on it :)
Colin
Eli Wapniarski wrote:
The fuss is.... The developers are saying that kdepim 4.5 is not ready for prime time and will not be released with kde 4.5. In unstable we have the kde 4.5 packages. We are all testing kde 4.5 not 4.5.1. It is not unforseable that me you or someone else, on purpose or by accident or for whatever reason installs kdepim 4.5 on a production desktop.
If you're using kde-redhat UNSTABLE on a PRODUCTION desktop, you have a bigger problem than kdepim 4.5. :-/
Kevin Kofler
On 07/03/2010 03:05 PM, Patrick Boutilier wrote:
qt 4.7 is in unstable. It is not going to be released with kde 4.5 either. I think you are missing the point of kde-unstable.
In fact, kde-unstable even carried Qt 4.7 Technical Preview 1 when it came out, i.e. what Nokia releases *preceding* a beta.
So I don't see what the fuss is about a kdepim beta release being there.
Eli Wapniarski wrote:
In kde-unstable along the path to testing and then fedora-testing and finally stable. And with relative certainty that things are going to work by the end of the process. We know that kdepim 4.5 is not going to work. That means putting the current unstable packages into testing.
Since there's still some confusion on this, let's set this straight: kdepim 4.5 will NOT hit updates-testing nor kde-redhat testing before AT LEAST RC stage (and most likely not even that) and DEFINITELY NOT any stable repository before upstream declares it stable. (And even then, it'll only get pushed if there aren't any regressions blocking an update.) We are NOT going to push beta releases of kdepim 4.5 into testing repositories, ONLY unstable.
A package being in kde-redhat unstable does NOT mean it's headed for testing or stable in any particular timeframe. While some packages make it out of unstable quickly and for all supported Fedora releases, others (e.g. KOffice 2) have stayed in unstable for years and were only shipped with new releases, not as updates at all. Things only make it out of unstable when they're actually usable, and only get pushed as updates to existing releases when they don't cause regressions.
I hope this clears up that particular misunderstanding.
Kevin Kofler
On Friday 02 July 2010 18:04:54 Eli Wapniarski wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Eli
The developers have said explicitly that it is a Technical Preview. They have asked that distros that choose to supply it should make that clear to users, and that they should distribute the 4.4 version as standard in SC 4,5, which means that you will be able to run the two in parallel, but only if you explicitly choose to.
The migration path is fairly well tested, but if things do go wrong it is possible to revert to using the 4.4 version. However, it sounds a bit complicated to me so I have asked the developers to help me write up a clear explanation when the release gets nearer.
Anne
On Saturday 03 July 2010 22:49:46 Anne Wilson wrote:
On Friday 02 July 2010 18:04:54 Eli Wapniarski wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Eli
The developers have said explicitly that it is a Technical Preview. They have asked that distros that choose to supply it should make that clear to users, and that they should distribute the 4.4 version as standard in SC 4,5, which means that you will be able to run the two in parallel, but only if you explicitly choose to.
The migration path is fairly well tested, but if things do go wrong it is possible to revert to using the 4.4 version. However, it sounds a bit complicated to me so I have asked the developers to help me write up a clear explanation when the release gets nearer.
Anne
As you noted Anne.... It is a technical review. However, as noted earlier kdepim 4.5 is schedualed to be brought along side packages being tested as part of the release cycle. Kdepim 4.5 is not schedualed for release. IMHO it is a mistake to include it within the framework of how kde-redhat has traditionally incorporated testing leading to final release. The last time kde released a botched kdepim the noise was horrific and very unpleasant.
Again in my humble opinion it belongs somewhere on the side. If individuals wish to test it then they would be able to do it by including the kde-redhat development repo. Leaving unstable clear for testing of packages schedualed for release.
Eli
Eli
On Sat, Jul 3, 2010 at 10:18 PM, Eli Wapniarski eli@orbsky.homelinux.org wrote:
On Saturday 03 July 2010 22:49:46 Anne Wilson wrote:
On Friday 02 July 2010 18:04:54 Eli Wapniarski wrote:
On Friday 02 July 2010 18:03:10 Rex Dieter wrote:
Christoph Kaulich wrote:
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
When it is provided by it's upstream.
Turns out just yesterday, some preliminary kdepim-4.5-beta1 tarballs were provided to packagers, so we'll get to work on those, and get into rawhide and kde-unstable asap.
Errr.... What does that say about stability? If I recall correctly there were serious issues with kdepim 4.5 that delayed the release with kde 4.5. Does that mean the developers think that they have been resolved? If not is it wise to include kdepim 4.5 so deep in the release cycle?
Eli
The developers have said explicitly that it is a Technical Preview. They have asked that distros that choose to supply it should make that clear to users, and that they should distribute the 4.4 version as standard in SC 4,5, which means that you will be able to run the two in parallel, but only if you explicitly choose to.
The migration path is fairly well tested, but if things do go wrong it is possible to revert to using the 4.4 version. However, it sounds a bit complicated to me so I have asked the developers to help me write up a clear explanation when the release gets nearer.
Anne
As you noted Anne.... It is a technical review. However, as noted earlier kdepim 4.5 is schedualed to be brought along side packages being tested as part of the release cycle. Kdepim 4.5 is not schedualed for release. IMHO it is a mistake to include it within the framework of how kde-redhat has traditionally incorporated testing leading to final release. The last time kde released a botched kdepim the noise was horrific and very unpleasant.
Even you say *testing* (kde-testing) leading to final.
Again in my humble opinion it belongs somewhere on the side. If individuals wish to test it then they would be able to do it by including the kde-redhat development repo. Leaving unstable clear for testing of packages schedualed for release.
What is not understandable on kde-unstable? Should it be named kde-unstable-devel-will-eat-your-babys-makes-kitten-cry? Kdepim4.5 will be in kde-unstable. EOT for me.
On 07/03/2010 10:18 PM, Eli Wapniarski wrote:
As you noted Anne.... It is a technical review. However, as noted earlier kdepim 4.5 is schedualed to be brought along side packages being tested as part of the release cycle. Kdepim 4.5 is not schedualed for release. IMHO it is a mistake to include it within the framework of how kde-redhat has traditionally incorporated testing leading to final release.
kde-unstable tends to contain backports from rawhide/$current_release+1, i.e. it is for testing what the KDE SIG expects will be part of the up- coming Fedora release. Rex has already said that he expects kdepim 4.5 to be in Fedora 14, since if kdepim 4.5 is released with KDE SC 4.5.1 or 4.5.2 as planned, it works out timing-wise. So what's happening here seems to be exactly what you are calling for, testing of software that is expected to be in the next Fedora release.
On Saturday 03 July 2010 21:50:00 Eike Hein wrote:
kde-unstable tends to contain backports from rawhide/$current_release+1, i.e. it is for testing what the KDE SIG expects will be part of the up- coming Fedora release. Rex has already said that he expects kdepim 4.5 to be in Fedora 14, since if kdepim 4.5 is released with KDE SC 4.5.1 or 4.5.2 as planned, it works out timing-wise. So what's happening here seems to be exactly what you are calling for, testing of software that is expected to be in the next Fedora release.
The problem as I see it is that there is no way we can exclude kde-pim from updates, if we felt that TP is to raw for us, without stopping getting updates on kde-pim 4.4 - or am I missing something?
Could there be something in the naming scheme that would allow that differentiation? AIUI, the developers have said that they could be installed in parallel. If that's so, then it must be possible to differentiate, and everyone's fears would be addressed. I would have to check back to what they actually said, though, and on a netbook at midnight is not the best time to do that.
Anne
Anne Wilson wrote:
The problem as I see it is that there is no way we can exclude kde-pim from updates, if we felt that TP is to raw for us, without stopping getting updates on kde-pim 4.4 - or am I missing something?
--exclude="kdepim kdepim-libs kdepim-runtime kdepim-runtime-libs" on the yum command line as a one-time workaround, or better: exclude=kdepim kdepim-libs kdepim-runtime kdepim-runtime-libs in the .conf file for kde-unstable.
(Please note that kdepim-libs is not the same as kdepimlibs.)
AIUI, the developers have said that they could be installed in parallel.
No. Not in the same prefix. Files conflict all over the place. At least not all of kdepim; KMail MIGHT be parallel-installable (I haven't checked), but we don't have separate packaging of KMail, and kdepim-runtime might also be a source of conflicts there.
Kevin Kofler
-
Anne Wilson -
Anoop -
Christoph Kaulich -
Colin J Thomson -
dexter -
Eike Hein -
Eli Wapniarski -
José Abílio Matos -
Kevin Kofler -
Patrick Boutilier -
Rex Dieter -
Ryan Rix -
Thomas Janssen -
Timothy Murphy