Re: What stands between us and branching 1.7?

It looks like Philip's list was added to the issue tracker with the
1.7.0 milestone. Nice.

I know CMike has been going through that list and fixing, closing,
moving items. Are all of the items left in the list things that we
definitely want/need for the release? For example, I see a couple of
tree conflict items that I assume no one plans to work on.

Since this list seems to be a good one for knowing what is left to do
before we can branch it would be worth it to remove anything in the
list that we can.

For reference, here is the list:

http://bit.ly/gfDkDC

Mark

On Thu, Jan 6, 2011 at 6:20 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>
>>   What, exactly, stands in the way of us branching for 1.7 stabilization?
>
> Performance, particulary on network disks, is still a concern.  If this
> requires using fewer, bigger transactions then we really want to do that
> before we branch.
>
> The biggest wcng feature that needs work is that revert doesn't really
> work on tree changes.  Some of the recursive reverts go through invalid
> wcng database states before reaching a valid final state (so an
> interrupt would be bad), and some of the non-recursive reverts leave the
> database in an invalid state.
>
> A related issue: we are bad at detecting invalid wcng database states.
> I suppose this could be considered a good thing as it allows the client
> to muddle through in some cases, but if we produced hard errors then
> perhaps we would already have fixed the code that produces invalid
> databases.
>
> There are areas that would benefit from review:
>
>  - Actual-only nodes, i.e. certain types of tree conflicts.  I hacked
>    read_info to get something working, but the API was never really
>    intended for actual-only nodes.
>  - Granularity of transactions
>  - Use of workqueues
>
> There are small issues that need work.  We could fix these after
> branching but obviously it's more efficient to do it before branching:
>
>  - timestamps don't self-repair when no mods are detected
>  - cleanup doesn't fix timestamps
>  - wc-to-wc copy breaks timestamps
>  - revert working not-present
>  - delete a child in a replace needs to reset some database columns
>  - operations like mv/rm on a tree with an actual-only node
>  - upgrade 1.6 wc that contains replaced directory (as produced by merge)
>  - the redirect regression tests fail using serf
>  - XFAILs
>
> --
> Philip
>

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/