Re: Proposed release goal: removal of wxwindows2.4
Hi,
On Tue, Jun 26, 2007 at 02:23:16PM +0200, Jérémy Bobbio wrote:
> I would like to propose a new release goal: the removal of the outdated
> wxwindows2.4 library.
I think proposing this as a release goal is a bit premature, since
what you are really proposing is to drop a number of stable, mature
applications. If you solve that problem, this library will vanish
naturally, if you can't, this goal will either not be met, or have
a net negative impact on the distro and its usability for the
affected upstream authors and their users.
> Upstream as already released the 2.8 versions which makes 2.4
> unsupported.
This statement is non sequitur, 2.4 was already unsupported upstream
long before 2.6 was released. Historically wx releases don't actually
become stable and widely adopted until upstream has abandoned a branch,
so ironically, that is a Good Thing. 2.4 has also survived years with
very few bug reports. The same cannot be said for 2.6 which has accrued
them steadily, nor 2.8 which accrues about the number open for 2.6 every
single day on the upstream lists still.
> WxWindows 2.4 also depends on GTK+ 1.2 which is outdated as well.
This I suspect is going to be more of a problem. I'm not sure what else
still depends on gtk1 or how much longer people will be motivated to
maintain it. But while its all stable and relatively bug/maintenance
free, and still has users, I don't see 'outdated' as a good argument to
break things that aren't broken or to summarily discard proven stable
applications from the distro.
> It sounds like a realistic goal to migrate affected packages to at least
> WxWidgets 2.6 before Lenny is released.
If you can prove that, I won't argue, but people had at least that long
to do this for etch. That it didn't happen says something is missing
from the assumption this will be easy.
Migrating (some) things to 2.6 might be a helpful interim step, but I
don't think that should be a goal for Lenny, since 2.6 probably has more
chance of being dropped before then. A number of upstream projects that
were using it already require 2.8 in their latest versions, 2.6 has just
been too buggy/incomplete for them, and wx3 is looming which threatens
to obsolete both of them by forcing people to rewrite their apps yet
again. It would just be cruel and unproductive to force everyone who's
string handling was broken in the 2.4 -> 2.6 transition to spend a lot
of work making their apps work with 2.6/2.8, when all that work will
need to be thrown away again in a few months when wx3 becomes the new
must-have release and breaks it all again.
If you are really interested in developing a viable release plan for
Lenny, I'd look at how the expected release schedule for wx3 is going
to fit with our tentative timetable, then assess what it will take to
migrate the remaining 2.4 apps to it. That will minimise the amount
of busywork that will need to be undone again when upstream abandons
the 2.6/2.8 string handling methods for a new and different nightmare.
To be frank, I'm not really sure if 2.8 is ever actually going to be a
viable release candidate. That depends a lot on how soon wx3 comes to
steal its thunder and how many people put in the effort to fix the
enormous number of bugs it seems to suffer from (now that it too is
being abandoned by the majority of 'core' developers for wx3). Any
planning that doesn't take all that into account is going to itself be
obsolete by the time lenny actually freezes.
The main thing to remember is that the library itself is unimportant
to most users, so if you are going to set goals that affect it, what
you need to take into account is what the application developers are
planning to release in time for the lenny freeze. When your plan
caters to the individual goals of all of those people, then what to
do about the library will be obvious, the work to do it will already
be in progress, and most importantly: remaining RC problems will be
found and fixed promptly. The same will not be true of any plan that
dictates ultimatums to them rather than responding to their actual
needs come freeze day.
I don't think there is enough information to compose a concrete plan
in much detail yet, but I'll be glad for any clues you can share if
you have time to probe about in the right corners for them.
Keep me in the loop as you build up a workable picture... I would
like to have a well known plan before too long, but right now I see
too many uncertainties that only time and maybe effort can untangle,
and just tossing more wx versions into the archive, in the hope that
maybe people will switch, is a fairly proven anti-pattern that is now
recognised in -policy and one I would like to avoid.
We can bug the RM's about it if it looks like things really are going
to cut it fine with the freeze date, until then, they probably have
nastier transitions to fret over than this one -- and I already still
owe Steve a beer from the last time an upstream id-ten-T glitch made
this a bonafide last-minute release blocker, so I'd prefer this to
all be over well before then ;-)
Cheers,
Ron
Reply to: