On Wed, Aug 15, 2012 at 12:21 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > 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.
I believe that the work is sufficiently protected on trunk as to be releasable. There is certainly more that could be done, but my energies are elsewhere at the moment, and I don't know who else is involved. > 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 <cmpil...@collab.net> > CollabNet <> www.collab.net <> Enterprise Cloud Development >
