lkml.org 
[lkml]   [1998]   [Oct]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Automating 2.3 patches
> Alan, you forgot that Mr. Linus Torvalds will still be the official final
> arbitrator, and _his_ kernel will still be the _official_ kernel, regardless of
> the 15 gazillion different kernel trees that may exist out there.

The problem is the splits in development end up coming all back on top of
Linus. "Can you sync" "scan you get this is for .." "ovber here we have
this" "in this we have this can you.."

AN dit should all come to him first, so it can be merged or at least
reviewed before any otrh major changes occur in the source tree.
Presenting patches from two different kernel version, even if they have
the same base isn't a simple process.

> Alan also said:
> "If patches didnt interact it would be a wonderful idea,
> but they do, frequently in bizarre and horrible ways."
>

What he said.

> I'd also like to add the following suggestions:
>
> 1. Space for short descriptions of the patches
> (much like what's going on in this list)
>

You mean per statement commenting? Or, say, a section at teh top of every
source available for people to add comments to when they patch a source,
or, a single FILE in teh soruce tree that can be patched (too much if you
ask me) when a patch goes through.

> 2. Space for people to post short comments
> (much like /.)

come again?

> 3. Links to places where those patches are available, and
>
> 4. Simple good / bad voting feature for that particular patch.
>

Where do you expect to see all this? I *am* confused.

> In that way, people can read about the good, bad, and the ugliness of any
> particular patch before they actually apply on their own machine, and if they
> want to try the patches, they can use the links provided and start downloading.

http://www.linux.org Yes, 'they' are working on it still (i HOPE).

> It would be nice if the website is structured in such a way that patches for
> memory would be put in the memory section, patches for hardware can be put in
> their respective category (such as hardware/scsi).

Actually, what would be nice if patches we're first selectable via
version, then via sub-system or drivers. Then you could sleect a nage of
patches that affect a given subsystem, or slect the drivers section and
get a list of drivers patches by driver that they patch. Patches that
affect multiple items could just be linked in several places to teh same
file (no problems, wow!)

%---* ely % "Ugh."


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:44    [W:0.044 / U:0.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site