[KVIrc] Proposal for a stable release of kvirc4
ctrlaltca at gmail.com
Mon May 17 23:45:18 CEST 2010
A long time has passed since the first talks about the possibility of
an official release of KVIrc4. We released 3 rc versions, and each one
helped us a lot gathering testers and collecting bug reports. The team
fixed mostly all of them and spent some time implementing new useful
features proposed by testers and causal users.
Nowadays, i think that our flower is full-blown and we need (read: urge)
to release it before it starts to.. overripe.
There are molstly two good reason for this, that i will try to explain:
1) After a lot of work (thank you Curan for that) we ended up with a
patch for the infamous bug #765. This took a lot of debugging efforts
(code flow checking, memory leaks checking, memory heap allocation
checking, bisecting, ...) and since all this debugging involved the
whole kvirc code, this ensures that the actual code base is really
tested, and guaranteed to be stable.
If we just let other changes flow in the main trunk, we'd gonna lose all
of this precious work and need to start checking everything again.
2) I've received a report on irc some days ago - the source wants to
stay anonymous - about a bad bug affecting our dcc system. Digging thru
the code, i found some format strings and a directory trasversal in our
dcc code - for the non-tecnical guys, let's say that a malicious user
could trick you into overwriting any file in your pc..
I've fixed the problem in trunk (r4317) and backported a patch to the
3.4 branch (r4335). I've also created new win32 snapshots, both for
kvirc4 and kvirc3.
Releasing to the public a fixed version soon is somewhat important!
while the bug reporter said he won't disclose the problem to the public,
we know our code is public and everyone can read it and understand how
to misuse this problem.
That's why, imho, we need to release a fixed version so that downstream
users (distro packagers, mantainers, etc) can catch it up and ensure
their users a safe chat session.
Releasing a new 3.4 version is not really an option, since afaik no
kvirc developers are still using a qt3-based build environment nowadays,
and in the 3.4 branch there are some bugs that would need to be fixed,
and a lot of fixes would need to be backported from trunk.
Anyway, i think the last word belongs to pragma.
Sorry for the long email, waiting for your comments :)
More information about the KVIrc