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

Finalizing the definition of 1.8.0

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Wed, 15 Aug 2012 12:21:47 -0400

Hello, all.

Echoing in the back of my head are promises we devs have made to avoid long
release cycles, and 1.7.0 recently turned 10 months old. There are a few
ongoing bits of feature work happening on branches or in various states of
completion on the trunk, and I'd really like to avoid 1.8.0 remaining a
moving target for much longer.

Also echoing in my head are recent conversations with some pretty large
Subversion-using corporate community members who are starting to sense that
it's about time for another Subversion release, but have no idea what such a
release might contain or when it will ship. It's the common complaint about
our poor management of outward-bound communication -- a stale roadmap.html
page, no real user-targeting blog or similar info stream, etc.

It's time to make a dedicated push, not so much to release 1.8.0 -- that
would be premature, I sense -- but to at least better define it.

After I send this mail, I'll take a shot at doing some updates to the
Release Status portion of roadmap.html. But in the meantime, allow me to
start the ball rolling with some sound-offs on outstanding
works-in-progress, hopefully so we as a community can ultimately come to an
agreement about which bodies of effort should be aimed at 1.8.0, and which
should be deferred.

=======================================================================

1.8.0 Issues: Per http://goo.gl/uo0CN, there are currently 21
"1.8.0"-milestoned (that is, per our convention, 1.8-blocking) issues. Most
of those are related to...

Serf Stabilization: There's clearly a body of work required here to get
ra_serf up to snuff for service as our sole HTTP communication library.

Conflict Storage: I get the sense that there was energy invested on this
for 1.8, possibly culminating in the trunk changes to defer interactive
conflict handling until the tail end of update/merge operations. Maybe Bert
or Stefan can update this roadmap.html item?

Server-dictated Configuration: See "Inherited Properties".

Inherited Properties: Paul has the basic property inheritence and local
caching mechanism working on his branch, and almost ready to begin
validating his approach by implementing one of our wishlist items (inherited
default ignores, or inherited default auto-props). Paul, Mark and I agree
that we needn't verify that server-dictated configuration is All Good(tm)
before deeming the inherited properties work trunk-worthy, but we also
realize that

Symmetic Merge: Looks like Julian and Paul are sufficiently satisfied with
this feature as to go live in trunk with it. I don't, however, know what
1.8-must-have work remains here.

EditorV2: I have this memory that EditorV2 adoption/migration work sits in
a half-finished state. That shims exist for adapting v1 to v2 and
vice-versa, but that certain bits of the codebase were suffering today
performance-wise or scalability-wise due to the use of those shims. And
there was something interesting about svnrdump, too. But I could be
*completely* misremembering.

Master Passphrase: I have on my branch abstracted the authn storage logic
into a set of private APIs, and then implemented two stores -- one based on
the current ~/.subversion/auth/ config-like code, and a one that uses our
serialized hash format and the new encrypted string support. A
'use-master-passphrase' runtime configuration item dictates which store is
used, and all the extant providers just use the authn store abstraction
layer. I highly doubt that my particular encrypted store implementation
will fly for production code, and my approach in general might not withstand
intense developer scrutiny. But ... that's where things sit today. It
partially because of where this feature sits that I'm intentionally turning
my head towards 1.8.0 -- I value us getting a good release out the door in a
timely matter, and don't want to be the cause of that release slipping.

Those are the things that come to mind immediately. What else?

-- C-Mike

PS: Is it safe to assume that "commit shelving/checkpointing" is *not*
going to happen for 1.8? ;-)

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Enterprise Cloud Development

Received on 2012-08-15 18:22:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.