Messages in this thread | | | From | teamwork@freemail ... | Subject | Re: Automating 2.3 patches | Date | Fri, 16 Oct 1998 08:33:19 GMT |
| |
The proposed Central Linux Patch Clearinghouse [CLPC] website's has two main functions:
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/
| |