Thorsten Scherler wrote:
http://lenya.zones.apache.org/docu/guidelines.html
"# Committers add an entry for each significant contribution to the
top-level changes document (site-author/status.xml) and detailed entries
to the relevant plugin's changes document. This enables linkage to the
relevant issue and shows the contributor's name. It also shows the
initials of the committer who did the work to add the patch.
# When committers are adding their own work, they similarly add entries
to the "changes" documents. Their initials are added to the entry."
does not reflect our usage. instead we write prescriptive svn log
entries which are collected into changes.html as described at
http://lenya.apache.org/community/website-update.html#Generating+changes.html
good and bad examples can be found at http://lenya.apache.org/changes.html
> * Define our policy for adding changes to release branch.
i would suggest review-then-commit (RTC) for the maintenance branch, and
commit-then-review for trunk.
> * Define the purpose of the "sandbox".
good point. currently it is a bit a dumping ground:
http://svn.apache.org/repos/asf/lenya/sandbox/
things should not go to the sandbox to die. it is a temporary place. we
need to make a decision whether things like mod_lenya are supported (and
should move out of the sandbox) or should be retired.
>* Declare that we only really maintain the current release branch
> (although contributed patches will be applied).
as opposed to what?
>* When to create a temporary branch for development and when/how to
> merge.
i don't think it makes sense to have a policy for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
