[Open-scap] OpenSCAP 1.2.0 coming soon

[Simon Lukasik]

On 10/23/2014 06:52 PM, Martin Preisler wrote:
> ----- Original Message -----
>> From: "Simon Lukasik" <slukasik at redhat.com>
>> To: "Martin Preisler" <mpreisle at redhat.com>
>> Cc: open-scap-list at redhat.com
>> Sent: Thursday, October 23, 2014 5:50:05 PM
>> Subject: Re: [Open-scap] OpenSCAP 1.2.0 coming soon
>>
>> Martin,
>>
>> I will try to find out, if I can live a few more weeks without upstream
>> release. I don't need new OpenSCAP just for playing or a showcase, I
>> have to have it in late November to productize things. The earlier I get
>> it the better.
>
> I would prefer an -rc release for now perhaps. But that probably wouldn't
> help.
>
>> So, I will try to build a development version in COPR environment, until
>> you resolve the issues you need to resolve.
>
> That would be great. I have re-planned some tasks and put higher priority
> on openscap changes.
>
>> Regardless, I have to disagree with the comments regarding the stability
>> of the new release. I simply don't understand them. You keep referring
>> to master branch as 'breaking release' or 'step back from responsible
>> upstream'; I am sorry that you feel it that way. I have tried hard to
>> not break things, I went extra mile when re-engineering the parsers
>> during September to ensure that there are no headaches going forward.
>
> This is simply a misunderstanding. I have no problems with your changes,
> I think they are great, as I have remarked many times. Currently I am
> having a hard time understanding why you came to this conclusion.
> It's almost impossible to make such big changes to the internals without
> breaking some use-case and you came pretty close. What I was getting at
> was the speed at which we are pushing out new feature releases.
> openscap 1.1.x will be very short-lived, don't you agree? We only
> released a single patch version!
>

I agree, that maint-1.1 would be short-lived. And I agree that having 
many maintenance branches would be overhead. Don't take me wrong, but up 
to certain point I don't care if a branch is short lived or not.

Instead, I try to optimize my workflow, and my best judgment told me to 
release now. However, after your feedback it feels that my inner 
judgment is not discounting the maintenance burden put on others.

So here is the thought, what about dropping maint-1.1 after 1.2.0 
release and maintain only maint-1.0, maint-1.2 and master branch?

> I simply want to push for more long term planning, where long term
> doesn't mean 2 months. At this pace we will be maintaining tens of
> feature branches in a few years.
>
>> I am sorry that you are having hard times rebasing scap-workbench to new
>> API. I didn't dropped a single API call. I only deprecated couple of
>> them. I made sure to keep all the deprecated calls working. So, I am
>> surprised, there are problems.
>
> I am not having a hard time, but I am having "a time". As anyone who
> is using the API would. This is *absolutely normal* and expected.
>

Happy to hear that! I've misunderstood your sentiment then.

-- 
Simon Lukasik
Security Technologies, Red Hat, Inc.
https://github.com/isimluk