"Milan Bouchet-Valat" <nalimi...@club.fr> wrote in message news:1319202026.9174.6.camel@milan... > Le vendredi 21 octobre 2011 à 13:39 +0100, Charles Roosen a écrit : >> Hi, >> >> >> I've recently taken over maintenance for the "xtable" package, and have >> set it up on R-Forge. At the moment I'm pondering what the best way is >> to handle submitted patches. Basically, is it better to: >> >> >> 1) Be non-restrictive regarding committer status, let individuals >> change the code with minimal pre-commit review, and figure changes can >> be reviewed before release. >> >> 2) Accept patches and basically log them as issues to look at in >> detail before putting them in. > I'd say you'd better review patches before they go in, as it would be > quite ugly to fix things afterwards, right before the release. If a > patch is buggy, better catch problems early instead of waiting for > changes to add up: then, it will be harder to find out the origin of the > bug. It also allows you to spot small issues like styling and > indentation, that you wouldn't bother to fix once they've been > committed. > > You can give people committer status, but ask them to post their patches > as issues before committing. This reduces the burden imposed on the > reviewer/maintainer. > My view :
1) Yes, be non-restrictive but impose some ground rules : i) each commit should pass 'R CMD check' ii) each new feature or bug fix should have an associated test added to the test suite (run by R CMD check), and an item added to NEWS (by the committer). iii) all developers subscribe to the -commits list and review each commit in a timely manner when the unified diff arrives in your inbox. If something is wrong or forgotten, ask the committer to fix it there and then. Matthew > > Regards > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel