Alan replied:
"Then instead of 2 or 3 kernel trees with get N!
limited by the number of Linux users."
"Not good."
Me to Alan:
"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."
Ely to me:
"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."
I apologize if what I said to Alan has mislead you.
What I was trying to say to Alan is that a website like that can be used not
only by Linus, but also by maintainers for all sort of categories, people
submitting patches, people looking for patches who for one reason or another
can't or don't know how to use CVS.
In other words, the website can be used as a central clearinghouse for all Linux
users.
Please allow me to take the OOM as an example to show the benefit of such a
central clearinghouse concept:
Andreas and Rik are both involved in ways to curb the OOM problem for Linux.
Andreas' way is to have the OOM protection be included in the kernel, but Rik's
approach is to get the OOM protection as a standalone daemon. Right now, Linus
has yet to include either Rik's or Andreas' OOM protection approach in his
official tree.
* How such website benefits patch submitters (like Rik and Andreas):
Both Rik and Andreas can go to the site and
"submit" their respective approach to the OOM
protection, write a brief description of their
respective patches, and offer a web (or ftp)
link so Linux users can obtain the patches.
Patch submitters no longer have to wait for Linus
to approve of their approach, and they no longer
have to go to 20 different places to submit their
patches.
All they have to do is to write up a brief
description of their patch, submit it to the website
(in appropriate category, of course.) If they want
to, they can also post messages on the L-K (and on
other related) mailing-list(s) to announce the
availability of their patches.
* How such website benefits the ordinary Linux users:
Not all Linux users subscribe to the L-K mailing
list. In fact, there are many Linux users who do
not have the time to subscribe and read through
the many messages on the Linux related mailing-lists.
Let's assume there is a Linux user Joe Blow, who
doesn't know how to write a SCSI driver.
When Joe Blow bought a brand new XYZ brand SCSI
drive, and found that his present Linux set-up
doesn't contain the required driver, Joe Blow may
post an enquiry on one of the many Linux mailing-lists
(or newsgroups) asking if anyone know about the XYZ
brand of SCSI drive.
Let's supposed another Linux user Jane Doe replies
to Joe Blow that she heard of the XYZ SCSI drive a
couple of weeks ago, and she thinks there may be a
driver available, but she doesn't know where it is.
Now what does Joe Blow do?
Does user Joe Blow have to search the entire Net
for such a driver?
Or does he make multiple annoying requests on as many
mailing-lists (and/or newsgroups) he can find, making
him an instant flaming target?
If a central Linux patch clearinghouse website is
available, Joe Blow could have point his browser to it,
and go down to the SCSI directory and search for the
required driver.
If there is not yet a driver for brand XYZ SCSI drive,
user Joe Blow can post a request on the SCSI section of
the Linux Patch Clearinghouse website, politely asking
someone to help write a driver.
* How such website brings together Linux hackers and users:
And because the website is the central clearinghouse
for all Linux patches, most Linux users with with SCSI
expertise will visit the SCSI section of the website.
Hence the possibility of someone code up a working XYZ
SCSI driver is very great.
Bear in mind that user Joe Blow may not know where to
find the Linux-scsi mailing list --- not everyone RTFM
you know? --- and if such website exists, ordinary
Joe Blow users can get in touch with someone familiar
with SCSI drivers and maybe both can cooperate and hack
up a working driver for brand XYZ drive.
* How such website benefits mailing-lists like L-K:
The Linux-Kernel mailing list is for the developers of
the Linux kernel, but we have seen many non-kernel
development related messages (such as this one, sorry)
on the mailing list. If a central Linux patches
clearinghouse website exists, (in Joe Blow's case)
people don't have to post SCSI related messages here,
while they can get in touch with SCSI driver experts there.
Ditto for other peripheral-related matters.
* How such website benefits maintainers:
Linux maintainers of all types, from documentation to
platform to specific peripheral, right now relies on the
many diversed mailing lists and newsgroups to find and
update new patches. It is a tedious and thankless job.
If a central clearinghouse Linux patches website is
available, patch authors can submit their patch onto the
appropriate section, and maintainer for SCSI, for example,
only need to go to the SCSI section to find new patches
for SCSI drives to include in their collection(s).
And I did propose a "Good/Bad" type of voting feature for
the website. Good patches will get mostly "Good" votes,
while broken patches will get mostly "Bad" votes.
Coupled with the availability of simple description
spaces for the voters to voice their opinions,
maintainers for specific peripheral (platform) can base
their decision on which one to include, which one to
reject on the comments (and the vote-counts) of the
various patches.
If a patch/driver is broken, but it has a potential,
then people may say so in the brief description space
(a little like what's available on slashdot.org), and
the maintainer can base on the description to decide
if he wants to get in touch with the original patch
writer, or to insert updates/corrections into the
original patch/driver, and offer it for others to test
it out.
Furthermore, the SCSI patch maintainer may advertise the
availability of the Linux-SCSI mailing list in the website,
inviting people to hold more SCSI specific talk in the
mailing list, thus bringing in possible new SCSI driver
coders to the community.
In this situation, the website functions much like the
famous "Bazaar" model Eric Raymond has written about --
o People are free to choose whatever that's
available,
o People get to vote good or bad for a specific
patch,
o People get to leave brief description of their
experience with the patch,
o Maintainers base their choice on whether to
include or reject a specific patch on the
"recommendations" by the people, a
"peer-review" process,
o A "secondary peer-review" process may be
carried out in specific targetted mailing-lists
(and/or newsgroups) to hash out more of the
detail of pros and cons,
o Since the patches that are submitted to the
website is available to the public almost
instantly (as long as the URL links is valid),
the "factory-to-market" bottleneck for Linux
patches is removed, and with the patches
reaching targetted users in record time, patches
can be tried out more often, by more people,
and better patches emerge with more rapid
succession. This improvement can only accelerate
the progress of Linux's evolution.
With this website, the existing maintainers will keep their source tree, but
they get to have much more participatory peer-reviews on the patches they put on
their trees.
The problem you said above --- the sync problem, the splitted trees --- will not
occur because the website isn't replacing the functions of the source tree
maintainers, on the contrary, it complements the work of the maintainers, making
their job easier (don't have to search all over the place for patches, for
example), and since the website also function as the unofficial gathering places
for "bof" of various interests, maintainers can enlists the help of those people
to help him/her write/review/patch whatever problems that cropped up on his
tree.
It'll help people like Linus Torvalds and Alan Cox too. They no longer have to
rely solely on L-K mailing list (not having to read _ALL_ messages on L-K means
a savings of hours everyday!) and when they need to find things that are
reliable, they can base their choice on the "recommendations" from the people
who actually _used_ the patches.
Of course, Linus being the final arbitrator, reserves his right for the final
words. To include or not to include any specific patch, or to alter the codes on
any patch, still lies within the "God-like" domain of Linus Torvalds.
Me to Alan again:
"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)"
Ely to me:
"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.
It's not per statement, nor single file for source tree. The brief description
is for the patch writer to advertise the availability of his patch. Something
like
"This is a patch to enable Linux to run brand XYZ SCSI drive
model ABC1234, tested with Linux version 2.125, and available
on ftp://ftp.whatever.com/~borg/Linux/patch/SCSI/xyz/"
is sufficient.
And of course patches evolve. The evolution of patches can takes place on the
website too. Let's take Joe Blow's example.
When you go to the SCSI section of the website, you find that XYZ SCSI drive is
not yet supported. So you write a simple (and preferably polite) request for
someone to write a driver for brand XYZ drive on the "Request" area of the SCSI
section.
Someone read your message, write the patch, put it on his own website, and come
to the Linux Patch website and replied to your request with a short description
for his patch, along with the URL where his patch is available.
And while the patch author is on the website, he has the option to submit his
patch to the "Patch Available" area on the SCSI section as well. It is up to the
author if he wants to do that.
If the patch is preliminary, he may want Joe Blow to try out the preliminary
patch and later gets back to him for feedbacks so the author can offer
additional updates.
If the patch is consider "stable", the author of the patch may want to write up
another short message describing his patch - with the URL linking to his patch -
on the "Patches Available" area of the SCSI section.
People will download his patch and try out, some may make improvement (and/or
correction) on his patch and submit to the website as the "Update" to the patch.
And if there are more than one kind of "updates" available for a specific patch,
people will make their own decision on which one to use. They can try out all
the "updates" and they can come back to the website and offer their
"recommendations" by voting "Good" or "Bad" on the updates, and there are brief
feedback areas for them to comment what "Good" or "Bad" experience they have
with the various updates.
For a given XYZ SCSI drive, the evolution of the driver won't go forever. There
are only so much "improvements" you can make to a SCSI patch, and when the dust
settles, one (and the most two) "update" will stands out from the rest, and the
maintainer of the the various Linux trees can then include the patch into their
own trees, and they can submit the patch to Linus as well, if they think the
patch needs to be included in the main Linux kernel.
Even if Linus rejects the inclusion of the patch in the main kernel, people
still can find and use the patch on the website when they need to.
Me to Alan:
"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.)
Ely to me:
"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!)
Or both.
On the mainpage of the website, people gets to choose between whether they want
to go the version route, just like what you've outlined above, or they can go to
hardware/SCSI and once they go there, they choose machine platform (Alpha, X86,
Sparc, Mips, PPC, or whatever else), then they choose which SCSI peripheral
(drive, cards, others) they want the patch on, then they choose the brand
(Adaptec, Buslogic, others) for the cards, or (Seagate, Quantum, others) for
SCSI drives, then they choose version number (if it is necessary).
Since Linux evolves all the time, and people update their Linux machine all the
time. If the website is to be useful for the Linux community, it must offer a
flexible interface and not force people to go through its own ideosyncracy.
Offering a "By Version Number" and a "By Hardware Specification" route on the
mainpage maybe a better way to go.
And one more thing: A website can be accessed by anyone with web browsers. Not
everyone is able to use CVS.
Below please find several of my additional proposals for the Linux Patch
Clearinghouse Website:
It should not be the job of the Linux Patches
Website to retain ancient patch-links. All
obsolete patch-links will be deleted (such as
if people tried the links and it isn't there
anymore), and most preliminary patch-link will
be deleted once a "stable" patch is available.
To save webspace, the website may only carries
very short patches. For patches that are massive,
the patch authors must provide a url so other
people can fetch the patches.
All "descriptions" are intended for describing
the patch.
All "comments" brief messages intended for
describing the pros and cons of the patches.
The "votes" are to aid the "tallying" of the
usefulness for a given patch.
All flames and other unrelated "comments"
should be deleted to cut down on the noise.
The website is to facilitate the growth of
Linux by easing the flow of patches from the
patch-authors to the patch-users.
I hope a enterprising Linux user may start such a website soon. The current
patch submission process is too cumbersome, and the gap between the patch
authors and patch users are too wide for the average Linux users.
With the blessing of Linus, Alan and others, and the cooperation of the Linux
community, my humble opinion is that a website that acts as a clearinghouse for
all Linux patches may helps ease many of the current Linux bottlenecks.
I reckoned that the proposed website does duplicate many of the Jittlebug
features, but since the close down of Jittlebug, problems have arisen, and
unless the Jittlebug is resumed, a website such as the one I propose is needed.
Lastly, I do understand that this is an Off-Topic message to the Linux-Kernel
Mailing List, so my apology to all for this intrusion.
Respectfully,
Pete
teamwork@freemail.c3.hu
-
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/