Bdale Garbee wrote: > In article <[EMAIL PROTECTED]> you wrote: > > : What will you record as fixing-version ?
> If we reorganize the server the way I've been discussing recently, this > problem would go away... because no package could ever get into a stable > tree without going through unstable... one version stream should be enough. I think there will still be a need for back-patching versions in the 'stable' tree. Consider a situation with xfree86 3.3 in 'stable' and xfree86 3.4 in 'unstable'. A security bug is found in the wrapper we use, and has to be fixed in both. We will have to offer the people who use 'stable' a way to secure their versions without having to upgrade to xfree86 3.4. However, since such cases will (one hopes :) be rare, it should be sufficient if the bug system has an escape hatch for such cases. And it will have one, since there is no need to do away with the unconditional "close bugreport", and that can be used for such backpatches. Security bugfixes are normally tracked pretty closely on their way through the archive anyway. > If we persist in managing the archive as we have been for the last > year or so, you are correct that recording the version that closes a > bug is problematic. A more complicated scheme might still be useful. If a bug is fixed in version 1.5, that does not mean that version 1.0 has the problems -- perhaps the bug wasn't introduced until version 1.3. Thus, it would be nice if the system could handle ranges of version numbers as an option. Alternately, such ranges could be keyed to distributions. "This bug is fixed by version 1.5, but it only existed in unstable". It's probably safe to assume that the earlier buggy versions are not going to make it into stable. I think this method is less robust, though. Richard Braakman -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
