El jue, 11-05-2006 a las 20:05 -0400, Gregor J. Rothfuss escribió: > 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
Yes, we need to change this. I will be away for a week and cannot change this until the 22nd. I will do it then if no one beats me to it. > > > * 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. Makes sense. > > > * 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. Agree. I started e.g. the doco pub there since code and community wise it is not yet support by the lenya or forrest community. Thus code need to get first attention from the community and more people playing with the code. Things in the sandbox need to stabilize and win community support to be then official and supported part of the lenya project. I see the sandbox like a lenya specific incubator. We may want to apply similar guidelines like in the incubator for projects in the sandbox. > > >* Declare that we only really maintain the current release branch > > (although contributed patches will be applied). > > as opposed to what? To support former versions like maintaining the 1.2.2 branch. When patches for this are coming in and we have reviewed them, then we would apply them but no one will focus her energies on providing back-ports. > > >* 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. This one has a little history on forrest. The lenya project does not actively use branching for incorporating new functionality into the core. Forrest has the policy of a stable trunk, meaning the trunk should be always be buildable and working. In the current dev version of forrest we are using the locationmap. The activation of the locationmap have been done in a branch. The policy which resulted was that one should use a new branch if one incorporates new features (or refactors code) that could break the trunk. The benefit of having modules or plugins is that one can capsulize code that have the potential to break the trunk. For example modules that have this potential can be developed in the sandbox. Having said this, this policy makes sense if we as well want the stable trunk policy. salu2 -- thorsten "Together we stand, divided we fall!" Hey you (Pink Floyd) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
