On Fri, Feb 24, 2006 at 10:25:14AM +0100, Mich?le Garoche wrote: > Le 24 f?vr. 2006 ? 09:53, Daniel Macks a ?crit : > >But seriously, we can't require of > >ourselves a higher level of quality than the uptream authors > I think the contrary, if obviously a package does not work properly, > either it has not to be put in fink and bug reported to gnome, or it > has to be patched so that it works and also the bug be reported to > gnome.
But it *did* work properly in my testing. That's why I committed it. > >. It seems > >unlikely that an upstream package would have gone through a whole > >unstable branch series then a new stable series and have serious > >upgrade breakage or interface incompatibilities. So if they say "it's > >compatible", it's been tested by them (these versions are already > >several months old), and we don't find any problems in some basic > >testing and usage, that sounds to me like it's ready to release. > See for example: <http://bugzilla.gnome.org/show_bug.cgi?id=326071> Oh come on now...it doesn't make sense to say "we won't release until every upstream bug including ones that aren't found yet are resolved". Should we hold fink at 2.10.x until upstream 2.14 comes out (i.e., no more bugfix release on the 2.12.x series) before fink goes to 2.12? You also seem to be assuming that libfoo-2.12.0 doesn't include fixes for bugs in libfoo-2.10.x. Also note that the bugzilla you cite is for an odd version (standardly a development branch)...fink tends to stay with stable/release branches specifically to allow upstream to shake out the more blatant bugs like that one (which would have blocked building of that package on *any* fink machine). > >Fink has tried to coordinate > not very hard though. I've spent the past five minutes trying to think of a polite way to respond to that. I can't, so I won't. > >a full gnome2.x suite in exp/ and fully > >test all its interactions before releasing it. > > >The issue here is just a missing BuildDepends. > But how can it be?:-) Because I don't test everything under every condition. Nor do you, nor does anybody. We rely on others with different configurations to find incorrect assumptions. If we only committed what worked perfectly (even "perfectly within the limits of upstream") in all cases and played nicely with all other packages, we wouldn't have an unstable tree. Even for something as fundamental as dependencies, you're asking that we not release a new version until we test-build it in the presence and absence of every other package, and test every one of those others in the presence and absence of the new one. The really best we can do is try to get it right, and fix it when it isn't. > >Stuff like that happens > >all the time, and gets fixed as soon as someone on a system without > >[whatever package] recognizes it problem. Or when someone discovers > >some sepcific combination os packages that triggers some weird > >interaction, for example, recent issues of libgnome2 + gnome-libs. > That's the problem here. As long as gnome would not be considered in > fink as some monolithic system like kde, it's likely not to work > properly. Right. Because it's not monolithic and it's not even a well- coordinated aggregate except on the first day of its release. It's got a jillion packages that all have their own bugfix release schedules, and mistakes that get made and then fixed, just like fink itself. > Well, I've already said it so much times, it is probably useless that > I say it another time. I guess we have to stay at disagreement there, then. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-devel
