On Sep 11, 2012, at 8:22 PM, Curtis Rueden <[email protected]> wrote:
> I'm not advocating that junior developers not be allowed to touch the > build—otherwise how will they learn?—but I strongly recommend code review > of any changes a junior developer makes to a build system. Kind of roaming away from Maven v. Gradle, but a process that I've grown comfortable with in large groups is a) locking all the POMs for anyone who's not a "POM mentor", b) buddying everyone else with a mentor to submit their changes, and c) anyone starting a new subproject project gets full access to their own POM for the life of their project. This tends to lessen POM damage as mentors take responsibility for their mentees, causes mentees to think harder about whether they really need a POM change to move forward (they learn it's certainly more expedient if they don't!), but still allows folks entrusted to create new modules the freedom to roam, make mistakes with projects that are not part of the mainline build yet, and generally get experience with POMs that they wouldn't get with patches alone. Other tweaks are possible, such as having mentors being required to talk to architects for certain classes of changes (such as dependency changes). Note that dependency changes can also be managed by locking down a repository manager and disabling auto downloading. Brian --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
