On Thu, Jul 25, 2013 at 1:17 PM, Marcus (OOo) <marcus.m...@wtnet.de> wrote:
> Am 07/25/2013 08:47 PM, schrieb Rob Weir: > > 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. >> > > +1, one for all. > > Marcus +1 from me on this also. maybe start a new thread and do Lazy Consensus? There seems to be no direct use of any information via the web in /marketing/art/galleries/logos/aoo-working that I can determine, so a good time to move and update the website logo page. http://www.openoffice.org/marketing/art/galleries/logos/index.html > > > > > 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-unsubscribe@openoffice.**apache.org<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
