В 13:33 +0100 на 02.12.2009 (ср), Gürkan Sengün написа: > I'm sorry about this, but please go blame the gnustep developers for this.
I will (as I planned to do a few months ago when I noticed the NSZoneMallocAtomic removal in a point release). But no matter what they do, we are the ones who are going to suffer and we are the ones to deal with all sort of breakages. (I am not sure why you feel offended -- my intention wasn't to blame you at all; I was just pointing out that we can't manage on the long term to handle problems like this, especially if they're introduced often and discovered post-factum. Think about the eventual runtime failures, too, they certainly prevail over FTBFSes.) > Besides, we have more bugs/problems if we don't upgrade. We will upgrade (that's unavoidable now anyway). I was talking about transitions 1.18 -> 1.20 for -base and 0.16 -> 0.18 for -gui/-back; i.e. tracking stable (even numbered) releases like usual. If we'll have to introduce Debian-specific SONAMEs (provided that we detect ABI breaks prematurely, which is not trivial for Objective-C libraries, as you know) for unstable micro releases and have library transitions fairly often, the release team will really hate us. > Nobody want's stoneage gnustep libs. People install GNUstep from source, is > that > what Debian meant to be? Make users and developers suffer by having to > install > everything by them selves? I doubt. Of course not. But you and I cannot deal with an avalanche of RC bugs just because we ought to ship the newest (unstable) core libraries. So there's a balance to strike. (Let's take this discussion to our list and gnustep-dev; I'll post something there soon.) -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
