Re: jitterbug

Stephen Frost (sfrost@ns.snowman.net)
Thu, 1 Oct 1998 08:02:21 -0400 (EDT)


On Thu, 1 Oct 1998, Andrew Tridgell wrote:

> Stephen wrote:
> > 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.

Possible, though I suspect he feels similar to the way I feel
about 'mousing around' vs. 'keyboard work', that is, 'mousing around'
is tedious and takes time where 'keyboard work' tends to be very fast.
In either case I think perhaps we should venture his opinion
on this, after all, that's what really matters, we can speculate all
we wish... :)

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

Understandable.

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

I agree, as many others have pointed out trying to compile-test
patches probably won't work very well, though testing that they will
patch correctly would be usefull.

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

The more I think about it the more I realize we already have
something like this in place w/ all of the people who test out the
new kernels and as such this perhaps wouldn't be very usefull unless it
could be automated...
Hmmm, that may be something to think about, have a system where
new kernels as released by Linus are sent to a number of machines around
the world for compilation and what not on. I expect may of the people
who like to be at the 'bleeding-edge' would probably want to be in on
this kind of system.

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

Unfortunately I don't have very much experiance with either of
those and as such I can't really venture an opinion as to if I think
they'd be usefull or not.

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

I fear that as the kernel gets larger and more patches get
submitted that the 'mousing around' time for each patch will start to
truely add up. This is why I'm pushing for an alternative to 'mousing
around'.
Some others here mentioned modifing pine to accept 'function-keys'
w/ automated replies that Linus could use to give developers faster
feed-back, something like instead of hitting 'n' for next message he can
hit 'F2' and a message will be fired off to the developer and JitterBug
saying 'Seen it, too busy, will get back to it later', JitterBug could
then registar that, mark it as 'PENDING Review' or something similar and
could then send the patch again to Linus a week later w/ a note saying he
said this was pending, now what?
Linus could also then hit the 'd' key for the second one if he's
still got the first one, or hit 'F2' again and then JitterBug would update
it's info w/ perhaps a 'Updated: 10/05/98' field to let people know that
yes he saw it and is still thinking about it.

Comments?

Stephen

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