RFC: Kopete 0.12.1

Hi,

I have fixed some bugs in the 0.12 branch.
(I did that today, because i had free time, and i wanted to code something
rather than try compiling stuff in kde4)

of them (Bug 127749) is major.
are less important, but at least are fixed.

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 ?

Personally, if we are allowed to push it I would say yes. That would improve
experience of most users without complicate things.

In any case, i think that if we ever release Kopete 0.12.1 then end of july
would be a good date.

Yes, i know, we should hack on kde4, but we should fix the few major bugs
that are easy to fix.
Lots of bugs in bugzilla are really minors and would require lots of code, so
I'll not fix them




kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)


H1BAGbXsgNgx2fL6sG9/Hwc=
=r8W1
PGP SIGNATURE

Wednesday 07 June 2006 18:13, Goffart wrote:
Hi,
>
I have fixed some bugs in the 0.12 branch.
(I did that today, because i had free time, and i wanted to code something
rather than try compiling stuff in kde4)
>
of them (Bug 127749) is major.
are less important, but at least are fixed.
>
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 ?
>

no

Personally, if we are allowed to push it I would say yes. That would
improve experience of most users without complicate things.
>
In any case, i think that if we ever release Kopete 0.12.1 then end of july
would be a good date.
>

i don't want to release 0.12.1. You'd have to get Kopete's bug count below 100
on the 0.12 branch before I'd even begin to consider a 0.12.1 release. The
reason for this is that the more time we spend on 0.12, the less there is for
kde4, and we need Kopete in KDE 4 to be really solid, because I want to make
it 1.0.

Yes, i know, we should hack on kde4, but we should fix the few major bugs
that are easy to fix.
Lots of bugs in bugzilla are really minors and would require lots of code,
so I'll not fix them

good idea. we have many things to work on and make decisions on for trunk, and
we need to get a move on. A tech preview of KDE 4 is going to be in october,
that's not going to be a lot of time.
--
Matt

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Hello!

Wednesday 07 June 2006 18:31, Matt Rogers wrote:
Wednesday 07 June 2006 18:13, 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 ?
>
no

Why not? Kopete is already included in KDE 3.5, but old, outdated one. There
is no even proper encoding support in protocol in that version!
This outdated version has lots of bugs which are already fixed in 0.12,
generating lots of bug reports.

Imagine regular user of Linux distribution which uses KDE. This user starts
Kopete, finds it unworkable, sends bug report. What do you guys reply to this
bug report? "Upgrade to 0.12", right?

How this poor person is supposed to upgrade? Download tarball, compile and
install? C'mon, it's XXI century. Do you really think that average Linux user
is sophisticated enough to do this?

Even if he's sophisticated to compile and install, this will replace files
which belong to kdenetwork package, creating inconsistency in package
management system. This inconsistency is a time bomb, actually: another
software update will rewrite Kopete 0.12 with the version from kdenetwork
package again.

Which other ways to install Kopete 0.12 are available? RPM or DPKG package? It
won't work, because this package will conflict with files from kdenetwork.
Install into home directody and use KDEDIRS path? I use this method, but it
won't work for most users, because it requires even more sophistication than
compiling and installing.

What I want to tell you is that this old Kopete included in kdenetwork is the
real pain in the ass, both for users and developers. It makes the new Kopete
painful to install for users. Also, it makes life more complicated for
developers, because de facto there are 3 different Kopete branches: trunk,
0.12 and the one in kdenetwork.

The only resolution of the problem I've outlined above is to eliminate old
kdenetwork version of Kopete as soon as possible. There are only two ways to
do it: either completely remove Kopete from kdenetwork package, or replace it
with Kopete 0.12. Which way do you prefer?

-- Girko, http://www.infoserver.ru/~ol/

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Le jeudi 8 juin 2006 04:14, Girko a *:
Why not? Kopete is already included in KDE 3.5, but old, outdated one.
There is no even proper encoding support in protocol in that version!
This outdated version has lots of bugs which are already fixed in 0.12,
generating lots of bug reports.

