Re: Patches Web Site/Newgroup?

Bruce Thompson (bruce@otherother.com)
Thu, 1 Oct 1998 07:27:10 -0700


Hi,
I'll go back to lurking in a moment...

</lurk>
What about using GNATS as a patch submission mechanism? I know it's
primarily a bug database, but its totally email driven, there's a number of
reports that can be pulled out of it easily and it might actually do the
trick (almost automatically!)

Here's what I'm thinking. A patch author submits a 'bug' which contains
the text of the patch. Gnats accepts the report, opens a bug number and
automatically notifies the author of the bug number and the "patch triage"
person of the new patch. The "patch triage" person assigns the bug to one
of a set of "patch verifiers", putting the report into the "investigation"
state. If the patch is bad it is immediately closed and the author is
notified of the disposition automatically, along with the reasons why it
was rejected. If the patch is good it is moved to the "integration" state
and re-assigned to the "patch integrator", that would likely be Linus.
Linus then takes the patch looks at the commentary in the report and either
applies it to the "official" tree or rejects it. In accepting or rejecting
the patch, the report is closed and the author is automatically notified of
the disposition.

At any time, reports can be pulled out of patches pending triage,
patches being verified and patches pending integration. All of this is done
automatically by GNATS.

The real beauty is that all of this is done using email to a central
GNATS repository. There's a small set of programs (shell scripts as I
recall) that are distributed to anyone submitting patches containing
principally the email forms and emacs macros to permit everything to be
done from within emacs.

It's been a while since I used GNATS, but I'm certain that it would
provide the origanizational infrastructure that's missing. There's still
the issue of synchronizing with the "official" source trees, but those are
fairly easily handled IMO. The "patch verifiers" would work off the same
tree Linus is (via CVS perhaps) and if a patch fails to apply that's
grounds for rejecting the patch immediately.

With a bit of work (who knows, the hooks might already be there...)
this could all be brought out to web pages as well. The queries could
easily be brought out to web pages.

<slightly later>

Before I get flamed, I just realized that Jitterbug might also provide
all this functionality. If so then please ignore this message and let's get
on with actually implementing the system... :-)

<still later>

I think thgere's also a need for an automated kernel test system. There's a
configuration management tool I use called "aegis". The main reason I use
it is because it requires that all changes applied to the baseline be both
tested and known to pass the baseline test suite. The idea is that any
change must have tests that it passes but the baseline fails. The baseline
has a regressions suite that the new change must also pass. Once a change
is integrated the tests for that change become integrated into the baseline
regressions test suite. Being able to report that a patch has a set of
tests that it passes and the baseline kernel fails, along with a report
that the patch passes all regression test cases is powerful information for
considering whether or not to integrate a patch.

nuff rambling,
Bruce.

<lurk>

>On Wed, 30 Sep 1998, Albert D. Cahalan wrote:
>

[snippage]

>
> Part of the idea was to not create any more work for Linus, however
>it would be nice to be able to get some feedback from him. This setup could
>also email any patch that hasn't been 'cleared' by the patch-submitter to
>Linus once the patch has become a week old.
>
> This takes some of the work off of the patch-submitter, but replaces
>it w/ a req. that the patch submitter submit a 'cleared' notification so that
>Linus doesn't keep getting patches over and over.
>
> However, this moves the load of work from Linus to the various
>developers, not that sending an email to the like of 'PATCH: XYZ, ACCEPTED'
>is all THAT much work, and in fact a better system would be to email the patch
>to Linus and the developer where either can just hit 'reply' and type
>'ACCEPTED'
>in the body or subject or something and have the patch be updated as
>'ACCEPTED'
>and have it no longer sent to Linus every week.
>

--
------------------------------------------------------------------------
Bruce Thompson                  | "So long and thanks for all the fish"
late of                         |   -- Hitchiker's Guide to the Galaxy
Newton Inc.                     |
                                |
bruce@otherother.com            |
                   My opinions are strictly my own.
	    (finger thompson.long@rahul.net for PGP key)
  PGP Fingerprint: 8F48 7FEF EE22 14FB 1F2E  3BF2 0D40 9628 53E8 72EB

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