On Wed, Jul 24, 2013 at 1:00 PM, janI <j...@apache.org> wrote: > On 24 July 2013 18:34, Rob Weir <robw...@apache.org> wrote: > >> On Wed, Jul 24, 2013 at 12:03 PM, janI <j...@apache.org> wrote: >> > Hi. >> > >> > I have followed the discussions in here, and have seen a number of not >> > wanted changed in our important artifacts happen. >> > >> > I think it is important, that items like our logos, release notes etc. >> > cannot be changed by accident. I believe it happens by accident and that >> > could avoided with a simple measure. >> > >> >> It might be useful to think of this in terms of Review-Then-Commit >> (RTC) versus Commit-Then-Review (CTR) rules. Once we clarify these >> and when they apply, then we can discuss whether additional >> technological means are needed to enforce this. >> >> For the wiki the general rules is CTR for all users with an account. >> No additional karma is needed. >> >> The for resources in Subversion the general rule is CTR for all >> commiters. Additionally, the public can submit patches, to the list, >> attached to BZ issues, or using the CMS anonymous submission tool. >> This then is effectively RTC since a committer must first reviews the >> patch. >> >> Those are the default postures, but there are exceptions. For >> example, as we approach a Release Candidate we switch into RTC for the >> trunk code. We only make changes after a bug has been proposed and >> approved as a "release blocker" on the dev list. >> >> So we could simply adopt a RTC for certain resources at certain times. >> For example, Release Notes once a release occurs, are RTC. The >> project logos, once approved and published, are RTC. If we agree to >> such things there are lightweight ways of reminding ourselves. For >> example, we could have a README file in directories that are RTC that >> explain this. That should be enough for conscientious, >> well-intentioned volunteers, >> >> >> > I am normally strong against limitations, but I would like to suggest >> that >> > these items are moved to one (or more) subdirs, where the commit right is >> > restricted e.x. to PMC members or even less. Doing so will not prohibit >> > anybody from making their changes but simply avoid that the changes are >> > product wide. >> > >> >> Personally I think this is a RTC versus CTR question. This >> distinction is a tool that we don't invoke as often as we could. >> Maybe that would be sufficient, at least in SVN. >> >> Also, I think even a PMC member should be following CTR rules when it >> is in effect. I don't think of a PMC member as a higher class of >> committer in terms of what they have access to. >> > > I think you misunderstood me. I agree with the RTC/CTR discussion, but > that does not prevent the accidential commit, I think it has happened to > most of us, that we commit our changes, and we overlook that another file > is also committed. >
I disagree that we have a a problem with accidental overwrites in SVN in cases where it is clear that RTC is in effect. I think the problem is that it is not clear when CTR is in effect. Also, I don't see how your solution helps with truly accidental commits. Surely PMC members make errors as well? -Rob > rgds > jan I. > > >> >> Regards, >> >> -Rob >> >> >> > thoughts ? >> > >> > rgds >> > jan I. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
