[Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Josh Triplett]

On Sun, Jul 12, 2015 at 06:48:07PM +0800, Fengguang Wu wrote:
> On Sun, Jul 12, 2015 at 09:19:53AM +0100, James Bottomley wrote:
> > On Sat, 2015-07-11 at 22:19 -0700, Josh Triplett wrote:
> > > On Sun, Jul 12, 2015 at 10:02:35AM +0800, Fengguang Wu wrote:
> > > > On Fri, Jul 10, 2015 at 09:54:42AM +0100, James Bottomley wrote:
> > > > > On Thu, 2015-07-09 at 14:00 -0700, josh at joshtriplett.org wrote:
> > > > > > On Thu, Jul 09, 2015 at 10:38:30PM +0200, Luis R. Rodriguez wrote:
> > > > > > > On Thu, Jul 09, 2015 at 01:11:27PM -0700, josh at joshtriplett.org wrote:
> > > > > > > > Bonus if this is also wired into the 0day bot, so that you also find out
> > > > > > > > if you introduce a new warning or error.
> > > > > > > 
> > > > > > > No reason to make bots do stupid work, if we really wanted to consider
> > > > > > > this a bit more seriously the pipeline could be:
> > > > > > > 
> > > > > > >   mailing-list | coccinelle coccicheck| smatch | sparse | 0-day-bot
> > > > > > 
> > > > > > That would effectively make the bot duplicate part of 0-day.  Seems
> > > > > > easier to have some way to tell 0-day "if you see obvious procedural
> > > > > > issues, don't bother with full-scale testing, just reject".
> > > > > 
> > > > > We already have this with the 0 day project.  The only difference being
> > > > > the patch has to be in a tree for it to get tested.  It's not impossible
> > > > > to imagine a bot that would pick up a patch, apply it (giving automated
> > > > > rejects as email replies), and leave it in for the 0 day tests to
> > > > > assess ... sort of like patchwork but with an automated tree build.   We
> > > > > could periodically throw away the tree (say weekly) because the job of
> > > > > the bot would be to find initial rejects rather than build a workable
> > > > > tree.
> > > > 
> > > > That's a good point. Up to now 0-day only takes care of code in git trees.
> > > > We've collected 500+ developers' git trees so far, however their coverage
> > > > looks not enough -- there are 3000+ kernel developers in last year's git log.
> > > > 
> > > > To achieve 100% code coverage, we'll also need to watch emails in the
> > > > kernel mailing lists, auto convert patch series there to git branches
> > > > for 0-day and other testers, and auto reply results to the original
> > > > mailing list's email thread.
> > > > 
> > > > That would be a natural fit for the email based patch submission path
> > > > and review process.
> > > > 
> > > > The potential problem, however, is "git-am to which base branch?"
> > > > That's where it may go messy.
> > > 
> > > Patch submitters should be making it clear to what tree their patch
> > > applies, preferably using an unambiguous tag in the mail subject.  In
> > > the absence of such a tag, try it against torvalds/linux.git and
> > > linux-next.git, and then give up and tell the submitter to specify what
> > > their patch applies to.
> > 
> > To be honest, the mailing list it's sent to mostly identifies which tree
> > it should be going in.  There's difficulty over whether the for next or
> > for current branches ... but we have that today as well.
> 
> Yes, mailing list would be a very good hint.
> 
> Another clue can be the index part of all git emails
> 
>         diff --git a/Makefile b/Makefile
> ==>     index 3ba5044..f5c8983 100644
>         --- a/Makefile
>         +++ b/Makefile
> 
> That object id may help identify the possible BASE branches for the
> email patch. Due to my limited knowledge of git, I can only think
> about a brutal force (but still affordable) way to iterate all the
> well known branches to find the possible BASE branches.

That's a good idea.

- Josh Triplett