Hi,
On Dec 21, 2007 2:53 PM, Mark Brouwer <[EMAIL PROTECTED]> wrote:
> No denial here (I think). The proposal mentions the /trunk as the main
> line of development, /maintenance when we are feature ready for a
> release (to provide support for releases) and the /tags for the actual
> releases.
>
> The /branches branch kept for any branch to be found necessary, reasons
> for branching can be many and probably hard to capture under one policy.
> I called it therefore adhoc (dunno whether that is the best word), in
> case there is a possibility to achieve the same result with less
> troubles I'm in for that, if not and we need to branch I would like to
> see that branch in the /branches branch and not being mixed up with the
> /maintenance branch because for that we have a uniform policy.
As Graig already pointed out, that might confuse some people who've
used to /branches being the place to look for maintenance branches.
For consistency with many other Apache projects I'd recommend
something like this:
river/trunk - mainline development
river/branches - maintenance branches
river/tags - frozen release tags
river/sandbox or (river/skunk :-) - development branches
But that's just a naming question, and the River project is free to
choose whatever structure it finds best. We can even start with one
set of names and revisit that decision later on if it turns out that
people are having trouble finding their way around svn.
> BTW as I noticed there was not much participation of others related to
> this subject, do we need to bring this up for an official vote?
Not really. Votes are needed for certain actions (releases, new
committers, etc.) as defined in ASF policies, but otherwise a vote is
typically only needed if there doesn't seem to be any other way to
reach consensus or take action.
I'd be OK if you just went ahead and set up the proposed /tags,
/maintenance, and /branches directories. If we want we can continue
debating which naming or branching strategy is best, but such debates
shouldn't stand in the way of opening the svn for real work.
BR,
Jukka Zitting
