[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Lose users? -- was: Re: Update on my previous tree conflict scenario

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Mon, 17 Nov 2008 18:45:52 +0000

On Mon, 2008-11-17 at 10:37 -0600, Justin Erenkrantz wrote:
> 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

See new thread "Tree conflicts - What's To Do".

I need help to turn a list of issues into a plan. Anybody?

One thing we should do to organise the list is enter the TODO-1.6 items
into the issue tracker (with "1.6" target milestone) and the mailing
list items (with "1.6-consider") so they're all in one place.

- Julian

> 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


- Julian

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 19:46:20 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.