lkml.org 
[lkml]   [1998]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

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