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 <[email protected]> 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) _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
