On Thu, Aug 4, 2011 at 10:52 PM, C. Michael Pilato <cmpilato_at_collab.net>wrote:
> On 08/04/2011 09:47 PM, Blair Zajac wrote:
> > On the veto issue, it's odd that Greg is veto a revert of a commit change
> > that originally occurred on trunk and is now sitting on the branch. It
> > does seem odd one can veto the move back to the original default
> > implementation.
> >
> > Just wondering, couldn't we veto the commit that made serf the default?
>
> Eh... sounds like politickin'... let's not go there, please.
>
> The Subversion committers have consistently demonstrated a keen ability
> (and
> desire) to work out our differences quickly and without even resorting to
> something as formal as a vote. I mean, I can count on one hand the number
> of such votes ... maybe on one finger, even! I'm not even quite sure that
> a
> call for vote in this situation was really necessary, as we already have a
> mechanism in place for addressing the technical question before us (the
> 1.7.x/STATUS voting system). To the degree that we can avoid resorting to
> mere rule-by-the-majority and continue working toward peaceful consensus,
> the greater Subversion community benefits.
>
FWIW, I tried to be clear that my intent was simply for us to take the
temperature of this issue so we can all see where each other currently
stands on the issue. While Greg has placed a veto in STATUS there may be
others that agree with him and are not coming forward because they think he
is handling it. I just want to know how close we are to a consensus.
Every time we have tried to do this in the past, and sadly it has happened
again on this thread, it just winds up being side tracked into this back and
forth that is not getting us any closer to consensus or a decision.
I can really go either way on this issue. I believe the vast majority of
our users use binaries built by someone else. I believe most people that
produce those binaries are going to make Neon the default regardless of what
we decide as a community. Maybe that is the best of both worlds? Most
users will not be impacted and we will still get some bug reports so we can
make Serf better. That said, I do find it odd that we would even consider
making Serf the default at this stage in our project's lifecycle. We are so
conservative about everything else we do, why are we now willing to make a
change that we know has bugs just so that we can accelerate the reporting of
those bugs,
Finally, I also question the notion that Serf is somehow "modern" and the
"future" for this project. When Serf was proposed many years ago I was
pretty excited by the ideas and the improvements it could bring. On paper,
I still think those ideas all make sense, But we have had working code now
for a very long time and it is clear those ideas do not bring the benefits
that they did on paper. In the end, I care about those benefits. I want
Subversion to be faster and faster. I do not see us getting there with Serf
in its current form. Perhaps if ra_serf was changed to work like ra_neon
when it comes to checkout/update I would feel differently. This seems like
it would give us the same performance as Neon without adding the DOS,
slowness and memory usage of Serf. There are still other parts of ra_serf
that would benefit from the modern architecture. For example, merge seems
to be faster with Serf and there may be other commands like status and log
that we have not tested as much as checkout/update/commit that are also
faster. To me, this is the core of the issue. Greg and Justin seem to
still be clinging to the notion that Serf's approach is better but we have
working code that shows it isn't. Ivan proposed tackling this issue and was
shot down immediately. If we want Serf to be the default than acknowledge
this does not work and take a new approach that does.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-05 15:35:55 CEST