On 22.11.2017 11:53, Julian Foad wrote:
> At the hackathon today we (me, Stefan Hett, Bert, Johan) have been
> talking about how to progress 1.10.
>
> We think all the features and changes are safe to release and are not
> going to get more testing until we produce a "release candidate". (For
> example, at that point Stefan will be able to justify taking time at
> his work to test the client in production scenarios.)
My idea for the hackathon was to add native 'svn list' support
to ra_serf. But that is not a release blocker.
>
> * conflict resolution: we understand it is already much better than
> 1.9; low risk if parts of it don't work quite right; designed so that
> improvements can be made in patch releases.
If we broke something, it is likely one of the more complicated
cases where the need for manual intervention is not all that
surprising to the user.
>
> * LZ4 compression: in some senses the risk of bugs here is higher,
> but it seems like it is high quality already; is there one remaining
> place where we should add LZ4 negotiation (one direction of svnserve
> protocol)?
ra_svn is certainly the ra layer that may benefit the most from LZ4.
Browsing through the code, I found a couple of TODOs that should
be simple to address this week.
I've got some ideas to enhance the protocol in 1.11 and that would
include using LZ4 for "mod_compress"-like full protocol compression.
However, those are non-trivial and are the one thing I like to discuss
with the people at the hackathon.
>
> * shelving v1: is isolated -- doesn't affect anything else; is
> limited but already useful; will be changed in the next release so
> APIs are marked "SVN_EXPERIMENTAL"; changes shelved by this release
> could be detected and 'upgraded' by a future release; should the CLI
> commands be marked "experimental" in the help, too (Johan thinks yes)?
+1 on letting people gain experience with shelving.
+1 on marking the feature "experimental" in the UI b/c we might not
want to fully commit ourselves to upgradability. That is a departure
from the policy of previous releases.
>
> After any issues raised in this discussion are resolved, we feel we
> should go ahead and produce RC1 as soon as possible.
Assuming no blockers come up, I think coming weekend would be
a reasonable value for $asap.
-- Stefan^2.
Received on 2017-11-22 14:21:43 CET