On Fri, Jul 26, 2013 at 12:51:23PM +0200, Lukáš Doktor wrote:
> Dne 25.7.2013 21:52, Cleber Rosa napsal(a):> 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,
>
> Yes, I like this idea.
+1
>
> >
> > 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.
>
> Well for some libraries which are under continuous development the
> problem with newer versions vs. what is in current/stable/used
> framework might be a problem. Eg. cgroup_utils. Currently it exists
> in booth virt-test and autotest. To freeze it for one or two
> releases would be really painful.
>
> Better solution for me would be to let booth libraries coexist, make
> all changes to booth of them and when the library is untouched for
> one or two stable releases remove the virt-test one.
+1
>
> So the cycle would look like this:
> 1) Develop it in virttest
> 2) Move it to virttest.staging and propose it for inclusion to autotest
> 3) wait 1-2 releases
> 4) remove the virttest.staging version (and all links)
+1
>
> and in case of continuous development
> 3b) include all changes to booth versions and mark the current
> version in docstring on top of the file
> 3c) keep them in sync until the library is untouched for 1-2
> autotest releases
>
Since we're talking about it, ideally we should have library
versioning in autotest, so that tests don't break because of
library changes (specially 3rd party tests).
But I think the current approach of a single single global
version for autotest is fine. In the case of continuous
development mentioned above, an ad-hoc versioning using docstring
looks good enough. Maybe we should think of proper library
versioning in the near future, when autotest-1.0 is released.
(Versioning could be simple: define __version__{"major","minor"}
in the module. major would be incremented when compatibility is
broken and minor when bugs are fixed or new stuff is added --
AFAIK there's no consensus/standard for it in python yet).
Anyway, +1 for virttest.staging, I think it's a good idea.
Cheers.
- Ademar
--
Ademar de Souza Reis Jr.
Red Hat
^[:wq!
_______________________________________________
Virt-test-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/virt-test-devel
