MENTORS, The last priority over the next two weeks before GSoC begins is for students to establish their commit privileges. For that, they need your help. Please review and provide feedback. Thanks to those of you (Cliff, Erik, ??) that have been hitting them up hard and to others interacting with students on their project plans and wiki pages.
The standard practice employed since our open source project was established is that new contributors have to demonstrate competency with our contributor responsibilities. Paraphrasing HACKING, those already with commit access have a responsibility to ensure new contributors are following the guidelines in the developer's guide. In practice, that generally means new contributors need to provide at least one but ideally two "non-trivial" pristine patches that apply *flawlessly* without breaking anything. The code should be demonstrably "better". As you review patches [1], be critical. It's okay to reject them when there is an issue. The structure of the patch and change communicated by it is more important than the "content" of the patch itself. If you have to make a change in order to apply the patch, any change, then that detail needs to be communicated to the contributor (even if it's simply incorrect formatting) and they need to try again. [1] https://sourceforge.net/tracker/?group_id=105292&atid=640804&status=1 STUDENTS, Please don't take criticism or a patch rejection personally! :) It's all just about making sure everyone has the same healthy understanding so all developers can be productive. Especially for a large project like BRL-CAD with an extensive source code history, code quality is vitally important. If that change you spent a week working on injects a bug that isn't discovered until a year later -- but then takes three developers a couple days to diagnose, inspect, fix, test, cleanup, and document -- then that change was ultimately a net negative waste of time. Nobody wants that. Be sure you're read through the HACKING file, particularly the COMMIT ACCESS and CONTRIBUTOR RESPONSIBILITIES and CODING STYLE & STANDARDS sections. Make sure you actually run the application/library/interface before your change and check it afterwards to make sure you didn't break anything! Make sure you're following our conventions; make sure you test. Ask questions. Some patches are very quick to review and apply and others will take some time, but communicate with the developers to remind them of your patch if you're waiting on feedback. Make your patches as small as possible (without making them trivial) so they are easier to review. They don't have to be glorious big patches that change the world or fix impossible bugs. On the contrary. They need to demonstrate that you understand our code conventions, you know how to communicate a code change, you know how to properly document your work, you know how to test your changes, etc. Everyone should have commit access before GSoC begins. Several of you are nearly there (or already there): Wu, Christina, Ksenija, and Andrei. Suryajith is the only one working in isolation so he gets held to the fire differently. ;) The rest of you are either pending review or were given feedback, your patch needs more work, or you need to submit additional patches. For everyone, continue to submit your work through the patches tracker until a developer lets you know that you've been granted commit access. Once you have access, you will be expected to commit *daily* and throughout the day while you work on your project. Cheers! Sean ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
