[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1009221520560.7689@nippy.intranet>
Date: Wed, 22 Sep 2010 15:44:21 +1000 (EST)
From: Finn Thain <fthain@...egraphics.com.au>
To: "Justin P. Mattock" <justinmattock@...il.com>
cc: Matt Turner <mattst88@...il.com>, trivial@...nel.org,
linux-kernel@...r.kernel.org,
"Maciej W. Rozycki" <macro@...ux-mips.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Randy Dunlap <rdunlap@...otime.net>,
Dimitry Torokhov <dmitry.torokhov@...il.com>,
Ben Pfaff <blp@...stanford.edu>,
Mike Frysinger <vapier.adi@...il.com>
Subject: Re: [PATCH]Update-broken-web-addresses-in-the-kernel
On Tue, 21 Sep 2010, Justin P. Mattock wrote:
> 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.
[snip]
> > 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).
I think the best solution might be to somehow ensure that, in future, new
links inserted into the kernel are qualified with a date stamp. E.g.
For technical information about the SUX-5000, please see:
<http://foo/bar> (retrieved 1990/6/22)
In this way, rather than adding loads of "www.webarchive.org" boilerplate
without solving the problem, we can push the extra workload back to the
patch authors instead of letting it fall to maintainers.
If you know perl, you might be able to achieve this with
scripts/checkpatch.pl.
Finn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists