aiaiai script set up

[Keller, Jacob E]

On Tue, 2014-05-27 at 15:09 +0300, Artem Bityutskiy wrote:
> On Fri, 2014-05-16 at 15:13 +0000, Keller, Jacob E wrote:
> > On Fri, 2014-05-16 at 12:45 +0400, Maxim Uvarov wrote:
> > > On 05/16/2014 11:58 AM, Artem Bityutskiy wrote:
> > > > On Fri, 2014-05-16 at 11:25 +0400, Maxim Uvarov wrote:
> > > >> On 05/16/2014 10:24 AM, Artem Bityutskiy wrote:
> > > >>> On Thu, 2014-05-15 at 20:10 +0000, Keller, Jacob E wrote:
> > > >>>> On Thu, 2014-05-15 at 21:02 +0400, Maxim Uvarov wrote:
> > > >>>>> On 05/15/2014 04:34 PM, Artem Bityutskiy wrote:
> > > >>>>>> Hi Maxim,
> > > >>>>>>
> > > >>>>>> just FYI, we have a mailing list nowadays, although it is scarcely
> > > >>>>>> populated anyway: aiaiai at lists.infradead.org
> > > >>>>>>
> > > >>>>>> There are archives, etc. Let me CC it.
> > > >>>>>>
> > > >>>>>> Jacob was using e-mail based work-flow, not sure if it is still the
> > > >>>>>> case, so I'll let him answer :-)
> > > >>>>> looks like answer is separate process with:
> > > >>>>> aiaiai-email-dispatcher -v  .../queue "aiaiai-email-test-patchset ..."
> > > >>>>>
> > > >>>>> at lest it began work for me.
> > > >>>>>
> > > >>>>> question is gone.
> > > >>>>>
> > > >>>> Yes, you use the aiaiai-email-dispatcher for scheduling, and it calls
> > > >>>> the aiaiai-email-test-patchset. Note that we have a lot of changes
> > > >>>> currently in the devel branch that I am getting ready to push into
> > > >>>> master, that will somewhat change how this command is run, but I think
> > > >>>> the overall changes are beneficial (moves a lot of configuration into
> > > >>>> the cfg file instead of on the command line options...)
> > > >>> Right, user-friendliness should be improved with your latest changes,
> > > >>> thanks!
> > > >>>
> > > >> Yes, also it will be good to detach it from kernel builds so that
> > > >> verifying patches
> > > >> for other projects should be also possible.
> > > > Well, the whole thing was created just for the kernel. I am not sure it
> > > > is feasible to extend it to anything else, but if someone comes up with
> > > > a set of patches, this can be done, theoretically, although quite
> > > > frankly, I am a bit skeptical about this. But, "patches talk, bullshit
> > > > walks" as they say :-)
> > > >
> > > As I understand the only thing is needed is to remove make defconfig. So 
> > > that user can define
> > > which command to use for building. At least it worked in my case for 
> > > master branch.
> > > 
> > 
> > I have a few patches in the works which add "build" types such as
> > kernel, standard make, and ./configure builds. Fully extending this to
> > ANY build system would be non-trivial, but not impossible. I used this
> > to allow building of ethtool, but I haven't yet posted this series to
> > the devel branch yet.
> 
> Jacob, do you think we can merge devel into master already now?
> 

Yes I was planning on looking at that today. :) I have been delayed with
other projects until recently.

Thanks,
Jake