[Open-scap] OpenSCAP 1.2.0 coming soon

[Martin Preisler]

----- 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 12:28:06 PM
> Subject: Re: [Open-scap] OpenSCAP 1.2.0 coming soon
> 
> [snip]
> 
> The decision was not made. Though I have projects that depend on changes
> in master that have tight schedule. I will blog about them shortly.
> 
> foreman_openscap needs SCAPtimony needs ruby-openscap needs openscap
> 
> If I manage to release all the four projects, we will be able to collect
> and show OpenSCAP reports from Foreman infrastructure. Then, I can
> announce the projects to Foreman community.

Do you really need released openscap to showcase this? Is there enough
functionality in foreman_openscap to warrant upstream releases of
4 projects and a lot of headache for other people depending on openscap?
Will these releases be shipping anywhere?

Could you please elaborate on the deadlines so I can plan my openscap
work around them? They clearly involve me and I have no idea.

> > There are still regressions from oscap_source that haven't been fixed.
> 
> I know only about a single one. Are there really more of them?

CPE autoload is the one you know about I guess. The branch is too new for
me to give you a good answer. I have just begun to move workbench to the
new code. It's likely there will be more issues that I come across.

There certainly are issues in workbench that need addressing [1] and they
weren't there before oscap_source. However I can't classify them as
regressions, because workbench is taking advantage of knowing openscap
internals. Very often it's just new functionality that workbench isn't
expecting.

> > I need changes in openscap master to support new workbench functionality
> > that has not been written yet. Furthermore I have RFEs for report and
> > guide that I would like to implement.
> 
> We can release 1.2.1 shortly after. Would it help?
> 
> >                                       Semantic diff is also planned
> > for 1.2.0.
> 
> Semantic is too big bite. I am afraid that Foreman/OpenSCAP integration
> cannot wait until the diff is done.

Semantic diff is a very important feature that has been requested for the
past 3 feature releases. Probably before that too. I think it's not such
a big undertaking. Especially if we narrow the scope at first and go for
just a good XCCDF TestResult diff. Diffing 2 TestResults of the same profile
would go a long way as the first implementation.

I guess it's a feature you plan in foreman integration too. Furthermore
it's important for cockpit integration. That's work I have deadlines for ;-)

The most important outcome of this discussion so far is that we could use
a release schedule for openscap to avoid these surprises in the future.

> > And then there is:
> > https://fedorahosted.org/openscap/query?milestone=1.2.0&status=assigned&status=new&status=reopened&group=status
> >
> 
> I've tried to address these issues above.
> 
> > It adds another maintenance branch which has significant cost. I would
> > prefer to release with more new features than what we have right now.
> > Do we really want to release a new breaking release every 2 months?

I'd like you to address this please. We have grown to be a very responsible
upstream in the past year and a half. This seems like a step back.

[1] dependency closure for bundle exporting, remote scanning and bzip2
(detecting support), bzip2 inside RPM bundle. I could go on, as I said
the branch is too new.

-- 
Martin Preisler