Public patch penguin

Public patch penguin

[Drew P. Vogel]

>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

Re: Public patch penguin

[Dave Jones]

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

Re: Public patch penguin

[Drew P. Vogel]

> 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

Re: Public patch penguin

[Daniel Phillips]

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

Re: Public patch penguin

[Drew P. Vogel]

>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

Re: Public patch penguin

[Daniel Phillips]

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