Re: [RFC + PATCHES] Work to get KVM autotest upstream

[Ryan Harper <ryanh@us.ibm.com>]

* Michael Goldish <mgoldish@redhat.com> [2009-05-13 14:54]:
> 
> ----- "Lucas Meneghel Rodrigues" <mrodrigu@redhat.com> wrote:
> 
> > On Wed, 2009-05-13 at 12:23 -0400, Michael Goldish wrote:
> > > The patches look good, but I haven't tested them yet to make sure
> > > they leave everything at a functional state (will test them and let
> > > you know).
> > 
> > Thanks Michael! I will start to give more thorough test on this
> > today,
> > since we finally got 0.10 in shape.
> > 
> > > I have a somewhat related question: how is KVM-Autotest development
> > > going to proceed after the upstream merge? Currently I have
> > > comfortable access to our repository at TLV, and on good days I
> > push
> > > as many as 20 patches per day. Should I submit all patches to the
> > > Autotest mailing list after the merge, or are we going to work with
> > > pull requests, or some other way? Will we work with git or svn?
> > 
> > Here is my plan: For people inside our team, with access to the git
> > tree
> > we can just pull stuff to the git tree and on a given time basis I
> > can
> > pick up the patches and send them altogether to the KVM and autotest
> > mailing list, wait for reviews and then check them.
> 
> I think it would be nice to have a 'fast' development channel like
> directly pulling from a git tree.
> 
> > If you are already used to send all your changes to the KVM mailing
> > list
> > though, this would pose little or no change to you, just send an
> > additional cc to the autotest mailing list.
> > 
> > What do you think?
> 
> So far we've kept development mostly internal in TLV, so I'm not quite
> used to passing my commits through the mailing list. Will this be
> necessary? I'm worried it might slow down development to a grinding halt.

I'd definitely like to see patches to the list before committing; we do
the same for kvm, qemu etc, not sure why kvm-autotest should be any
different.  On the other hand, it's not currently being done that way
and I'm not losing any sleep over it; it's easy enough to git log and
and email the list if you break something or think something should be
done differently.


-- 
Ryan Harper
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
ryanh@us.ibm.com