[]

I fully agree with you.

Even if few distribution already have package for Kopete 0.12, this will be
complicated.

Frugalware (the distribution I have on my laptop) removed kopete from
kdenetwork 3.5.3, some others will include kopete 0.12 in their kdenetwork
package.

So what's the point of releasing a new version of kopete 0.11 with kde 3.5.4
and co ?


The only resolution of the problem I've outlined above is to eliminate old
kdenetwork version of Kopete as soon as possible. There are only two ways
to do it: either completely remove Kopete from kdenetwork package, or
replace it with Kopete 0.12. Which way do you prefer?

Removing kopete from kdenetwork is not possible (compatibility things, we
even still have kedit)

So guess which I prefer.


But nothing warant that we be allowed to do that.



kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)


Vf7y+/UfFowHBM3yi4S=
=msEW
PGP SIGNATURE

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.

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.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | N
966C 33F5 F005 6EF4 5358 | , Norway


kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)


bMQPXRZ/=
=4C6i
PGP SIGNATURE

Hello!

Wednesday 07 June 2006 22:23, Goffart wrote:
Le jeudi 8 juin 2006 04:14, Girko a ©*:
Why not? Kopete is already included in KDE 3.5, but old, outdated one.
There is no even proper encoding support in protocol in that
version! This outdated version has lots of bugs which are already fixed
in 0.12, generating lots of bug reports.
>
[]
>
I fully agree with you.
>
Even if few distribution already have package for Kopete 0.12, this will be
complicated.
>
Frugalware (the distribution I have on my laptop) removed kopete from
kdenetwork 3.5.3, some others will include kopete 0.12 in their
kdenetwork package.
>
So what's the point of releasing a new version of kopete 0.11 with kde
3.5.4 and co ?

That's the point. _Some_ others. Most distributions will not bother.

The only resolution of the problem I've outlined above is to eliminate
old kdenetwork version of Kopete as soon as possible. There are only two
ways to do it: either completely remove Kopete from kdenetwork package,
or replace it with Kopete 0.12. Which way do you prefer?
>
Removing kopete from kdenetwork is not possible (compatibility things, we
even still have kedit)

What kind of compatibility do you mean? Is there any other component in KDE
which uses Kopete libraries or DCP interfaces? And, by the way, updating to
Kopete 0.12 will break binary compatibility anyway (at least, libkopete_oscar
from 0.12 is not compatible with 0.11). do I miss something?

So guess which I prefer.

Actually, there is third way to solve the problem - rename Kopete, as it was
suggested on April 1st, so it won't conflict with files in kdenetwork. There
will be two entries in KDE menu: Kopete and KDE Messenger. Guess, which one
will be more popular? :-)

-- Girko, http://www.infoserver.ru/~ol/

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Hello!

Wednesday 07 June 2006 23:50, Will Stephenson wrote:
Thursday 08 June 2006 04:14, Girko wrote:
Which other ways to install Kopete 0.12 are available? RPM or DPKG
package? It won't work, because this package will conflict with files
from kdenetwork. Install into home directody and use KDEDIRS path? I use
this method, but it won't work for most users, because it requires even
more sophistication than compiling and installing.
>
I've packaged 0.12 as 'kopete' in the KDE:Backports project for openSUSE.
>
With RPM you can put
: kdenetwork-InstantMessenger <= 3.5.3
Conflicts: kdenetwork-InstantMessenger
in kopete.spec and RPM will sort out the rest.

