Re: Finalizing the definition of 1.8.0

On 15.08.2012 18:21, C. Michael Pilato 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.
>
> 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? ;-)
>

Hello,

I hope you dont mind a short feedback from a commercial svn supporter regarding some issues customers would love to have
fixed:

These issue have been already fixed on trunk, but please assure that they really go live with 1.8:

3401, always block revision-fixed externals from commit
2487, mod_dav_svn and locales fail to play nicely together

This issue has not been fixed yet:

3457, 3750 : WT proxy locking

regards

-- 
Walter Klust, Director Support, elego Software Solutions GmbH