From: Jiri J. <jja...@re...> - 2012-10-05 09:09:10
|
On 10/04/2012 06:49 PM, Linda Knippers wrote: > Hi Jiri, Hi Linda, > > I'm not sure I understand so perhaps you can provide a bit more > history. > > It sounds like that at some point, there was a fork of the test > suite that was modified to support the RHEL5.6 KVM certification? > And this fork is CVS based, perhaps because the test suite was > using CVS at the time? > And you can't get the history of the changes to the fork from the CVS? > All answers are "yes, correct". > Does your version of the test suite have all the changes that we > made in the rhel5_6_testing branch backported to it? Sounds like > just some of them? Only some of them. My responsibility was to make RHEL5 Common Criteria retention testing (including KVM) possible. That could be done based on an older RHEL5.3 tarball (which was AFAIK a snapshot of the audit-test repository), that was patched to support multiple architectures, and somehow wire kvm tests to it. I soon realized that the kvm tests depend on additional utils/ changes, along with other modifications not included in rhel5_6_testing or the 5.3 suite tarball. I could also use a RHEL5.6 KVM, IBM-provided x86_64-only suite and backport "hopefully" several commits to make multiarch work. I chose the second path. I've been trying really hard to utilize my git skills and find a possible best point for the RHEL5.6 KVM suite, so at least part of its history could be recreated. I did a git-diff test of the imported tarball against all upstream commits and then compared the diff sizes. IIRC rhel_5_6_testing had about ~1MB of diff, the best result was ~400KB diff, somewhere before rhel_5_6_testing. I was ultimately able to identify the point based on a single change, a point where no piece of code was supposedly older than the 5.6 KVM suite, but the changes were massive enough that I couldn't be sure. Ultimately, and after further discussions with Miroslav Vadkerti, I decided to create a separate history, using the 5.6 KVM suite as a reference, building history (backports, fixes) on top of it. That's how the branch, currently containing about 30 commits, was created. > > If you're just looking for some place to store a tarball, we can > probably find a better place. As I said, my custom branch has exactly 29 commits at this point, fixing bugs in the suite, backporting additional changes to make multiarch testing work. The use case is automated kind-of-regression testing of newer RHEL5.x releases against RHEL5.6. All the automated parts and hacks are stored separately, this branch contains just a clean suite. At this point, the suite can either remain in one of our internal repositories, or it can be pushed to upstream to a separate branch, to keep the code in one place. As far as the size/cost goes, current audit-test clone, git gc'd (--aggressive): in-pack: 11809 size-pack: 5770 and with the branch: in-pack: 12249 size-pack: 5862 I hope that provided the missing details. Thanks, Jiri Jaburek |