kdepim4.5

[Thomas Janssen]

On Sat, Jul 3, 2010 at 7:18 AM, Eli Wapniarski <eli at 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 at 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