I've a quick question regarding the policy for granting/sponsoring CVS/subversion write access. There seems to have been a recent change in thinking (or difference of opinions) on the pre-requisites for allowing a new contributor modification rights to GCC's source repository.
My understanding (which is admittedly mostly personal and historical) is that someone is granted write access once they have demonstrated an understanding of the rules and policies for submissions to GCC. I'd submitted ten or twenty patches to GCC, before RTH offered to sponsor my write access. Admittedly this is a bit extreme, but the rule of thumb that I currently use is to sponsor someones write access once they've submitted a patch that doesn't require changes (correct, following GNU-style, documentation changes, new testcase(s), with a ChangeLog entry, properly tested listing target triples). There does however appear to be another school of thought that suggests that write access should be immediate, following the acceptance of FSF copyright assignments, possibly implicitly by becoming a employee of a "blanket-assignment" company. In the interests of consistency I was wondering whether there was any official advice or guidelines on this aspect of GCC protocol? Increasingly, there have been examples of patches getting checked-in without maintainer approval, or without posting to gcc-patches, etc... I'd assumed that one reason for the right-of-passage of GCC CVS access was that no-one would be able to delete/corrupt the GCC repository without first having read contribute.html. One reason for requiring a "sponsor" is that a maintainer is required to vouch for the behaviour/apptitute of a new "Write After Approval" contributor. And in theory breakage of the regulations should reflect not only on the violator but also of his/her sponsor's judgement. I also suspect that the ultimate recourse of the SC is to revoke someone's write access. Unfortunately, this aspect of GCC protocol isn't clearly documented, and I base my current actions on experience of legacy policies. Admittedly, it'd be easier to relax "admission requirements" and thereby reduce the number of commits that have to be made on behalf of those without access. Perhaps the effectiveness of the "three stage system" at stabilizing the tree has reduced the need for the earlier methods used to ensure/improve the quality of contributions. There's also the new/recent complication that companies/groups now maintain their own GCC branches, perhaps requiring write access even for programmers who don't contribute to FSF GCC. What do the other maintainers, or the SC, think? Roger --
