> > The flip side is that we can provide them with a "localized" > > (not in the i18n sense!) fix much sooner. > > The current snapshot system contains a patched version (after the fix is > applied) within 2 hours at most for source distributions and 4 hours for > win32 distributions.
By localized I meant that only the part of the code that the user was worried about gets the fix; quite often, people don't even want to try our stable snapshots in case they introduce more bugs. > > This isn't really a problem as you tend to mark all bug > > reports as bogus anyway, and no one else provides support. > > I beg to differ, there are plenty of people (not to say that there couldn't be > more ;) ) who handle bugs etc... you need to look no further then the NEWS > file. > > I may have misunderstood you, so please correct me if I am wrong. I was using Jani's own brand of humour; I do know just how much work goes into bug fixing (I've spent many hours of my own time there too, even though I've not been so prolific in that department recently). > but it seems > are you advocating a system where by modules are compiled as shared. If the person making the installation wishes it, they can do that now. I am not advocating a change in our default installation. > This > approach would open a whole can of worms with users using conflicting module > versions, trying to load same modules more then once and so on. We have that now; it happens rarely (although more often on windows). > Not only will > this be a headache for the users, but also for the QA/developers who wish to > solve user reported problems. Without a way to determine the exact version of > the module it'd be nearly impossible to determine what code is the user > actually using. Modules have a version field, and the pear/pecl installer keeps track of the installed version. None of these problems are insurmountable, nor are they terrible, and none of them will affect anyone doing a default install. If we worry about everything that might possibly make things slightly harder to debug, then we shouldn't make any changes to the code, write no more new features and fix bugs for the rest of eternity. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
