Re: What's blocking the 1.8 branch?

--
Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
----- Original Message -----
> From: C. Michael Pilato <cmpilato_at_collab.net>
> To: Subversion Development <dev_at_subversion.apache.org>
> Cc: 
> Sent: Wednesday, 13 March 2013, 9:23
> Subject: What's blocking the 1.8 branch?
> 
> Hey, all.  The CollabNetters were talking today about the status of our
> codebase, and were trying to enumerate the things which are blocking the
> 1.8.x branch.
> 
> * Though we've not seen anything explicitly stating as much, we had the
> sense (per his toggling of the task's status on roadmap.html to 
> "completed")
> that Philip has taken the rename work to a place where he's comfortable
> branching.
> 
> * svn_node_kind_t and svn_kind_t -- Brane has been working to eliminate that
> bit of confusion (which, as an API matter, certainly counts as a release
> blocker).
> 
> * There's some discussion ongoing about svn_client_move7()'s API flags.
> This needs resolution before releasing, too.
> 
> Those are the things we could come up with.  Obviously there will be
> numerous bug fixes and performance enhancements and such made to the
> codebase between now and the release itself.  Paul and Julian are debating
> something merge-related; Bert commits a minimum of 241 bug fixes per day;
> etc.  But does anyone know of other release-branch-blocking activities?
For issue #4316 'Merge errors out after resolving conflicts', I am about to make a change to the way 'merge' invokes the conflict resolver callback.  This would probably be better done before branching, as it affects APIs although it might not change any API signatures; but I suppose it is not a hard blocker.
I have a concern about inconsistency of the flags available to some 'update' and 'switch' APIs which, as a potential API change, would be better resolved before branching, but again is not a hard blocker.
There are currently ten open issues marked '1.8.0', including some of the ones mentioned above.  I suppose we don't necessarily need to fix such issues before branching?  Maybe some of them should be demoted to '1.8-consider'?
- Julian