All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: "Justin P. Mattock" <justinmattock@gmail.com>
Cc: Joe Perches <joe@perches.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	trivial@kernel.org, linux-kernel@vger.kernel.org,
	linux-wireless@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-fbdev@vger.kernel.org,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
	linux-ide@vger.kernel.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Matt Turner <mattst88@gmail.com>,
	Dimitry Torokhov <dmitry.torokhov@gmail.com>,
	Mike Frysinger <vapier.adi@gmail.com>
Subject: Re: [RFC v4]update broken web addresses in the kernel.
Date: Tue, 28 Sep 2010 11:37:57 +1000 (EST)	[thread overview]
Message-ID: <alpine.OSX.2.00.1009281119570.276@localhost> (raw)
In-Reply-To: <4CA0CB0F.3060303@gmail.com>


On Mon, 27 Sep 2010, Justin P. Mattock wrote:

> On 09/27/2010 09:03 AM, Joe Perches wrote:
> > On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote:
> > > On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote:
> > > > Below is an updated patch from the original fixing broken web 
> > > > addresses in the kernel. Thanks for all the help and info on this 
> > > > to everybody.. Hopefully I didnt miss any of them(if so let me 
> > > > know, and I'll resend).
> > > Changing a URL for a relocated page is one thing, but removing links 
> > > isn't necessarily a great idea.  Even if the site is technically 
> > > gone, it may be possible to find information e.g through the 
> > > Internet Archive Wayback Machine.
> > 
> > Perhaps it'd be better to scrape the contents of the various web 
> > pages, collect them somewhere like wiki.kernel.org and encourage 
> > others to put new contributions in that site.

The copyright problem aside, this might be a good idea for material not 
already archived but I don't think it makes sense to start a new 
archive when archive.org (or other) has the information.

And which version(s) do you scrape? I discussed some problems with 
changing URLs in another thread: http://lkml.org/lkml/2010/9/22/22

Anyway, without knowing what future archive(s) would be available or 
relevant to any given URL in the future, I think the best we might do is a 
"Retrieved on YYYY-MM-DD" qualification for new URLs.

> 
> 
> yeah I think somebody was saying something about having a separate file, 
> with all the web addresses in them or something...In any case, up to you 
> guys..

I don't see how moving the addresses would help.
And would it not make the information harder to find?

Finn

> 
> Justin P. Mattock
> 

WARNING: multiple messages have this Message-ID (diff)
From: Finn Thain <fthain@telegraphics.com.au>
To: "Justin P. Mattock" <justinmattock@gmail.com>
Cc: Joe Perches <joe@perches.com>,
	"John W. Linville" <linville@tuxdriver.com>,
	trivial@kernel.org, linux-kernel@vger.kernel.org,
	linux-wireless@vger.kernel.org, linux-usb@vger.kernel.org,
	linux-scsi@vger.kernel.org, linux-fbdev@vger.kernel.org,
	alsa-devel@alsa-project.org, dri-devel@lists.freedesktop.org,
	linux-ide@vger.kernel.org,
	"Maciej W. Rozycki" <macro@linux-mips.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Randy Dunlap <rdunlap@xenotime.net>,
	Matt Turner <mattst88@gmail.com>,
	Dimitry Torokhov <dmitry.torokhov@gmail.com>,
	Mike Frysinger <vapier.adi@gmail.com>
Subject: Re: [RFC v4]update broken web addresses in the kernel.
Date: Tue, 28 Sep 2010 01:37:57 +0000	[thread overview]
Message-ID: <alpine.OSX.2.00.1009281119570.276@localhost> (raw)
In-Reply-To: <4CA0CB0F.3060303@gmail.com>


On Mon, 27 Sep 2010, Justin P. Mattock wrote:

> On 09/27/2010 09:03 AM, Joe Perches wrote:
> > On Mon, 2010-09-27 at 11:10 -0400, John W. Linville wrote:
> > > On Sun, Sep 26, 2010 at 11:31:15AM -0700, Justin P. Mattock wrote:
> > > > Below is an updated patch from the original fixing broken web 
> > > > addresses in the kernel. Thanks for all the help and info on this 
> > > > to everybody.. Hopefully I didnt miss any of them(if so let me 
> > > > know, and I'll resend).
> > > Changing a URL for a relocated page is one thing, but removing links 
> > > isn't necessarily a great idea.  Even if the site is technically 
> > > gone, it may be possible to find information e.g through the 
> > > Internet Archive Wayback Machine.
> > 
> > Perhaps it'd be better to scrape the contents of the various web 
> > pages, collect them somewhere like wiki.kernel.org and encourage 
> > others to put new contributions in that site.

The copyright problem aside, this might be a good idea for material not 
already archived but I don't think it makes sense to start a new 
archive when archive.org (or other) has the information.

And which version(s) do you scrape? I discussed some problems with 
changing URLs in another thread: http://lkml.org/lkml/2010/9/22/22

Anyway, without knowing what future archive(s) would be available or 
relevant to any given URL in the future, I think the best we might do is a 
"Retrieved on YYYY-MM-DD" qualification for new URLs.

> 
> 
> yeah I think somebody was saying something about having a separate file, 
> with all the web addresses in them or something...In any case, up to you 
> guys..

I don't see how moving the addresses would help.
And would it not make the information harder to find?

Finn

> 
> Justin P. Mattock
> 

  reply	other threads:[~2010-09-28  1:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-26 18:31 [RFC v4]update broken web addresses in the kernel Justin P. Mattock
2010-09-27 15:10 ` John W. Linville
2010-09-27 15:10   ` John W. Linville
     [not found]   ` <20100927151005.GC11086-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
2010-09-27 16:03     ` Joe Perches
2010-09-27 16:03       ` Joe Perches
2010-09-27 16:03       ` Joe Perches
2010-09-27 16:49       ` Justin P. Mattock
2010-09-27 16:49         ` Justin P. Mattock
2010-09-28  1:37         ` Finn Thain [this message]
2010-09-28  1:37           ` Finn Thain
2010-09-28  2:07           ` Justin P. Mattock
2010-09-28  2:07             ` Justin P. Mattock
2010-09-28  2:07             ` Justin P. Mattock
2010-09-27 16:39   ` Justin P. Mattock
2010-09-27 16:39     ` Justin P. Mattock
2010-09-28  2:59 ` Finn Thain
2010-09-28  2:59   ` Finn Thain
2010-09-28  3:23   ` Justin P. Mattock
2010-09-28  3:23     ` Justin P. Mattock
2010-09-28  4:15     ` Finn Thain
2010-09-28  4:15       ` Finn Thain
2010-09-28  4:21       ` Justin P. Mattock
2010-09-28  4:21         ` Justin P. Mattock

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.OSX.2.00.1009281119570.276@localhost \
    --to=fthain@telegraphics.com.au \
    --cc=alsa-devel@alsa-project.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=geert@linux-m68k.org \
    --cc=joe@perches.com \
    --cc=justinmattock@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=macro@linux-mips.org \
    --cc=mattst88@gmail.com \
    --cc=rdunlap@xenotime.net \
    --cc=trivial@kernel.org \
    --cc=vapier.adi@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.