Re: jitterbug

Jauder Ho (jauderho@transmeta.com)
Wed, 30 Sep 1998 13:31:37 -0700 (PDT)

for automated testing, you can look at possibly setting up bonsai and
tinderbox... code released courtesy of netscape. basically the kernel is
rebuilt over and over again constantly. But this is obviously only useful
if said kernel was changing a lot... www.mozilla.org.

--Jauder

On Wed, 30 Sep 1998, Stephen Frost wrote:

> On Thu, 1 Oct 1998, Andrew Tridgell wrote:
>
> > The big disadvantage of the linux-patches JitterBug is that it is more
> > work for Linus. He needs to use a browser to change the status of
> > patches when he accepts/rejects them (lots of "mousing around" as he
> > puts it). The big advantage is that it allows everyone to see the
> > status of pending patches and the explanations (attached as notes to
> > the patch) of why it was accepted/rejected/deferred. If Linus is
> > willing to do the mousing around then I think that the other
> > developers could benefit a lot from the system, but it is for Linus to
> > decide if he can afford that time.
>
> 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.
> 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).
> 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..
>
>
> 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/
>
>

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