On Sun, 2002-09-22 at 14:30, SI Reasoning wrote: > David Walser ([EMAIL PROTECTED]) wrote*: > > > >--- Ben Reser <[EMAIL PROTECTED]> wrote: > >> On Sun, Sep 22, 2002 at 11:03:09AM +0800, Leon > >> Brooks wrote: > >> > Perhaps we can do a `9.0Q Download Edition' which > >> is Cooker from a week or > >> > fortnight after release? (-: Q as in Quiet or > >> Quiescent :-) > >> > >> Isn't that what mandrakefreq and updates are for? > > > >Well 8.2 really stabilized in Cooker a few weeks after > >release, but you couldn't have gotten to that just > >from updates. > > the problem with that is that cooker being a developer model, you never really know > when the switch happens on packages from stabilizing 8.2 to starting development on > 9.0. At any time an unstable package can be introduced by adding in new features, > etc....
One thing I've been wanting to do here is to set up a partial mirror of cooker that holds only packages which haven't changed in (say) 2 weeks. The idea being that once a package reaches a certain level of stability it won't be modified for some period of time. I'm thrilled to say that from watching this list it seems that problems generally get fixed inside of a week after they're first identified (or at least an attempt is made inside that time). I don't know how to handle dependencies there, but it would be a way to allow users to stay relatively up to date whilst still having a certain amount of stability. It would also be nice to have some utility in mandrake that implements some sort of "trust metric" system. If you're having a problem with a package, you have a simple utility that talks to a server and says taht you're having a problem with package X. It should have the option to give more info, but that's not really the point. There could then be a truth metric (or weight if you will) assigned to your vote that the package is bad by some "honesty" co-efficient assigned to you in a database. Now the idea is that the more package problems you report which are consistent with other reports, the higher your honesty metric, and thus the faster your problems are made known to developers etc (since your vote will count more than someone else's who hasn't reported any bugs consistent with the mandrake community). If you aren't as technically competent and report problems with packages which are actually "false" (ie user errors and such), then your "honesty" metric reduces. Now, there are three ways this becomes useful: 1. Mandrake developers have a single place to find the most genuine bugs that are attracting the most attention. I suspect that the details will be discussed here on the cooker list. 2. Users can have an option in urpmi that tells it to install only packages with < x weighted votes / time since release / urpmi installs (although that's more difficult. Urpmi again would need to talk to a central server and that's a bottleneck I don't think we want). 3. It opens up bug reporting to a much larger community without increasing the number of false alarms. So then, you again have a reasonably reliable way to keep your system up to date with the latest fixes that has a substantially lower probability of breaking your system. Just a thought. James.
