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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
