Messages in this thread | | | Date | Tue, 21 Sep 2010 20:12:14 -0700 | From | "Justin P. Mattock" <> | Subject | Re: [PATCH]Update-broken-web-addresses-in-the-kernel |
| |
On 09/21/2010 07:41 PM, Finn Thain wrote: > > On Tue, 21 Sep 2010, Justin P. Mattock wrote: > >> On 09/20/2010 10:17 PM, Finn Thain wrote: >>> >>> I would say that if a URL is in the web archive, then no patch is needed. >>> >>> Finn >>> >> >> before I go and remove all of the archive.org stuff, can I get some feedback >> from other people as well on having this used? i.e. if keeping the old broken >> link in the kernel, how will people know to go to archive.org or any other >> archive site to read the old info?, as opposed to already having this in there >> so people can just click and go?.. >> >> The idea to use archive.org came from this thread: >> http://amailbox.org/mailarchive/linux-kernel/2010/7/21/4596207/thread >> where there are people still wanting to read the old info. > > If people want to read the old links, and they don't know about > archive.org, then they should. If you've seen one > "http://web.archive.org/web/*/foo/bar", you've seen them all. So this is > bloat in some sense. >
I dont like this.. reason for just ripping them out from the first series back in july/august(but to accommodate peoples needs I added this).
> As the web matures, and more and more information disappears from the web, > archive.org will become common knowledge (if it isn't already). >
I had never heard of it.. but nor do I ever really search for some technology back in the 90's(but then again I suppose I do from time to time).
> Applying your reasoning that "people are still wanting to read the old > info", a policy to accept patches like: > - http://foo/bar > + http://web.archive.org/web/*/foo/bar > would imply another continual stream of patches when the domain foo > changes hands. Then you have to pach, > - http://web.archive.org/web/*/foo/bar > + http://web.archive.org/web/YYYYMMDDHHMMSS/foo/bar > > Then the problem becomes what is the correct YYYYMMMDDHHMMSS? The one > closest to the datestamp of submission of the patch? Or the datestamp from > the email that submitted the patch? When these questions arise, it becomes > a new burden on maintainers to determine the right version of the web page > in the archive, and whether or not the latest version is the best one. >
just was looking for apmv1.1.doc my search results are not so good(everything is pointing to v2) but it is tricky to decipher..
> So both of these (arguably) continuous streams of patches would become a > burden on maintainers and offer little or no benefit to those reading the > source code. >
true.. I see it as accommodating.. but then again maybe a museum if you want to search about the first commador64 as opposed to ps3/xbox(I know bad analogy, but only thing I can think of).
> The benefit to end users is also dubious, because you're chasing web pages > that were abandoned, implying low value in the first place. >
but at the time that was hot off the press info..(which I need to respect, and should be taken care of).
> Though they move from one URL to another, the links that are valuable are > the web pages that are regularly updated. These are are the links that > need to be kept up-to-date. And I think your work in that direction is > valuable. > > Thanks. > > Finn >
one thing that gets me.. is, is the maintainer/author/company of their _old project_, (even if it's a link)can be that irresponsible to abandon their child like that? atleast have the responsibility to update the kernel, or have one of the hyperlink forward things etc..(the leave it, im on to bigger better things I don't need this anymore _misfit_ eeks me, but we all are guilty of this one way or another..) keep in mind that's just my 00.02$
Thanks for the help as well my friend.. FWIW I went through the arch stuff and resent, ended putting the archive.org links on a separate patch to make things easier..(and in the meanwhile I'm going through the rest...(but might crap out..and end up having a beer..(we will see though)).
Justin P. Mattock
| |