----- Original Message ----- > On 07/25/2013 04:41 PM, Lucas Meneghel Rodrigues wrote: > > Hi guys, > > > > I was reviewing some patches here, and bumped into one problem that we > > frequently have, while developing autotest and virt-test: > > > > "What to do with generic libraries that were developed while working > > on virt-test that are good enough for autotest inclusion?" > > > > Why is that a problem? Well, the recommended way of running virt-test > > is to: > > > > 1) Install an autotest RPM on your box > > 2) Clone the virt-test repo > > 3) Execute the bootstrap script > > 4) Profit > > > > So for a lot of people interacting with virt-test, we don't want them > > to clone the large and otherwise not very relevant autotest repo. The > > RPM is ideal for people that don't care about autotest itself. > > > > Now, the current process > > > > released autotest -> available packages for people to install with yum > > or apt-get > > > > Takes a long, long time to complete (4+ months). We're working hard to > > make this cycle way shorter and more efficient, but for now, let's say > > we're stuck with it. > > > > It follows that, for each library that we add to autotest, we need the > > same library to be on virt-test, until the new autotest arrives to the > > hands of distro users. One of the biggest problems with that approach > > is that we might lose track of what are the libraries, and how/when to > > phase them out from virt-test. > > > > My proposal is to create a fixed namespace, virttest.staging, that > > hosts all libraries that need a copy on virt-test, that will go to > > autotest in the future, and when they are available to the wide > > audience of developers, they can be ripped out virt-test. The cycle > > would be: > > > > 1) New coollib is proposed > > 2) It's added to virttest.staging.coollib > > 3) Once we feel it's good enough and fairly stable, it's proposed to > > autotest, where it goes to the most appropriate namespace. The > > addition is recorded on github or some other place. > > 4) On new autotest releases, the release notes are updated with the > > 'promoted' libraries. > > 5) When the new autotest release is packaged and the package is > > accepted, then the libraries can be dropped, so > > virttest.staging.coollib goes away. > > > > What do you say? Looking forward hearing from you, > > I do not see a single failure with your proposal. > > The only rule I'd add is that, once the library is added to Autotest, it > should freeze on virt-test, so that we do not loose any > fixes/improvements during that time.
I agree it sounds good. It could work quite well. Forgotten library in user's git repo will be solved by git pull request even if users adds some features to libs after merge of virt-test/autotest. For merging should be always special commit message to show user, what happens and why they can't do fast-forward update by git pull. > > > > > Lucas > > _______________________________________________ > Autotest-kernel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/autotest-kernel > _______________________________________________ Virt-test-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/virt-test-devel
