There is a weekly, one hour call at 15:00 UK time on Tuesdays to discuss Virgo. See meetings for details.
Very occasional face to face meetings will be held. See F2F for details.
Suppose you see a need to change Virgo somehow. You can start by raising this on Virgo-Dev or as a bug, but suppose the committers don't dive in and make the change for you. Don't take this personally - Virgo is an active project and there's always more to do than the committers have time for.
That's where contributors come in. You may not feel very confident about changing the Virgo codebase, but the best way to learn is to do. The committers are interested in building up the Virgo community and they should help you navigate the codebase and can provide useful feedback on changes you are proposing. So file a bug, attach your code, and take it from there. But before you do, please read on to understand what makes a good contribution.
a good contributor
- checks out the flow chart in the Eclipse Legal Process poster
- ensures that they wrote 100% of the contribution and did not copy content from elsewhere or rely on the intellectual property of others.
That makes the contribution process so much simpler.
- attaches the code as a patch (easily created using git diff) to a Bugzilla bug (under RT/Virgo/core) so that a committer can perform the necessary due diligence checks.
In the bug the contributor (that's you) must confirm that they wrote 100% of the code contributed (in particular that none of it is copied from elsewhere), that they have the right to contribute the code to Eclipse (e.g. the employer agrees or the code is produced in personal time and contracts do not assign ownership or copyright to the employer), and that any new files contain the appropriate License header with the contributor (or the employer, as appropriate) as the copyright owner and the contributor as the "initial contributor". (See existing files in the Virgo source code repositories for examples of the copyright and license headers.)
See Committers for information about coding conventions and testing which will make your contribution more easily consumed by Virgo.
Contributions should include unit tests whenever possible and integration tests where appropriate. This ensures that the contributed code is well structured and can be tested, as well as avoiding the technical debt of code waiting to be tested. The committers that handle the contribution will assess these criteria.
You should probably discuss large contributions (more than 250 lines of code and/or configuration) on the virgo-dev mailing list first so everyone knows what's going on. Small patches and additions (e.g. extra unit tests) can be made with little or no discussion. Remember that patches or enhancements can often include 'too much'. It is tempting to include unrelated changes with another idea -- simply because they are 'close by' in the code. No-one is particularly at fault here, but if patches are ruthlessly reduced to the smallest possible units they are more likely to get in. Small is beautiful, and minimal is marvellous.
So, silly as it may seem, if you spot a single line correction (or 'improvement') while writing your magnum opus, please resist the urge to 'just put it in'. If a single line bugzilla patch is raised, it can get in much more easily than a collection of changes, and is quicker and simpler for all concerned. If the change is unrelated, or just 'independent' in the sense that it could be made separately without harm, then please do separate it. That way it won't be 'caught up' in a long discussion (and possible rejection) that has nothing to do with it.
Currently Under Discussion
There are topics for discussion that have got beyond a forum thread. Please feel free to contribute your design thoughts.
Take Virgo for a spin
If you want to take the Virgo server for a spin, go here.
- Migrating from dm Server 2.0.x to Virgo 2.1.0
- Migrating from the dm Server slices prototype to the Virgo snaps prototype
- Migrating from Virgo 2.1.0 to 3.0.0