Hi everyone, 

firstly I wanted to thank everyone for raising this issue. I wanted to point 
out that we are not talking about a security process here, but the development 
process. Or more accurately the cost of writing more secure code and the 
relative importance of security compared to features. And of course the recent 
increase of relative importance of "built-in security as a feature" since 
Snowden. 

> On 9 Nov 2015, at 16:31, Franz <169...@gmail.com> wrote:
> 
> (Please note that all of the above are my personal views, i.e. I'm
> explicitly not speaking on behalf of the project.)
> 
> 
> It seems positions are antithetic with no possible compromise in view. Sadly 
> this is a general problem of FOSS software: developers  tend to do what they 
> like and not what users request. And who can blame developers for that? After 
> all they are working as volunteers so they deserve to do what they like. No 
> possible compromise.

I don't think this is a fair statement: more than 95% of developers working on 
Xen are employees of large organisations. And they follow the priorities that 
their employers set. The same is true in Linux and for comparable projects and 
of course for proprietary software developers. Blaming open source developers, 
is simply wrong and not constructive. 

In fact, throughout 2014 and 2015, the project has received complaints from 
several large vendors that the Xen Project today is too rigorous with code 
reviews compared to Linux, KVM and QEMU and that it is now harder to get code 
into Xen compared to similar projects. To understand the root causes, the Xen 
Project Advisory Board has commissioned a study to look at the root causes  
(see http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01635.html 
<http://lists.xenproject.org/archives/html/xen-devel/2015-10/msg01635.html>). 
The result of the first phase of the study showed, that a primary factor for 
longer review times are significantly higher quality expectations on new code 
compared to the past. Of course this does not help with code that has been 
added in the past.

In many ways, the problem which was stated comes down to different 
expectations, by different classes of contributors. And a solution, will 
necessarily have to involve compromise. 

> Perhaps a way out of this impasse is to put bounties on Xen security tasks 
> identified by Joanna and properly advertise these bounties to Xen users. I 
> would give particular attention to the companies that use Xen.

I can certainly raise this suggestion with the Advisory Board and see whether 
we can make some funds available. However, the board has already invested 
nearly 50% of its entire budget in Test Infrastructure and is planning to 
continue to spend in this area at roughly this proportion of the projects 
budget. However, we do not have huge amounts of funds: thus, what we could do 
with bounties would necessarily be limited. 

I personally also looked at other ways to change the cost-benefit equation. One 
example is the Feature Maturity Lifecycle (see 
http://lists.xen.org/archives/html/xen-devel/2015-11/msg00609.html 
<http://lists.xen.org/archives/html/xen-devel/2015-11/msg00609.html> & 
http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html 
<http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg01992.html>) 
which aims to use better classification to change behaviour of contributors. 

I do hope, that this discussion can remain constructive. De-motivating the good 
work many of our developers (and in particular code reviewers) are doing, is 
really not helpful in this context. 

Best Regards
Lars


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to