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
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 12:30:00 CEST