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

Reduce the 1.7 release feature set a bit?

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 20 Aug 2010 12:29:03 +0200

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.

- Performance improvements branch
  I think these changes are very valuable and need to be reviewed and
  eventually go into trunk. But we could postpone this to 1.8 as well.
  Apparently we don't seem to have the cycles available right now to
  review them thoroughly, since not many people have done so. So why
  add the extra pressure during the current release cycle?

- 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.

- 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.

- atomic revprops
  This is still work-in-progress, and I'm not sure how far we are from
  completing it. The real problem it's trying to solve (race in svnsync)
  can be worked around reliably using file locks to synchronise svnsync
  processes. I think we can leave judgement to danielsh over whether this
  feature is easy enough to get ready for 1.7, or whether any additional
  time spent on it should rather be spent on more release-critical items.

  Should we not fix this for 1.7, the svnbook should be temporarily
  amended to document the problem and the workaround (maybe we should
  already have done so...)

I think all the above are great features, and should eventually be released.
All I'm asking is whether we should try to narrow our focus a bit more in
order to get 1.7 shipped as early as possible (hopefully still this year).
The less features we have to test and review, the faster we can release.

Obviously, I myself cannot make binding decisions over any of these items,
so please share your thoughts.

Some random notes on other roadmap items while here:

- 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).

- 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
"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 :)

Received on 2010-08-20 12:30:00 CEST

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.