Rob Weir 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,
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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
