>From what I understand, the larger portion of the patch problems come from
the question of "How much of patch X does Linus need to look at before
appling it?". In the community spirit and using the "many eyes" concepts
we're so familiar with, why is the public not the patch penguin?
Would there be any interest in a web site which hosts copies of all
current patches, while providing a way to rate the patches and leave
comments (a simplified freshmeat.net with only kernel patches).
This would help facilitate the network of trust/cooperation Linus and others
have suggested. Aside from the 10-20 people Linus works directly with, he
and other maintainers could work with the site as the site will be a
decent filter between Linus and the public. If 95% of users have a certain
patch working without trouble against a particular tree, then the question
first raised in this email becomes "very little".
(Note: many times I type "Linus" when I truely mean "tree maintainer", ie:
Alan, Dave, etc).
--Drew Vogel
On Wed, Jan 30, 2002 at 12:56:21PM -0500, Drew P. Vogel wrote:
> Would there be any interest in a web site which hosts copies of all
> current patches, while providing a way to rate the patches and leave
> comments (a simplified freshmeat.net with only kernel patches).
It's been done before with various levels of success. Some would
like it, others (myself included) would likely not use it.
I've said it before, and I'll say it again. Any tool which requires
me to start up a web browser to do something productive is a major
nuisance.
> This would help facilitate the network of trust/cooperation Linus and others
> have suggested. Aside from the 10-20 people Linus works directly with, he
> and other maintainers could work with the site as the site will be a
> decent filter between Linus and the public. If 95% of users have a certain
> patch working without trouble against a particular tree, then the question
> first raised in this email becomes "very little".
I like the sounds of some of it. Take for example Andrew Mortons recent
ide-cd DMA patch. I was curious about how that worked out for people,
so I kept the whole thread. If at some point it's a candidate for
inclusion in my tree, I can open mutt, look in the January l-k folder,
and see the whole thread with success/failure stories, and see how it
worked out..
A correctly indexed patch repository could also duplicate this, but
not replace it. I do a lot of patch-hoovering scooping up mislaid
dropped patches from l-k archives when I'm on the road with no
network connection, or sitting around in hotel rooms watching bad
german television. For this reason, the www is a non-starter for me
unless I have some means of mirroring the whole repository and comments.
(which isn't too practical).
--
| Dave Jones. http://www.codemonkey.org.uk
| SuSE Labs
> It's been done before with various levels of success. Some would
> like it, others (myself included) would likely not use it.
> I've said it before, and I'll say it again. Any tool which requires
> me to start up a web browser to do something productive is a major
> nuisance.
Honestly I feel the same. Unfortunately installing new tools to do this is
also a larger task than should be required. Personally, I would like a
public ftp archive for patches to reside. I don't have a
machine/connection I can open up ftp though.
--Drew Vogel
On January 31, 2002 02:48 am, Drew P. Vogel wrote:
> > It's been done before with various levels of success. Some would
> > like it, others (myself included) would likely not use it.
> > I've said it before, and I'll say it again. Any tool which requires
> > me to start up a web browser to do something productive is a major
> > nuisance.
Hi Dave,
> Honestly I feel the same. Unfortunately installing new tools to do this is
> also a larger task than should be required. Personally, I would like a
> public ftp archive for patches to reside. I don't have a
> machine/connection I can open up ftp though.
Agreed. Please have a look at what we're doing here:
http://killeri.net/cgi-bin/alias/ezmlm-cgi
It's too early to try the code, currently at version 0.0 (thanks to Rasmus
Andersen for that, Kalle Kivimaa for the mail list). The guilding design
rule is to do everything with MTAs that submitters and maintainers _are
already using_, and to do it _just as they do it now_, using a normal mail
archive as the data base. The only thing that changes is: you mail the
patchbot instead of the maintainer.
Submitters will need to put some minimal number of additional lines in the
body of the email, and it's possible we'll get the 'minimal number' down to
zero for common cases (one line description comes from subject, long
description comes from mail, purpose is implied by [BUGFIX] in subject line,
etc).
Do you see anything to object to so far?
--
Daniel
>Agreed. Please have a look at what we're doing here:
>
> http://killeri.net/cgi-bin/alias/ezmlm-cgi
>
>It's too early to try the code, currently at version 0.0 (thanks to Rasmus
>Andersen for that, Kalle Kivimaa for the mail list). The guilding design
>rule is to do everything with MTAs that submitters and maintainers _are
>already using_, and to do it _just as they do it now_, using a normal mail
>archive as the data base. The only thing that changes is: you mail the
>patchbot instead of the maintainer.
>
>Submitters will need to put some minimal number of additional lines in the
>body of the email, and it's possible we'll get the 'minimal number' down to
>zero for common cases (one line description comes from subject, long
>description comes from mail, purpose is implied by [BUGFIX] in subject line,
>etc).
>
>Do you see anything to object to so far?
Well, I don't have any objections, per se. What I did notice immediately
though is that the web browser is still involved. My *ideal*
implementation would be very similar. The only significant difference
would be that the patches would be sorted into directories, in a public
ftp archive. The special comments would be display while changing
directories in the archive. This way I can at least just type 'lynx
ftp://kernel.patches.archive/patch_name/' and the first entry is the most
current patch, and the special comments from the author would be displayed
at the top.
--Drew Vogel
On January 31, 2002 05:09 pm, Drew P. Vogel wrote:
> >Agreed. Please have a look at what we're doing here:
> >
> > http://killeri.net/cgi-bin/alias/ezmlm-cgi
> >
> >It's too early to try the code, currently at version 0.0 (thanks to Rasmus
> >Andersen for that, Kalle Kivimaa for the mail list). The guilding design
> >rule is to do everything with MTAs that submitters and maintainers _are
> >already using_, and to do it _just as they do it now_, using a normal mail
> >archive as the data base. The only thing that changes is: you mail the
> >patchbot instead of the maintainer.
> >
> >Submitters will need to put some minimal number of additional lines in the
> >body of the email, and it's possible we'll get the 'minimal number' down to
> >zero for common cases (one line description comes from subject, long
> >description comes from mail, purpose is implied by [BUGFIX] in subject line,
> >etc).
> >
> >Do you see anything to object to so far?
>
> Well, I don't have any objections, per se. What I did notice immediately
> though is that the web browser is still involved.
Nope, no web browser. What made you imagine that?
We would likely provide a web browser view of the patch database at some point,
but this is 'future work', it's not part of the fundamental operation of the
thing, which is all by mail.
> My *ideal*
> implementation would be very similar. The only significant difference
> would be that the patches would be sorted into directories, in a public
> ftp archive.
We haven't defined the database format yet. The first purpose is to establish
the flow of patches from submitter to maintainer, with confirmation, rejection,
etc, flowing back in the other direction. Then we move on to maintaining
state for each patch, and archiving the patches (kernel.org itself doesn't
archive, so we'll have to do that ourselves, not such a bad thing).
> The special comments would be display while changing
> directories in the archive. This way I can at least just type 'lynx
> ftp://kernel.patches.archive/patch_name/' and the first entry is the most
> current patch, and the special comments from the author would be displayed
> at the top.
OK, interesting, maybe that is the way to go. This needs to be kicked around
a little.
--
Daniel