lkml.org 
[lkml]   [1998]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: jitterbug
Date
Stephen wrote:
> I think it's already been established that just about anything
> we do here needs to take some of the load OFF of Linus, yes JitterBug is
> nice, but it needs to take some of the load off of Linus, or at least
> not add to it.
> The question is, how to do both? Is there a simple way to have
> JitterBug look for something like 'STATUS: Pending' at the beginning of
> one of these email's from Linus? That takes away all of the 'mousing
> around' for status updates at least.

I'd be happy to implement that if Linus wants it, but I'm not sure
that he does. It just replaces mousing around with keyboard work.

> Also, could JitterBug auto-magically incorporate patches that
> come in as 'approved' from Linus? Then have say nightly patches created
> from the tree that resides w/ JitterBug? This would permit snap-shots
> more or less of the 'official' tree (Or at least pretty close to
> it).

From the discussions we had when setting it up I don't think Linus
wants the linux-patches system to be involved in actually generating
releases. I think he is happy with the current method he uses to
distribute kernels.

> JitterBug could also test new patches in some way or another
> (at the least it could see if with the new patch the kernel would
> compile), and then send a reply to the submitter if it fails with an
> explanation as to why. Admittedly this will cause the machine hosting
> this to be rather busy if alot of patches come in, but it would be a
> usefull test..

In response to a complaint from Linus about getting out-of-date and
broken patches I added a feature to JitterBug called
"auto-patch". People who have passworded access to the system see a
slightly different layout and have the option of selecting a kernel
source tree and testing the current patch against that tree. When you
press "auto-patch" it checks out a clean copy of the latest release
(using rsync so it takes only a couple of seconds) then it applies the
patch and generates 4 scrollable text areas in a web page:

1) the patch itself (with auto-extraction of uuencode, mime, gzip etc)
2) diffstat output so he knows what it affects
3) diff output (error reports etc)
4) the contents of any resulting .rej files

I could extend this system to actually compile the kernel but I don't
think it will be very useful. For a start it would take too long and
then there is the problem of which options to set.

Instead I think it would be useful for someone else to setup a "kernel
compile machine" and automate it as they see fit. They could then
contribute to the development effort by reporting combinations of
options that don't compile. This compile testing would be largely
decoupled from the Linus patch-release cycle.

I know that mozilla has tinderbox and bonsai, but I really don't think
they will work very well for linux kernel development. The number of
different compile options in the linux kernel is very different from
mozilla. There is no "standard kernel".

From the comments I've seen from Linus, davem, alan etc I think that
they mostly like the current linux-patches JitterBug system. It does
seem to work. The current problems come partly as a result of Linus
deciding that the system isn't appropriate during a
code-freeze. Perhaps there is some way it could be modified to be more
useful for him during a code-freeze, useful enough that the mousing
around is worth it. I'll discuss it with Linus privately.

Cheers, Tridge

-
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:44    [W:0.114 / U:4.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site