Messages in this thread | | | Date | Thu, 15 Oct 1998 18:33:13 +0000 (/etc/localtime) | From | Rik van Riel <> | Subject | Re: Automating 2.3 patches |
| |
On Thu, 15 Oct 1998 teamwork@freemail.c3.hu wrote:
> 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.
This was not such a great example, for the following reasons: - my patch includes the OOM protection in the kernel too (well, that doesn't change the example, but I'll mention it) - Andrea's patch and my patch are good complements to eachother, there's no reason to throw away any of our efforts
The last reason is also the reason why Andrea and I keep 'communicating' the way we are. If it wasn't the case, we'd probably both go for a cool-down-a-moment period :)
> 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.
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)...
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).
> 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.)
It's still a nice idea, though. Maybe we should do something like this...
> * How such website benefits the ordinary Linux users: > > Let's assume there is a Linux user Joe Blow, who > doesn't know how to write a SCSI driver.
Yeah, that sucks {;-)
[SNIP driver available, but not locatable]
> 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?
OK, you convinced us that a more-or-less central site for patches is needed.
I still think that a human-managed site for each individual subsystem is better, but that's probably just a matter of opinion...
On a side note, if anybody knows of a subsystem site that's not already listed on the "kernel links" section of my Linux-MM site, please let me know. I will add the links immediately.
It will also be a good idea to report yourself for http://webwatcher.org/, since that site currenly only lists _one_ Linux kernel subsystem site (Linux-MM).
> 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.
s/SCSI directory/SCSI subsystem site/ s/driver/driver, documentation and generally patronizing warnings/
> * 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.
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...
> Hence the possibility of someone code up a working XYZ > SCSI driver is very great.
Yup, we really should do something like this.
> * How such website benefits mailing-lists like L-K: > * How such website benefits maintainers:
Anybody? What we need now are volunteers...
> 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.
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.
It would be best if the programmer of the patch gets all the bug-reports in his/her mailbox and puts up a little message to the community if he/she feels like it.
Just having anybody vote on a patch will result in a fast and brutal dismissal of ideas that don't look so great at first sight. I can remember that the OOM killer provoked a large flamefest ("What, I don't want the kernel killing my processes") when first proposed.
A second - very sneaky - proposal led to a better acceptance ("I don't want X to die unexpectedly" "Well, maybe we should put some code in the kernel to not kill random processes"), but still there are people who just glance over the messages and then come out with a strong (unfounded) opinion...
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.
> 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.
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.
> 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.
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.
> 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.
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...
> 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.
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.
Rik. +-------------------------------------------------------------------+ | Linux memory management tour guide. H.H.vanRiel@phys.uu.nl | | Scouting Vries cubscout leader. http://www.phys.uu.nl/~riel/ | +-------------------------------------------------------------------+
- 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/
| |