You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by janI <ja...@apache.org> on 2013/07/24 18:03:18 UTC
[DISCUSS] added security to avoid changes in artifacts.
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.
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.
thoughts ?
rgds
jan I.
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Jul 25, 2013 at 1:17 PM, Marcus (OOo) <ma...@wtnet.de> wrote:
> Am 07/25/2013 08:47 PM, schrieb Rob Weir:
>
> On Thu, Jul 25, 2013 at 2:21 PM, Kay Schenk<ka...@gmail.com> wrote:
>>
>>> On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher<da...@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<ja...@apache.org> wrote:
>>>>>>
>>>>>>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
>>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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<de...@openoffice.apache.org>
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
Success is falling nine times and getting up ten."
-- Jon Bon Jovi
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/25/2013 08:47 PM, schrieb Rob Weir:
> On Thu, Jul 25, 2013 at 2:21 PM, Kay Schenk<ka...@gmail.com> wrote:
>> On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher<da...@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<ja...@apache.org> wrote:
>>>>>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
>>>>>>
>>>>>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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
>>> 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
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Rob Weir <ro...@apache.org>.
On Thu, Jul 25, 2013 at 2:21 PM, Kay Schenk <ka...@gmail.com> wrote:
> On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher <da...@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<ja...@apache.org> wrote:
>> >>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
>> >>>
>> >>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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-unsubscribe@openoffice.apache.org
>> > For additional commands, e-mail: dev-help@openoffice.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
>
>
> --
> -------------------------------------------------------------------------------------------------
> MzK
>
> Success is falling nine times and getting up ten."
> -- Jon Bon Jovi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Kay Schenk <ka...@gmail.com>.
On Wed, Jul 24, 2013 at 12:27 PM, Dave Fisher <da...@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<ja...@apache.org> wrote:
> >>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
> >>>
> >>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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.
> 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
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
-------------------------------------------------------------------------------------------------
MzK
Success is falling nine times and getting up ten."
-- Jon Bon Jovi
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Dave Fisher <da...@comcast.net>.
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<ja...@apache.org> wrote:
>>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
>>>
>>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 07/24/2013 07:07 PM, schrieb Rob Weir:
> On Wed, Jul 24, 2013 at 1:00 PM, janI<ja...@apache.org> wrote:
>> On 24 July 2013 18:34, Rob Weir<ro...@apache.org> wrote:
>>
>>> On Wed, Jul 24, 2013 at 12:03 PM, janI<ja...@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.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jul 24, 2013 at 1:00 PM, janI <ja...@apache.org> wrote:
> On 24 July 2013 18:34, Rob Weir <ro...@apache.org> wrote:
>
>> On Wed, Jul 24, 2013 at 12:03 PM, janI <ja...@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-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by janI <ja...@apache.org>.
On 24 July 2013 18:34, Rob Weir <ro...@apache.org> wrote:
> On Wed, Jul 24, 2013 at 12:03 PM, janI <ja...@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.
rgds
jan I.
>
> Regards,
>
> -Rob
>
>
> > thoughts ?
> >
> > rgds
> > jan I.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by "Keith N. McKenna" <ke...@comcast.net>.
Rob Weir wrote:
> On Wed, Jul 24, 2013 at 12:03 PM, janI <ja...@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,
>
For the Release Notes I believe that this would make sense. Restricting
access while the notes are being drafted would deprive individuals who
may not be technically oriented to contribute in a meaningful way to the
project. However once a Release occurs they should be frozen except for
things lake a re-spin for new languages, new issues for which a work
around exists that needs to be communicated, etc.
There was an extensive discussion of this in an earlier
thread;http://markmail.org/message/zub3ovqoi3zvoxst?q=Where+to+keep+release+notes%3F&page=3.
One of the suggestions floated was to move the Release notes to the
developer cwiki that is write restricted to committers, but can be read
by anyone. This would appear to be a viable alternative at least for
items lke Release Notes that need to be tied to a particular release,
but also have the potential to change without a new release.
Another possibility that could be used is the setting of restrictions on
pages of the cwiki. A quick review of the help show that a Space
Admnistrator can define set up a structure for a limited number of
people to be able to set view or edit restrictions on a page that will
be inherited by all child pages as well. This scenario would work well
for the Release Notes. Once the release occurs the Notes are edit
restricted to a defined group that can edit them if necessary.
Regards
Keith
>
>> 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.
>
> Regards,
>
> -Rob
>
>
>> thoughts ?
>>
>> rgds
>> jan I.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [DISCUSS] added security to avoid changes in artifacts.
Posted by Rob Weir <ro...@apache.org>.
On Wed, Jul 24, 2013 at 12:03 PM, janI <ja...@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.
Regards,
-Rob
> thoughts ?
>
> rgds
> jan I.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org