> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: vrijdag 20 augustus 2010 3:29
> To: dev_at_subversion.apache.org
> Subject: Reduce the 1.7 release feature set a bit?
>
> I think that the recent NODE_DATA developments in wc-ng show that wc-ng
> is still in flux, or at least a bit further from stabilisation than we'd
> like it to be. That's fine! I'd much rather see us release a great working
> copy library than get the release out 3 months earlier. Our new focus on
> enterprise users doesn't demand the 6-month release cycle we once
> decided upon (and subsequently never carried out). Extra cycles spent
> on wc-ng won't hurt our users even if it means delaying 1.7 for a couple
> of months. A few enterprise users I've met are still on 1.4 (yes,
really...
> send praises to Debian etch).
>
> Nevertheless, we'll need to get to a point where we can start focussing
> on stabilisation, to avoid a 1.5-like release debacle (if it's not
already\
> happening :) I think it would benefit the project a lot if anyone not
> involved in wc-ng focused solely on fixing release-critical issues from
> now on. We'll need to draw that line in the sand at some point, and we
> might as well draw it now.
>
> Looking over s.a.o/roadmap.html, I see a couple of things scheduled
> which don't seem to be strictly necessary in order to give our users
> a stable and functional Subversion 1.7 release that contains an awful
> lot of improvements over 1.6. I think that dropping all or any of these
> items from the roadmap would allow us to release 1.7 sooner, without much
> harm.
>
> - Conflict storage
> Do we really need to have this ready for 1.7? We might as well keep
> using the 1.6-style of "recording" conflict information in temporary
> files, that act as conflict markers. At the very least, doing so would
> not be a regression over 1.6, and it can be improved upon during the
> 1.8 cycle.
> As an aside, I'd like to make "svn patch" record conflict markers
> for rejected hunks for 1.7 if possible, and the implementation of
> that depends on this roadmap item. If we decide to postpone a better
> conflict store to 1.8, then I can make "svn patch" and other subcommands
> treat the presence of .svnpatch.rej files as a conflict marker.
> The sooner we can make a decision on this, the better.
I think we need some parts of this to compensate for the new
obstructed/missing handling. You can have a different unversioned directory
in place where a versioned directory should be. And update can't record that
as a conflict using just the old information.
One of the reasons that this isn't handled, is that this upgrade can't be
handled atomicly before we move to single-db. (Tree conflicts would move
from the parent to the child DBs, while we only upgrade them at once. So any
error while upgrading would break your conflict storage)
> - svnrdump
> It's marked as complete, but I don't really know yet if we can consider
it
> complete yet. I plan to review it thoroughly again in its current state
> before deciding whether or not I'd like to see it in 1.7. In particular,
> the current test coverage seems quite poor, and I'm afraid of that
hiding
> potential problems.
> However, if anyone already has reviewed its current state and has found
> it to be of releasable quality, please let us know. But if noone has the
> cycles available to review it thoroughly, and in particular to improve
> test coverage, I'd say we should postpone it to 1.8.
I think the dump part is stable.
The load part needs more testing, but if it could load the ASF repository
I'm happy to ship it as is and fix possible bugs later. (But I don't expect
that this will complete now)
> - file externals improvements
> Are file externals usable at all right now or are they even more broken
> than they were in 1.6? If they aren't more broken, could we postpone
> fixing them to 1.8?
> At least, we should ship the feature in a state that matches the 1.6
state.
> It's not a killer feature that many people rely on, so I don't think
> 1.7 should definitely wait for improvements in this area.
The problem here is that we never documented how it worked in 1.6. It worked
as a hack in 1.6 and as a slightly different hack now. Issues are
continuously noted and more hacks are added to fix specific use cases.
I'm -0 on fixing any more specific use cases until we have a proper design
to support these file externals/internals/hacks. (I don't want to see 2
additional if statements added to every function in libsvn_wc and
libsvn_client, just because we never designed this feature)
<snip>
> - svn patch
> I'd like to really almost-feature-freeze this now (the last feature
> freeze was before danna's Gsoc). The only feature I'd still like to
> add is conflict recording (an exception dannas and I had in mind during
> the pre-gsoc freeze, too).
Doesn't this require the new conflict store mentioned before?
>
> - libsvn_ra_serf stabilization
> I consider this one very release critical, because HTTPv2 depends on it.
> It would be a shame to not ship HTTPv2, which is basically done, because
> of bugs in ra_serf/serf. In particular, the random crashes on checkout
> which seem to be due to bugs in memory handling need to be fixed
> (Stephen
> Butler could reproduce this problem on his Mac, by the way, so it's not
> just me): http://subversion.tigris.org/issues/show_bug.cgi?id=3684
> I have not heard from anybody about fixing serf problems in spite of
> having reported them, and some irregular poking. Can someone involved in
> ra_serf/serf please let us know if there are plans to address these
> problems during the current cycle, and whether additional resources
> are needed to fix problems? I'd expect that, by now, serf should have
> been ready to become the default, but it's sad that it still isn't
> ready for that. If these problems remain, I will vote for shipping 1.7
> defaulting to neon, which means dropping client-side support for HTTPv2.
> It's simply not usable if it crashes dereferencing a NULL pointer coming
> from malloc(), with 512MB of memory available to it. ra_neon uses about
> ten times less memory (rough estimate from human memory, YMMV).
>
> If anyone has the time to look through the list of issues with 1.7
milestone
> and point out a few that may not really be release critical, I would
appreciate
> that a lot.
>
> One release-critical issue that comes to mind is
> http://subversion.tigris.org/issues/show_bug.cgi?id=3620
> "svn add ^/ triggers assertion failure". There are still a couple of
> subcommands which haven't been checked, and might run into assertions
> when given invalid user input. I've slowly been working through this
issue.
> I'm currently at "svn merge", and I have a patch for it but have not
> committed it yet. Any help with subcommands coming after "merge" in the
> output of "svn help" is appreciated.
>
> Enough ranting :)
>
> Thanks,
> Stefan
Received on 2010-08-20 20:56:22 CEST