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.
>
> 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.
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)
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
>
>>
>> Lucas
>
_______________________________________________
Autotest-kernel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/autotest-kernel
