Here is the synopsis:
o Existence of release and development branches
in parallel with each other (dev are odd numbered,
release are even numbered).
o Development branches are CTR. If code or patches
to this branch change the API, advanced warning
is required even before the commit. It may be
open to a vote if there is debate. Larger patches,
as well as far-reaching patches should also be
community gauged before implemented.
o Release branches are RTC, with patches obtained
from the development tree. Thus, backports refer
to the SVN revision on the development tree which
adds that feature.
o Both branches have a STATUS file. For the release
branch, STATUS is also used to note backport
proposals.
o Reviews are *always* appropriate. One can call
for a formal review of a patch at any time.
o Voting is via normal ASF rules.
o Regarding large and/or API changing patches, use of
a sandbox is recommended to allow for SVN history to
be maintain, to encourage outside interest and
involvement ("Hey, I'm working on Foo. Here is the
SVN url. Come and help or at least follow along").
This also allows for more complete understanding of
the impacts before it reaches the dev branch.
As previously mentioned, this is simply detailed information
about normal ASF development mechanisms, with some SVN
best practices thrown in to ease the collaborative efforts.
(The numbering in the 1st bullet is not required, of course,
but parallel dev/release branches are key. It ensures that
no code enters release without 2 review phases: the 1st
via CTR in the development branch and the 2nd via RTC
when backported to the release branch).
On Sep 22, 2007, at 1:42 PM, Tim Funk wrote:
Can we have a new VOTE with the six bullets (if it is that many -
I'm losing track with all the responses).
I'm not quite sure what I'm voting for.
-Tim
I'd like to call a vote on acceptance of the above methodology,
as crafted and fine-tuned by Costin and myself. It is worthwhile
to note that, really, these are the typical ASF methods, but
with some "grainy" aspects better defined. In essence, some
typical "niceties" are now mandated (changes, even in CTR, which
affect the API, must be brought up first to gauge community
approval).
[ ] +1. Yes, the above works and addresses my concerns
as well as the problems which started this whole
thing.
[ ] 0. Whatever.
[ ] -1. The above does not work for the following reasons:
The vote will run for 96 hours instead of the normal 72 because of
the weekend. Only binding votes will be counted, but non-binding
votes will be used to address wider concern/acceptance of
the proposal.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
