On Jul 24, 2013, at 11:40 AM, Marcus (OOo) wrote: > Am 07/24/2013 07:07 PM, schrieb Rob Weir: >> 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. > > I don't think that it will help to prevent every error of this kind. > >> Also, I don't see how your solution helps with truly accidental >> commits. Surely PMC members make errors as well? > > Of course, as they are humans, too. ;-) > > But you don't become a PMC member by default. You need to show some things > that you have understand how the page is turning. And then I doubt that such > error would happen. > > So, I also think that we should do more than just turn the CTR into RTC and > expect that no mistakes will happen after that. > > My 2 ct.
I think that there are a few things to think about. We can all understand when RTC and CTR are in effect. These are different in different systems. We are talking about a situation where a commit was made that was not acceptable. Since it was in svn we can always revert. In other systems we have other means of restoration. I don't think we need extra security. We may need a review of our systems to know what is in effect. WIth that in hand we can discuss what policy changes to make. Whatever changes might be made they should be the smallest possible and kept simple. Regards, Dave > > Marcus > > > --------------------------------------------------------------------- > 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
