On Wed, May 13, 2009 at 5:21 PM, Ryan Harper <ryanh@xxxxxxxxxx> wrote: > * Michael Goldish <mgoldish@xxxxxxxxxx> [2009-05-13 14:54]: >> >> ----- "Lucas Meneghel Rodrigues" <mrodrigu@xxxxxxxxxx> 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. > > If you have, or can have, a publicly visible git tree with your changes, you can generate pull requests from time to time. Then the job of the maintainer will be only to sanitize your tree, make sure it is in overall good shape, and merge it to the main stream. -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
