1. To facilitate the rapid evolutions of
Linux patches and drivers, and
2. To offer a central place whereby Linux
users can easily obtain necessary Linux
drivers and/or test out the latest patch.
It is not meant to be a replacement for any of the established Linux sites,
mailing-lists, and newsgroups.
- -----------------------------
I said:
"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."
Rik replied:
"This is a nice thing to do for 'homeless'
patch writers."
"The MM patches can be accessed through the
Linux-MM homepage though (not sure if I
linked Andrea's patch repository, I'll
check that when my exam is over)..."
- -----------------------------
And this is exactly why a Central Linux Patch Clearinghouse [CLPC] website might
help.
There are plenty of people who write patches, and with so many new talents keep
popping up, nobody can honestly say they can keep a close track with the
increasing number of patch authors, their url links, and the exponential volume
of what they have produced.
The Central Linux Patch Clearinghouse [CLPC] website which is open to all means
patch authors have the option to advertise their patches by put up the links
themselves. They keep their own updates available for all because they are the
ones who know which version of their updates is the latest, or the best.
Under the current procedure, for a patch author to get his patch to the public,
the patch author has to do all these:
o Patch author finished writing a patch,
o Patch author needs to RTFM, or use
search engines, to search for relevant
places to submit his patch,
o Patch author then writes emails to all
the webmasters of the specific Linux sites
[if he can find the email addresses, that is],
o Then the patch author has to hope that the
unsolicited emails he sent to the webmasters
are being read, and not treated as junk email
[and sent to dev/null]
o Even the emails he sent to the webmasters
are not being flushed out by the webmasters'
email reader proggies, his emails waited in the
mail-queue for hours [or days, or even weeks!]
before the webmaster of the specific sites can
find times to read them
o Webmasters may have tons of email already
accumulated in his inbox, and it may be very late
at night, or that the webmasters are tired.
The patch author's email may have being skipped
and/or erroneously deleted, or misfiled
o Even if his email survives and the webmasters
think that his patch is a Good Thing (TM),
some more time will still be wasted because
the webmasters have to find more free time to
update their websites
o Patch author may also needs to bombard the
many Linux related usenet newsgroups and/or
mailing-lists to announce his patch,
making him an instant flaming target
o Finally, after all the ordeals, the patch meets
the public.
Compare this to the following.
With the availability of a Central Linux Patch Clearinghouse [CLPC] website, a
patch author has to go through the following to get his patch to the world:
o Patch author finished writing a patch,
o Patch author point his browser to the
Linux Patch Clearinghouse website,
o Go to appropriate directory
(such as hardware/SCSI,)
o Write simple descriptor for his patch,
o Put down the url where his patch is available,
o The patch meets the public the instance its
author hits the "submit" button.
* Please allow me to sum up the advantages:
1. No wasted time,
2. No wait,
3. No delay,
4. No hassle, and
5. No flame.
Now, would you tell me which way is better?
- -----------------------------
Rik also said:
"Having dedicated sites for each subsystem
would, IMHO, be better than a central site,
since specialised sites can go much more
in-depth and provide other stuff as well
(documentation, mailing list archives,
TODO lists and technical musings)."
- -----------------------------
The Central Linux Patch Clearinghouse [CLPC] website is not intended to replace
the various sites dedicated for specific Linux segments, in many ways, it may
actually complements them.
The advantage to the webmasters of those sites (for example, the Linux-MM site)
is that you do not have to review so many patches anymore. All you need to do is
to go to the Central Linux Patch Clearinghouse [CLPC] website from time to time
and pick those patches that you like, and put them in your sites.
The Central Linux Patch Clearinghouse [CLPC] website will not carry any
particular patch forever.
o If the url to the patch is obsolete,
the patch is dropped.
o If the patch is for kernel version 2.0.8,
while the current [stable] kernel version
is 4.2.6, the patch is too old for
most people, and it is dropped.
o If the patch is proven to be buggy like hell,
and better patches are available, it is dropped.
o If the patch has been updated and tremendously
improved upon, it is dropped.
The other sites which are dedicated to a specific Linux segment, such as the
Linux-MM site, on the other hand, can act as the depositories for _ALL_ versions
of good patches. Let's say an old patch for kernel version 2.0.8 may not be
needed by _many_ people, but if it is still needed by the Linux-MM community, it
will do a lot of good for the Linux-MM site to retain that patch on its site.
There should be no conflict what-so-ever between the Central Linux Patch
Clearinghouse [CLPC] website and other specific Linux sites. They all play their
respective roles to aid the Linux communities.
The Central Linux Patch Clearinghouse [CLPC] website should have a url that
points to the Linux-MM site on its dev/mm directory, and if the Linux-MM site
also has a url points to the Central Linux Patch Clearinghouse [CLPC] website,
both sites working with each others complementary will boost each others'
effectiveness in serving the Linux users of the world.
- -----------------------------
I said:
" * 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."
Rik replied:
"True, but a 'central' site will probably make for a
less attached SCSI community as well. Maybe we'll want
a central site, but with the possibility of each subsystem
maintaining it's own site instead..."
- -----------------------------
I don't think the existence of a Central Linux Patch Clearinghouse [CLPC]
website will split any specific community - such as th SCSI - because
essentially the SCSI people (bof) will gather on the Central Linux Patch
Clearinghouse website for patch submission, and for more detail discussions of
how to write a driver for a particular SCSI device, SCSI people will be
encouraged to use the Linux-SCSI mailing-list, and persue the Linux-SCSI website
for a more detail description on SCSI specifications.
All subsystem sites are encouraged to continue their operations, and by a mutual
linkage, both the subsystem sites and the CLPC will benefit novice Linux users,
as well as the most experienced Linux gurus by providing a more organized
structure to bring them together.
- -----------------------------
I said:
"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."
Rik replied:
"This could be a bad idea. Version 2 of a patch might
be very very different from version 1, but it could
still have the bad name."
- -----------------------------
Point taken.
The ideas I am throwing out are not meant to be rigid. Everything that I have
said are mere suggestions, and I welcome anyone who is willing to offer
constructive criticisms and like my "vote" idea above, I can see that it could
potentially be a Very Bad Thing [TM]. If it is bad, then we do away with it, but
if any of you think it could be changed a bit [like from a simple "Good/Bad"
vote to a "1-to-10" scale] to eliminate its potentially destructive nature, I'm
happy to hear you out.
- -----------------------------
Rik also said:
"I don't want folks like that to vote over my
patches. Often the kernel works very counterintuitive,
so casual surfers really can't make judgements about
patches."
- -----------------------------
Understood.
But do you think that offering an optional numerical scale [1 to 10, for
example] for people to cast their opinion on is workable?
What I am trying to achieve is to have a simple and time saving method to help
the maintainers and folks like Linus Torvalds and Alan Cox in determining which
patch makes sense, which doesn't, without having to study the code of all of
them.
I understand that even a numerical scale is flawed, but if anyone have better
ideas, I am always open for suggestions.
- -----------------------------
I said:
"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."
Rik replied:
" Maintainers should (and probably will) base their
decisions on the quality of the code, and not because
of democratic stuff going on. Linux is not a democracy,
it is a meritocracy with a benevolent dictator taking
the final decisions."
- -----------------------------
Correct.
Ultimately, Quality Counts [TM] !
If Linus finds a patch that has potential, but its code needs polishing, Linus
should tell the author what he [Linus] wants, and perhaps offering a pointer or
two to the author so that the patch is properly coded and when that is achived,
the patch will be included in the kernel release.
CLPC, if properly set-up, may become an excellent vehicle for Linus (and others)
to get in touch with various patch authors - without having tons of unwanted
emails or messages to wade through, like this L-K mailing list.
- -----------------------------
I said:
"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."
Rik replied:
"This will be another advantage. Making it easy for people
to test patches, will most likely increase development
speed, thereby making the whole process more rewarding
for the programmers."
- -----------------------------
_EXACTLY_ !!
And with programmers feeling better, they will be more willing to help out. With
this increasing productivity, Linux may become much better than it is today.
This is a case for an all around WIN-WIN-WIN situation for Linux, the
programmers and the users.
- -----------------------------
I said:
"and when they [Linus and Alan] need to find things that are
reliable, they can base their choice on the "recommendations"
from the people who actually _used_ the patches."
Rik replied:
"Having all the reactions to one patch in the same place
is a large advantage indeed. This point could make the
job of Linus and Alan a little easier -- if they want it
this way..."
- -----------------------------
Indeed, quality of code is _the_ thing for Linux. But before a patch can achieve
that, it has to be tested, and re-tested, and it has to evolve. With all the
reactions comes in one place, instead of thinly spread throughout the entire
internet, both the programmers and the users of the programs can put their heads
together and find optimal solutions for a given problem.
- -----------------------------
I said:
"I hope an 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."
Rik replied:
"So do I. Most Linux subsystems still lack all clarity
and there's no way for someone with little time to
figure out what's going on inside the devel group."
- -----------------------------
Thank you for echoing my enthusiasm, Rik. :)
Let's hope someone set up such the CLPC website, and let us also hope that Linus
will give his blessings and cooperations and we will all see a much better Linux
in the future.
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/