On Mon, Nov 17, 2008 at 9:51 AM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Producing some kind of definition of the remaining tree conflicts work for 1.6
> will help the community understand what's left to do, and more importantly help
> the tree-conflicts folks understand what's left. It may even get a few more
> people involved if there are well-scoped bite-sized tasks available.
>
> Neels, Stefan, Julian, et al: I await your list of what's left. :)
My suggestion from the peanut gallery is:
1) We should await a review of what is 'left' on tree conflicts
2) Ensure ourselves as a community that it is doable within <1 mo of work
3) Branch 1.6.x as soon as we have a list of what remains (but not completed)
4) Begin stabilization of 1.6.x modulo tree conflicts (probably no
releases, but just ensuring dev@ is happy with it)
5) Merge approved backports and whatever is on the list of to-do for
tree conflicts
6) Once tree conflicts is API-stable, begin formal stabilization procedures
My point is really that we begin the stabilization of the rest of the
code as soon as possible, get trunk back to be open (waves bye-bye to
ra_neon *grin*), and merge tree conflicts stuff and start the final
stabilization as soon as it's API-stable.
If the tree conflicts stuff can't be resolved within 1 mo or it takes
longer than that, then we yank the APIs for 1.6.x and it continues
apace for 1.7.x and we release 1.6.x without it. (I'm okay with
shipping dead code if it makes the RM process simpler as long as it
doesn't expose any APIs.)
My $.02. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-17 17:37:35 CET