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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
