openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <>
Subject Re: [DISCUSS] added security to avoid changes in artifacts.
Date Thu, 25 Jul 2013 20:17:03 GMT
Am 07/25/2013 08:47 PM, schrieb Rob Weir:
> On Thu, Jul 25, 2013 at 2:21 PM, Kay Schenk<>  wrote:
>> On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher<>  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<>   wrote:
>>>>>> On 24 July 2013 18:34, Rob Weir<>   wrote:
>>>>>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<>
>>>>>>>> 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
>>> etc.
>>>>>>>> cannot be changed by accident. I believe it happens by accident
>>> 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
>>>>>>> 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
>>>>>>> attached to BZ issues, or using the CMS anonymous submission
>>>>>>> This then is effectively RTC since a committer must first reviews
>>>>>>> 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
>>>>>>> approved as a "release blocker" on the dev list.
>>>>>>> So we could simply adopt a RTC for certain resources at certain
>>>>>>>   For example, Release Notes once a release occurs, are RTC.
>>>>>>> project logos, once approved and published, are RTC.   If we
agree to
>>>>>>> such things there are lightweight ways of reminding ourselves.
>>>>>>> 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
>>> right is
>>>>>>>> restricted e.x. to PMC members or even less. Doing so will
>>> prohibit
>>>>>>>> anybody from making their changes but simply avoid that the
>>> 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
>>>>>>> committer in terms of what they have access to.
>>>>>> I think you misunderstood me.  I agree with the RTC/CTR discussion,
>>>>>> 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.


>>> 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:
For additional commands, e-mail:

View raw message