| |||||||||||||
|
| |||||||||||||
The OSWatershed.org projectThe OSWatershed.org projectPosted Jul 21, 2009 4:22 UTC (Tue) by tannewt (guest, #59683)Parent article: The OSWatershed.org project
Hi, I'm Scott Shawcroft. Here are my replies:
(Log in to post comments)
The OSWatershed.org project Posted Jul 21, 2009 8:19 UTC (Tue) by kragil (guest, #34373) [Link]
Obsolete is a very bad word for what you are trying to convey. But I thought about it and I can not come up with a good term either.
Obsolete is something that will never get any patches. Maybe don't name it and just explain it a little more. (I thought about "upstream equality" which would certainly be better, but not perfect.)
The OSWatershed.org project Posted Jul 21, 2009 8:29 UTC (Tue) by jordanb (subscriber, #45668) [Link]
The reason why it's not possible to come up with a good word for it is that the entire concept is bogus.
Who cares if you have the latest version of a package, unless you *need* a feature of it, or you're doing development on it? If a distro still distributes Python 2.6, does that mean that they have an 'obsolete' package there?
If he wants to track divergence from the upstream, he should do something like compare the set of outstanding distributor patches. Or even more useful, look at the average *lifetime* of a patch. How quickly is it pushed upstream? That'll avoid bias against distributions that are aggressive about closing their own bugs, so long as they're still active in pushing things upstream.
The OSWatershed.org project Posted Jul 21, 2009 19:03 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
the reason that you care about your distro shipping version 8.1 when version 9.1 is out is that it becomes very hard to get support for version 8.1
Circularly reasoned Posted Jul 21, 2009 20:32 UTC (Tue) by man_ls (subscriber, #15091) [Link] That looks to me like circular reasoning. Usually you get support from your distro, not from upstream. If your distro gives you version 8.1 then they are supposed to support it; if not, they should distribute 9.1 or whatever they feel comfortable supporting.If your distro is not going to support the packages it distributes then support will be equally hard for 8.1 or 9.1 -- in this case you might just download the latest from upstream and be done with it. Or switch distros.
Circularly reasoned Posted Jul 21, 2009 21:28 UTC (Tue) by dlang (✭ supporter ✭, #313) [Link]
in theory you are right
but in practice your distro probably isn't going to do a very good job of supporting a version by themselves. the distro gets it's support from the upstream developers, and if those developers don't provide it because the version you are using is old it severely limits how good the distro support can be.
things work better the more people you have running a version, and it's even better when the developers run/support that version as well because they will be afar more familiar with the code and the problems than any one distro will be.
now, there are particular projects where this falls down
the upstream developers may not actually make releases, so the distro is forced to take a snapshot and support it.
the upstream developers may be doing such a poor job of quality control that the distros have to lag behind to have a working setup
the distros may be customizing the code enough that the upstream developers (and other distros) can't help
but overall I do think that it is much better to use a distro that keeps with a version that is supported upstream
Spiral reasoning rather Posted Jul 21, 2009 21:41 UTC (Tue) by man_ls (subscriber, #15091) [Link] In these fine points you are right too, but practice shows that even this level of detail does not cover the whole situation. Arguably the best supported distro is Red Hat, and it is hopelessly outdated by the time it comes out (it doesn't even make the author's list). And the most stable (IMHO the best community-supported) is Debian, which is also quite behind the times by the time it is released.Without even entering the mandatory stability-vs-currency dichotomy, keeping packages up to date is a very complex task and has a lot of variables. That is why the OSWatershed.org project is not so useful as it would appear at first sight. Still it is an interesting idea.
The OSWatershed.org project Posted Jul 21, 2009 9:16 UTC (Tue) by k3ninho (subscriber, #50375) [Link]
>Obsolete is a very bad word for what you are trying to convey. But I thought about it and I can not come up with a good term either.
'Superseded' is my suggestion, if you'll be so kind as to ignore the regressions. The older releases aren't obsolete in the sense of the definition at Wiktionary (which compares well with Google's 'Define:obsolete' search [2]). These older editions of software aren't obsolete (as in 'no longer in use; gone into disuse; disused or neglected (often by preference for something newer, which replaces the subject)' -- from Wiktionary). The evidence for that is the statistics shown here: it's still in use and very much not neglected.
I'm going to assume that there's a bias toward latest-and-greatest (possibly due to youth) which is part of this work. It's neat that someone's taken the trouble to assemble this data but don't know what you can really say about this: should everyone be using upstream and following it, so as to reduce effort finding and fixing bugs? Should there be a bug-fixed non-developmental Upstream series which is reliable and stable (and not labeled obsolete)?
[1] http://en.wiktionary.org/wiki/obsolete
The OSWatershed.org project Posted Jul 21, 2009 9:46 UTC (Tue) by kragil (guest, #34373) [Link]
If the greater Linux/FOSS ecosystem were to listen to Theo de Raadt (Dutch for "the rant" I guess ) we would all be tracking current.
AsiaBSDCon 2009:The OpenBSD Release Process: A Success Story
The OSWatershed.org project Posted Jul 21, 2009 10:01 UTC (Tue) by nix (subscriber, #2304) [Link]
"Unsupported upstream" might be a better term.
Of course then this founders on things like ffmpeg and (for a long time) glibc, which never even made stable releases (or threw them over the wall and forgot about them), so that the only thing upstream supported was the development trunk: yet they didn't expect average users to be running said trunk.
The OSWatershed.org project Posted Jul 21, 2009 12:46 UTC (Tue) by nowster (subscriber, #67) [Link]
> "Unsupported upstream" might be a better term.
Not all programs which are unsupported upstream are useless. Unless a better alternative comes forward, that program may be the only one that provides that function. Should a distribution drop a useful but stable program just because it hasn't been updated in the last five years?
The OSWatershed.org project Posted Jul 21, 2009 17:39 UTC (Tue) by tannewt (guest, #59683) [Link]
Again, this is one of the biggest controversies. How about 'old' or 'outdated'? Or is 'Not New' the best way of putting it?
The OSWatershed.org project Posted Jul 21, 2009 9:46 UTC (Tue) by errare_est (guest, #14275) [Link]
Lag is not as bad as Obsolete, and you already are using that word :)
The OSWatershed.org project Posted Jul 21, 2009 13:23 UTC (Tue) by kirkengaard (subscriber, #15022) [Link]
I will agree with pride that my distribution of choice is slightly more than half "stable" in its development branch at this point in time, and I think that's a great indicator of release-time balance. Perhaps "proven" is a less pejorative term, but more accurate than "stable," for the child-codebases that are not on the bleeding edge of your trees, but are far from obsolete.
The OSWatershed.org project Posted Jul 21, 2009 13:57 UTC (Tue) by spinochet (subscriber, #23939) [Link]
Lumping Debian experimental with Debian testing makes no sense to me. While many users of experimental may use testing (though I bet most use unstable), very few users of testing would use experimental. In trying to figure out where each of stable, testing, and unstable stood, I couldn't make heads or tails of your data. I'd suggest using the same groupings and terminology for releases as the distros do, if you want the data to mean anything to them.
The OSWatershed.org project Posted Jul 21, 2009 17:45 UTC (Tue) by tannewt (guest, #59683) [Link]
Perhaps the experimental/testing stuff is a result of me not being a Debian user. I don't use the same terminology so that I can compare different distributions. I know this comparison is controversial but I feel like it should be done to spark conversation.
The OSWatershed.org project Posted Jul 22, 2009 17:22 UTC (Wed) by spinochet (subscriber, #23939) [Link]
There is a succinct description of the meaning of these terms at <http://www.debian.org/releases/>.
Correctly mapping Debian releases Posted Jul 22, 2009 3:32 UTC (Wed) by fjpop (guest, #30115) [Link]
Lumping Debian experimental with Debian testing still makes absolutely no
sense.
If I look at the definitions in your theses, the correct mapping for
Debian experimental should IMO not be included with any of them.
BTW, how do you deal with snapshots taken from upstream source
I still agree with others that the way the data is presented gives a
As I've said in my initial comment: the terms obsolete and lag are
Also, I doubt that using "number of newer releases" as you do in 4.1.3 in
``Obsolete'' considered harmful Posted Jul 25, 2009 3:22 UTC (Sat) by Max.Hyre (subscriber, #1054) [Link] @lbt: 'obsolete' is one of the most talked about aspect. Any ideas of a better term?How about ``trailing edge''? It could be defined as any version older than the newest release from the project.
The OSWatershed.org project Posted Jul 26, 2009 10:14 UTC (Sun) by lab (subscriber, #51153) [Link]
Regarding 'obsolete', how about 'maturity'? It doesn't have the negative connotation, and indicates why the software is older- because it takes time to mature things. Of course, the converse connotation- 'immature' is not particularly nice either.... What about simply 'age'? The connotations of both high or low age are not overly negative, and it corresponds well to what's actually being measured- the age of the software..?
|
|
||||||||||||