9:08 a.m.
Hello,
just a short question, will there be a kdepim 4.5 beta1 build for fc13?
Thanks
Christoph
10:03 a.m.
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
12:04 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
12:25 p.m.
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski <eli(a)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.
--
LG Thomas
Dubium sapientiae initium
3:02 p.m.
On Friday 02 July 2010 20:25:33 Thomas Janssen wrote:
On Fri, Jul 2, 2010 at 7:04 PM, Eli Wapniarski
<eli(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
5:36 p.m.
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(a)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
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
midnight
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(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
12:18 a.m.
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(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:27 a.m.
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski <eli(a)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(a)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
--
LG Thomas
Dubium sapientiae initium
2:02 a.m.
On Saturday 03 July 2010 09:27:28 Thomas Janssen wrote:
On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski
<eli(a)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(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
2:57 a.m.
>
> 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
2:57 a.m.
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(a)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(a)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.
> >> >
> >> >
No, it's ready enough for Beta, that's why the PIM devs are pushing *beta*
tarballs!
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
Ryan
--
Ryan Rix
== http://hackersramblings.wordpress.com | http://rix.si/ ==
== http://rix.si/page/contact/ if you need a word ==
7:59 a.m.
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(a)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(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
8:05 a.m.
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
8:19 a.m.
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
11:56 a.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:15 p.m.
On Sat, Jul 3, 2010 at 6:56 PM, Eli Wapniarski <eli(a)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.
--
LG Thomas
Dubium sapientiae initium
2:49 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
3:18 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:33 p.m.
On Sat, Jul 3, 2010 at 10:18 PM, Eli Wapniarski
<eli(a)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.
--
LG Thomas
Dubium sapientiae initium
3:43 p.m.
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
--
Best regards,
Eike Hein
3:47 p.m.
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.
--
Best regards,
Eike Hein
3:50 p.m.
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.
--
Best regards,
Eike Hein
11:53 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
5:37 a.m.
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
7:19 a.m.
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*.
--
Best regards,
Eike Hein
9:34 a.m.
Quoting Patrick Boutilier <boutilpj(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
9:36 a.m.
Why is everyone so interested in kdepim-4.5?
What will it contain that is not in kdepim-4.4?
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
9:39 a.m.
Quoting Eike Hein <hein(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11:59 a.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
12:02 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
2:37 p.m.
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.
--
Best regards,
Eike Hein
2:43 p.m.
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.
--
Best regards,
Eike Hein
2:45 p.m.
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
--
Best regards,
Eike Hein
2:57 p.m.
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
--
Best regards,
Eike Hein
3:01 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:07 p.m.
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
3:11 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:22 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
3:23 p.m.
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
--
Best regards,
Eike Hein
3:35 p.m.
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
--
Best regards,
Eike Hein
3:52 p.m.
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
3:58 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
3:59 p.m.
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
--
Best regards,
Eike Hein
4:04 p.m.
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
4:04 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:08 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:09 p.m.
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
4:15 p.m.
2010/7/4 Anne Wilson <cannewilson(a)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.
--
LG Thomas
Dubium sapientiae initium
4:16 p.m.
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
4:19 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:22 p.m.
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
4:23 p.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:30 p.m.
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.
--
Best regards,
Eike Hein
4:30 p.m.
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
2010/7/4 Anne Wilson <cannewilson(a)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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:38 p.m.
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
--
Best regards,
Eike Hein
4:49 p.m.
2010/7/4 Anne Wilson <cannewilson(a)googlemail.com>:
On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
> 2010/7/4 Anne Wilson <cannewilson(a)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.
--
LG Thomas
Dubium sapientiae initium
4:52 p.m.
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
4:52 p.m.
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
4:53 p.m.
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
--
Fedora release 13 (Goddard)
Registered Linux user number #342953
4:58 p.m.
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
--
Best regards,
Eike Hein
5:28 p.m.
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.
--
Best regards,
Eike Hein
10:16 p.m.
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
11:21 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
11:31 p.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:06 a.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
1:12 a.m.
On Sunday 04 July 2010 22:49:48 Thomas Janssen wrote:
2010/7/4 Anne Wilson <cannewilson(a)googlemail.com>:
> On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
>> 2010/7/4 Anne Wilson <cannewilson(a)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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
1:13 a.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
1:14 a.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
1:16 a.m.
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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
1:30 a.m.
On Mon, Jul 5, 2010 at 6:31 AM, Eli Wapniarski <eli(a)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
Dubium sapientiae initium
1:38 a.m.
Quoting Thomas Janssen <thomasj(a)fedoraproject.org>:
On Mon, Jul 5, 2010 at 6:31 AM, Eli Wapniarski
<eli(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:53 a.m.
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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
1:57 a.m.
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
1:58 a.m.
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
2:06 a.m.
Quoting Kevin Kofler <kevin.kofler(a)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
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
2:13 a.m.
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
2:13 a.m.
2010/7/5 Anne Wilson <cannewilson(a)googlemail.com>:
On Sunday 04 July 2010 22:49:48 Thomas Janssen wrote:
> 2010/7/4 Anne Wilson <cannewilson(a)googlemail.com>:
> > On Sunday 04 July 2010 22:15:41 Thomas Janssen wrote:
> >> 2010/7/4 Anne Wilson <cannewilson(a)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.
--
LG Thomas
Dubium sapientiae initium
2:17 a.m.
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
5:37 a.m.
On 07/05/2010 09:13 AM, Thomas Janssen wrote:
[08:56]<annew> they are going to put it into
updates-testing
without 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.
--
Best regards,
Eike Hein
3:21 p.m.
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-testing
>
> without 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
--
New to KDE4? - get help from http://userbase.kde.org
Just found a cool new feature? Add it to UserBase
4:45 p.m.
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.
--
Timothy Murphy
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
5:36 p.m.
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,
--
José Abílio
1:37 p.m.
On Tue, Jul 6, 2010 at 11:49 AM, dexter <dex.mbox(a)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.
--
LG Thomas
Dubium sapientiae initium
5057
days inactive
5061
days old
85 comments
14 participants
participants (14)
-
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