Hi Technologov, sorry about the late answer. Again an issue with too much to do. I'm also sorry about the length, but this is a complex subject, especially in the context of a big company like Oracle. It's far from Oracle specific, though.
Note that the below reply is purely my personal opinion, and while it does make statements what's possible or not this isn't a legal statement. It intentionally ignores as much as possible commercial aspects (licensing, support), since this is a question from the community. It's hopefully clear enough that my mail is neither a full "yes", nor a "no". I'm too much of an optimist to say no, and too much of a realist to say yes. On 13.02.2012 17:29, Alexey Eromenko wrote: > Hello, > > 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. > I'd like to ask Oracle to open up development, and let old-time > community members submit patches for VirtualBox directly. > The problem of large sets of unofficial patches, is that they later > result in official forks. Forks wouldn't help with getting the features integrated, they would harm everyone. Due to the license it's impossible to prevent forks, but the aim is to avoid encouraging this. This is why a lot of time is invested into the community. > I understand that you were busy with the Oracle SSO transition, but > this is now over. Some nightmares don't end immediately when the publicly visible part of it is done... > 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. > 2. Allow GPL-only code into the code tree, provided it can be disabled > at compile time (so that Oracle VirtualBox will be shipped with those > features disabled, under dual-license, GPL+PUEL). -- This is needed > for some potential contributors. 2 is already reality, but is only accepted if there is no other way, like a significant amount of 3rd party work which can't be easily avoided. The VNC support is GPL only, because libvnc is GPL, and no one has time or motivation to do a replacement library. I prefer to keep code in this category at the very minimum, because it creates "black holes" in the source tree which aren't routinely tested. This means they'd become a risk of build failures due to code changes elsewhere. Leaving it to the community can be seen as an answer to this concern. I don't follow this argument, though, as it implicitly means there are inevitably more follow-up contributions to keep the feature alive, and this takes time, no matter how streamlined the contribution process is. GPL-only parts of the code would also be some risk for OEMs - they can't use such code in their sometimes very unusual environments. Not that they would need such code generally, yet it makes VirtualBox less attractive for this kind of application. The two accepted licenses/ways to contribute (MIT and OCA) are used by several Oracle projects, and thus are an established fact. Getting something different approved is most likely difficult. > I believe that opening up direct community contributions is > beneficial, provided those patches do not break the build for other > users. The "provided" clause hints in the same direction as I wrote above - quality must become more important. > The "community" window doesn't even have to stay open all the time, > but only after major release and until the BETA of the next major > release, while the window can be closed from the BETA and until final. See above - streamlining the patch submission/reviewing/testing/... process is in my opinion the only realistic goal in the foreseeable future, and I can't see far. > This may increase the rate of community patches and, in the long-term, > improve the product, overall. (despite the possibility of early > bumps.) If the rate improves and the quality is also high it can turn out to be feasible. Whether we'll get there is not certain, it depends on how effective the testing is and how efficient the patch integration can be made. The submission to the mailing list clearly isn't the most efficient way... > Can we come to some kind of agreement of how this can be done ? Working towards the mentioned goals is possible, and initially depends on a few community "contributions" in the form of working on the quality of the patches, and also making proposals about how the process efficiency could be improved. This is mostly food for thought initially, and is far from any "final" decision. Thanks, Klaus > > [1] List of OSS Community Contributions to OSE, including pending patches > https://forums.virtualbox.org/viewtopic.php?f=10&t=36800 _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
