Re: [Audit-test-developer] RHEL5 CC retention - branch creation

[Linda K. <lin...@hp...>]

Hi Jiri,

Jiri Jaburek wrote:
> 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.

Where will the branch be created?  Off the point at which you
were able to find the original of the code that the RHEL5.6 KVM
suite started?

-- ljk

> 
>>
>> 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
>