Wow, you Suse guys are lucky to have kdenetwork package splitted into small
subpackages! Unfortunately, I use Fedora, which has just single monolitic
kdenetwork package (and kdenetwork-devel, but this does not help in this
case). Bad luck. :-(

-- Girko, http://www.infoserver.ru/~ol/

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Hello!

Thursday 08 June 2006 00:38, Thiago Macieira wrote:

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.

-- Girko, http://www.infoserver.ru/~ol/

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Thursday 08 June 2006 09:38, Thiago Macieira said:
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.

I have a patch that minimally backports the UI changes to 0.11 that are in the
suse packages of 0.11.1 that fulfil these rules.

Will

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Thu, 8 Jun 2006, Will Stephenson wrote:

Thursday 08 June 2006 04:14, Girko wrote:
>Which other ways to install Kopete 0.12 are available? RPM or DPKG package?
>It won't work, because this package will conflict with files from
>kdenetwork. Install into home directody and use KDEDIRS path? I use this
>method, but it won't work for most users, because it requires even more
>sophistication than compiling and installing.
>
I've packaged 0.12 as 'kopete' in the KDE:Backports project for openSUSE.

Nice! It might be also good to mention this at the openSUSE Kopete page:
http://en.opensuse.org/Kopete

even add that page to the Kopete releases page, so that users know
where to get it easily (I didn't for instance, besides reading the ML):


Thanks
Michal

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Thu, 8 Jun 2006, Girko wrote:

Wednesday 07 June 2006 23:50, Will Stephenson wrote:
>Thursday 08 June 2006 04:14, Girko wrote:
Which other ways to install Kopete 0.12 are available? RPM or DPKG
package? It won't work, because this package will conflict with files
from kdenetwork. Install into home directody and use KDEDIRS path? I use
this method, but it won't work for most users, because it requires even
more sophistication than compiling and installing.
>>
>I've packaged 0.12 as 'kopete' in the KDE:Backports project for openSUSE.
>>
>With RPM you can put
>: kdenetwork-InstantMessenger <= 3.5.3
>Conflicts: kdenetwork-InstantMessenger
>in kopete.spec and RPM will sort out the rest.
>
Wow, you Suse guys are lucky to have kdenetwork package splitted into small
subpackages! Unfortunately, I use Fedora, which has just single monolitic
kdenetwork package (and kdenetwork-devel, but this does not help in this
case). Bad luck. :-(

Can't you just use the SUSE rpm package? at least src.rpm and rebuild
it on your system? Might work, the packages shouldn't differ that much
(provided that you don't need the rest of kdenetwork).

Michal

kopete-devel mailing list
kopete-devel (AT) kde (DOT) org

Girko wrote:
>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.

The policy is there to guarantee that we don't release newly-broken stuff.
The branch is frozen for a reason.

You have known all along that Kopete 0.11 is part of KDE 3.5. You should
have backported the bugfixes to it. New features can be backported now
too, as long as you follow the rules.

If the big problem is kopete being in kdenetwork, then we can just remove
0.11 from KDE 3.5. Problem gone.

But adding 0.12 to it is not acceptable. Who is going to review ALL
changes, to make sure they are ? Remember it must be someone different
from the person who wrote the code in the first place.

This is not the first time packagers have had to deal with this issue:
Kopete releases standalone versions from time to time. It has happened
before and it may happen again. They should have learnt by now.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
thiago.macieira (AT) trolltech.com Trolltech AS
GPG: 0x6EF45358 | Sandakerveien 116,
E067 918B B660 DBD1 105C | N
966C 33F5 F005 6EF4 5358 | , Norway


kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)


QyqLz7GyQ27A/+ZTCEegXC8=
=kygd
PGP SIGNATURE

Le jeudi 8 juin 2006 12:31, Michal Svec a *:
Thu, 8 Jun 2006, Girko wrote:
Wow, you Suse guys are lucky to have kdenetwork package splitted into
small subpackages! Unfortunately, I use Fedora, which has just single
monolitic kdenetwork package (and kdenetwork-devel, but this does not
help in this case). Bad luck. :-(
>
Can't you just use the SUSE rpm package? at least src.rpm and rebuild
it on your system? Might work, the packages shouldn't differ that much
(provided that you don't need the rest of kdenetwork).

Even if can do this, the average user will not.
Most people just use what the distribution put by default.



kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)


LfLFb7jqlFChlbyDTzz8ebI=
=HDZd
PGP SIGNATURE

Le jeudi 8 juin 2006 12:28, Thiago Macieira a *:
Girko wrote:

The policy is there to guarantee that we don't release newly-broken stuff.
The branch is frozen for a reason.

Yes of course.

But Kopete 0.12.1 (or .2) will not be a newly-broken stuff, it will be tested
as a separate release during months

>
You have known all along that Kopete 0.11 is part of KDE 3.5. You should
have backported the bugfixes to it.

Most of bugfixes have been backported
But there we speak about "feature fix" ie new features that "fix" problem due
to their lack in 0.12 (exemple: the new chat style engine which replace the
broken old one, or the muc improvement in jabber, or the support of more jep
to be more standard compilant)

New features can be backported now too, as long as you follow the rules.

Nice: then what rules does Kopete 0.12 not follow ?

You accept to backport all feature one by one, but not the whole Kopete ?
backporting kopete as a whole will be infinitively more easy.

Also, by backporting only few feature, we risk to backport code that rely on
others code that have not been backported, and introduce bugd

If the big problem is kopete being in kdenetwork, then we can just remove
0.11 from KDE 3.5. Problem gone.

Can we ?
Then ok, let's remove kopete from kdenetwork 3.5.

Just that i think that the solution is ridiculous: We don't want to introduce
new bugs, but it's ok to have a serious regression (no more im client)

but also count application that rely on kopete (dcop script, kmail
integration, ) that would have just kdenetwork as dependencies

But adding 0.12 to it is not acceptable. Who is going to review ALL
changes, to make sure they are ? Remember it must be someone different
from the person who wrote the code in the first place.

good point.
but there is always solution, we are enough developper to review eachothers
code.

This is not the first time packagers have had to deal with this issue:
Kopete releases standalone versions from time to time. It has happened
before and it may happen again. They should have learnt by now.

This is the first time it is a standalone package only.


kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.3 (GNU/Linux)


nF+izebba05wR9nWZBw8hkc=
=pGKY
PGP SIGNATURE

Goffart wrote:
>You accept to backport all feature one by one, but not the whole Kopete
? backporting kopete as a whole will be infinitively more easy.

Indeed it would, which is precisely the problem.

Lots of problems could be overlooked because it's one big patch. Besides,
if it's one single commit, it would need to be someone outside of Kopete
to review it, since everyone in Kopete had a hand in that big patch.

You'll be hard pressed to find someone to review it.

>Also, by backporting only few feature, we risk to backport code that
rely on others code that have not been backported, and introduce bugd

Which is why backporting the entire thing is dangerous, since we don't
know what relies on what, and what could be more broken now than in 0.11.

>But adding 0.12 to it is not acceptable. Who is going to review ALL
>changes, to make sure they are ? Remember it must be someone
>different from the person who wrote the code in the first place.
>
>good point.
>but there is always solution, we are enough developper to review
eachothers code.

So you're proposing individual patches. I'm fine with that.

But this must be truly reviewing, not just a formality. The rules are
there to ensure quality, not to hinder development.

If you think it would be a waste of time to follow them, then don't and
advise kde-core-devel of the issue. You know my position, but I of course
do not speak for everyone involved.

I'd much rather that the bugfixes were backported to 0.11, that KDE 3.5.4
included 0.11 and that a separate 0.12.1 release were made. Distributors
who still haven't figured out how to make separate packages deserve to
get problems anyways (IM).

>This is not the first time packagers have had to deal with this
>issue: Kopete releases standalone versions from time to time. It has
>happened before and it may happen again. They should have learnt by
>now.
>
>This is the first time it is a standalone package only.

0.10.2 was a standalone package only.

--
Thiago J Macieira - thiago.macieira AT trolltech.com
Trolltech AS - Sandakerveien 116, N , Norway


kopete-devel mailing list
kopete-devel (AT) kde (DOT) org


PGP SIGNATURE
Version: GnuPG v1.4.2.2 (GNU/Linux)


I/MAAl/TKHmnryH/Mwpxfy8=
=FAbp
PGP SIGNATURE