[vbox-dev] Open Letter to Oracle: Please open up community development

[Pau Garcia i Quiles]

Hi,

What about mimicking the Qt Project - Nokia relationship?

Nokia keeps their own git repositories for internal development, then
automatically push to/pull from qt.gitorious.org

Closed development is kept closed by developing closed stuff in
separate, non-published repositories (there are very few of these now)

All code is contributed through gerrit, i. e. git + two reviews before
it is merged into the official branch

All code contributions must include autotests. Even after reviewer
approval, it still must pass continuous integration autoapproval: it
must build and not break anything.

etc

It's all explained here:

http://wiki.qt-project.org/Main_Page

(of course git helps a lot with that workflow: forking and merging are
very lightweight and smart compared to Subversion)


On Tue, Feb 28, 2012 at 8:02 PM, Klaus Espenlaub
<klaus.espenlaub at oracle.com> wrote:

>> Many community patches are around for 3 months, unreviewed. [1]
>> Last year (2011) things were looking better, and the UDP Tunnel patch,
>> among others, was reviewed quickly, and went into the tree in 2
>> months.
>
> There are a few pending patches, but not that many. It's unfortunately
> the case that the workload of the VirtualBox development team has grown
> a lot. The community is bigger than ever (however 99.99% passive users
> which at most create bug reports), and the number of customers is also
> bigger than ever.
>
> This means that for getting things into the tree quickly the developers
> depend on better quality patches. So far we often took patches, ripped
> them to pieces and reused just some parts of it, or even only the idea
> and problem analysis. This is very time consuming, and is part of the
> reason why we don't even start integrating certain changes. And I'm
> completely ignoring the testing aspect - we only know that approx. 1
> user has tested the patch, and sometimes it's far from obvious if it
> breaks other use cases.
>
> The biggest pending change (the Haiku port) is waiting for build tools
> integration, and this is simply time consuming. The quality of this
> contribution is very high.
>
> In general most pending patches have a very small expected user base,
> and the consequence is that we have to work on them with low priority.

>> My suggestions are:
>> 1. let old-time community members submit patches to SVN tree directly
>> (+active new members should get this ability too...). The benefit is
>> that old-time community members will start reviewing patches by new
>> community members.
>
> 1 is most likely impossible to achieve, as the actual subversion
> repository can't be made accessible to non-Oracle employees. It contains
> components which are not open source. There are other technical
> problems, too.
>
> What would be possible is a more direct way of getting patches submitted
> for inclusion, which have been community reviewed and tested, and have
> clear copyright statements. If anyone knows good tools for managing
> patch contributions for subversion I'd appreciate if you drop me a line.
>
> The current state is that it's done completely manually, and that's one
> reason for being so susceptible to individual developer overload.
>
> I can't repeat it enough - the key item is quality. If the contributions
> cause as little regressions as possible it's good for everyone. If a
> contribution causes a significant problem for a paying customer there
> will be sooner or later questions what the advantage is for Oracle...
>
> In the end it's a risk management question, and any viable solution must
> give an answer to this question.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)