On Thu, Jul 25, 2013 at 2:21 PM, Kay Schenk <kay.sch...@gmail.com> wrote: > On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher <dave2w...@comcast.net> wrote: > >> >> 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. >> > > In the two years since OpenOffice has been with Apache, in nearly every > case we have always had discussion on ANY change/commit in anything we > consider "source" that is not applied to a bug. So this excludes most of > the material on the web site with the exception of the new logo svgs. At > least that is my impression. > > This is not really clear in our Orientation modules. And, I think in most > people's minds, knowing when to go from CTR to RTC is not particularly > clear either. There are some implicit assumptions -- like don't mess with > SNAPSHOT builds -- but I think it would be better if we stated this > explicitly. > > I also suggest that any artifact we feel should be considered "source" -- > like the new logo svg files -- be put, if not in /trunk, in an SVN area > that has some distinguishing name so that it is clear to committers this is > really a RTC area. >
I like that idea. Something like /branding, a peer of /trunk and /ooo-site. That can hold the branding related source. But we can then also have specific bitmap versions checked into the website, for direct use. But we keep the source versions separate. -Rob > >> 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 >> >> > > > -- > ------------------------------------------------------------------------------------------------- > MzK > > Success is falling nine times and getting up ten." > -- Jon Bon Jovi --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
