lkml.org 
[lkml]   [2001]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Alan Cox quote? (was: Re: accounting for threads)
Rob Landley wrote:
>
> On Wednesday 20 June 2001 20:42, D. Stimits wrote:
> > Rob Landley wrote:
> > ...snip...
> >
> > > The patches-linus-actuall-applies mailing list idea is based on how Linus
> > > says he works: he appends patches he likes to a file and then calls patch
> > > -p1 < thatfile after a mail reading session. It wouldn't be too much
> > > work for somebody to write a toy he could use that lets him work about
> > > the same way but forwards the messages to another folder where they can
> > > go out on an otherwise read-only list. (No extra work for Linus. This
> > > is EXTREMELY important, 'cause otherwise he'll never touch it.)
> >
> > What if the file doing patches from is actually visible on a web page?
> > Or better yet, if the patch command itself was modified such that at the
> > same time it applies a patch, the source and the results were added to a
> > MySQL server which in turn shows as a web page?
>
> His patch file already has a bunch of patches glorped together. In theory
> they could be separated again by parsing the mail headers. I suppose that
> would be less work for Linus...
>
> The point is, the difference between the patches WE get and the patches LINUS
> gets is the granularity. He's constantly extorting other people to watch the
> granularity of what they send him (small patches, each doing one thing, with
> good documentation as to what they do and why, in seperate messages), but
> what WE get is a great big diff about once a week.

If patch was itself modified, the one big patch file could easily be
considered in terms of all of its smaller patches in any processing it
does as a publication aid.

>
> So what I'm trying to figure out is if we can impose on Linus to cc: a
> mailing list on the stream of individual patch messages he's applying to his
> tree, so we can follow it better. And he IS willing to do a LITTLE work for
> us. He's issuing changelogs now. This would be significantly less effort
> than that...

The patch command already considers one large file to be a lot of
smaller patches in most cases. Why not, as it does its work, let it
document what it has done?

>
> MySQL is overkill, and since these things started as mail messages why should
> they be converted into a foriegn format? There's threaded archivers for
> mailing lists and newsgroups and stuff already, why reinvent the wheel?

MySQL is just a sample. I mention it because it is quite easy to link a
web server to. Imagine patch running on a large file that is a
conglomeration of 50 small patches; it could easily summarize this, and
storing it through MySQL adds a lot of increased web flexibility (such
as searching and sorting). It is, however, just one example of a way to
make "patch" become autodocumenting.

>
> Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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