lkml.org 
[lkml]   [1998]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Automating 2.3 patches

Hi gang,

I don't know how old this thread on linux-kernel is, but I'm working on
such a patch archive since over a week now. I think that what I'm writeing
is a nice solution. Let me explain what I wrote allready and why I wrote
it this way by repleing to Rik van Riel's mail:

On Thu, 15 Oct 1998, Rik van Riel wrote:

> > 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).

Having dedicated sites for each subsystem is one way. Having a central
patch archive is another one. I think that there should be both. If
someone is looking for documentation, mailing list archives and so on,
he should have a look at the site of the subsystem. But if someone is
just looking for a list of pathes out there, the patch archive is the
right place.

> > 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...

My patch archive works like that. But it's more tricky:

A patch maintainer has to write a description file. This file contains all
standard information (like author, kernel version it is for, name of the
patch ...) in header fields and a detailed description of the patch in the
body. The header has fields for a Homepage-URL and a Documentation-URL
too. One can use this (e.g.) to link the entry in the patch archive with
the subsytem site.

After the maintainer has written the description file he has to put in on
the net (together with his patch) and send the URL of the description file
to the patch archive administrator. The administrator has a look at the
description file and adds the URL to the according cathegories of the
archive. From now the archive monitors the description file on the
maintainers site and updates changes in the description file in the
archive automatically. At the moment the archive system can do http and
anonymous ftp queries to keep it's local copy of the description file
up-to-date.

So the patch archive can be administrated by one or more persons and stays
clean becouse the admins have a look at every new patch and see if they
are really in the right cathegory and so on.

And it's easier for the patch maintainers to keep their entries in the
archive up-to-date becouse all they need to do is to edit an ascii file
on their site (which is much faster that any web-interface).

> 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...

My patch archive system is human-managed. But this human gets a lot of
help by the system. Otherwise the archive would become dirty within
a short time ...

> > 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/

The advantade of a central patch archive in this case is, that the user
would know it allready and would find the needed patch pretty soon. If
he than would like to have some additional information on a patch, all
he need to do is clicking the "Homepage" or "Documentation" link of the
patch (if the patch has one).

> > 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.

I absolute agree with you. It should be up to the patch maintainer
to tell how stable the patch is. The description file format of my
archive has a header field called "status". It contains a number
from 0 to 10 where 0 stands for "absolute alpha" and 10 for "nasa
and esa are using my patch".

There should be a more detailed description of the status of the patch
in the body of the description file. But this simple number can give the
user a first idea of the development status of the patch.

> > 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.

This is one of the reasons why I desided to develop the patch archive.
Before reading the linux-kernel list I had no idea of what patches and
drivers are there. From time to time I browse thru menuconfig to see what
I could try out. It would be great to give people the possibility to do
the same with patches ...

> > 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.

Such a website is allready there. It's in beta state and there are only a
few patches in the archive now. But if the patch maintainers support it
by writeing description files to their patches, it could become a
powerfull tool for all linux users.

The URL of it is <http://linux-patches.rock-projects.com/>. Just have a
look at it and tell me what you think. And if you wrote a patch: please
write a description file and send me the URL of it. I don't like to make
a big announcement at the current development state of the archive but it
would be cool to have a bit more patches in it.

- clifford

-- -- -- -- -- -- -- -- -- -- -- -- --
Clifford Wolf (CEO and CTO)
The ROCK Projects Workgoup IRC: IRCnet / clifford
http://www.rock-projects.com/ http://www.clifford.at/
e-mail: c.wolf@rock-projects.com email: god@clifford.at


-
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.068 / U:1.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site