[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] RFC:  Kopete 0.12.1
From:       Oleg Girko <ol+kde () infoserver ! ru>
Date:       2006-06-08 8:24:37
Message-ID: 200606080124.37422.ol+kde () infoserver ! ru
[Download RAW message or body]

Hello!
On Thursday 08 June 2006 00:38, Thiago Macieira wrote:
> Olivier Goffart wrote:> >I also think we will probably meet the requirement to go \
> in KDE 3.5.x> >Kopete 0.12 will be well tested since it has been released.> >And it \
> will be merged with trunk.> >> >But do we want Kopete 0.12.x in KDE 3.5.x š ? š>> \
> Sorry, the changes are too large to allow a simple move of 0.12 to> \
> branches/KDE/3.5. KDE 3.5.x is permanently frozen into 0.11.x.>> So, unless you \
> *backport* the changes from 0.12 to 0.11, those fixes will> not be in KDE 3.5.4.
May by, just backport _all_ changes between 0.11 and 0.12? :-)
> Does anyone want to do the backporting? If you want, remember that each> individual \
> patch going in must obey the backporting rules of the unfrozen> 3.5 branch.
So, what's the point? Keep a piece of crap noone can use anyway just because policy \
says that? Policy is meaningful when it helps, but in cases when it hurts, exceptions \
should be made. And Kopete is really an exceptional case. It was included in \
kdenetwork release when it was not even close to production quality (no insult here). \
It was developed then outside of kdenetwork. It just does not look like an integral \
part of kdenetwork. And now, when it reached the state when it's usable and stable, \
it can't be included because of what? Just show me a single _practical_ reason. -- \
Oleg Girko, http://www.infoserver.ru/~ol/_______________________________________________kopete-devel \
mailing listkopete-devel@kde.orghttps://mail.kde.org/mailman/listinfo/kopete-devel


[prev in list] [next in list] [prev in thread] [next in thread]