On Fri, Jun 14, 2019 at 9:26 AM Julian Foad <julianfoad_at_apache.org> wrote:
> The Subversion community has gradually become much less active. We have
> reached the point where we are struggling to even put out a release.
>
> Johan said I may quote his thoughts, so I will:
> > Indeed, I was just wondering about the same thing, before I read your
> > response, Julian. It's quite clear that things are getting more and
> > more quiet . I feel the project is slowly dying ...
> >
> > Sometimes I try to give an issue a little push by summarizing it on
> > the dev list, or by giving some ideas, but for me that's usually about
> > all I can do (limited time, limited knowledge, ...). I'm not the only
> > one of course. Sometimes, others give a little push as well, and with
> > enough hands some things still get done. But lately, those little
> > pushes seem to become more and more rare.
> >
> > Also: if Julian's funding stops, will we get another release out?
> > Theoretically we can, of course, but will we?
> >
> > I'm not blaming anyone of course. We're all volunteers, time gets
> > consumed by other things, motivations and priorities shift, ... But it
> > makes me a little sad .
> >
> > Can we do something about it? Or is this just the way it is ... a
> > normal project lifecycle of which we've reached the end? It's become
> > old and un-sexy legacy software ... at least in the perception of the
> > masses. Can we revive it, or give it a second life?
> >
> > .oO("Make Subversion sexy again" :-))
>
> Is this a Bad Thing? It is not objectively bad that the development has
> tailed off; that's simply what happens when a project moves on to its
> "mature" stage in its life cycle. But it is causing some problems in
> adapting to the "new normal".
>
> We have reached the point where we are struggling to even put out a
> release because not enough developers are volunteering to do the work
> required. (A release, no matter how minor the changes, currently
> requires reviewing, testing, voting, writing release notes, updating
> other web pages, and so on. Some of the steps are mostly automated but
> others are not.)
>
> So, we might want to look at changing how we do releases. I have some
> other thoughts too. But first, I'd like to invite others to speak up.
>
> Anyone with constructive suggestions, please do share them. Please let
> us not dwell on our sadness and criticism of what went before; let us
> try to keep this thread focused on positive solutions for what to do next.
>
>
Making a suggestion here is tough. I feel like the current release policy
is the only realistic way to encourage contributions to the product because
there are known and predictable release vehicles to deliver those
contributions. That said, those contributions are not coming and the
frequent releases themselves ARE causing pain. You list some of it here.
As maintainer of Subclipse, the releases are an enormous problem for me.
The realities of the JavaHL API and JNI make it very difficult to support
multiple releases. At the Java API level it is all quite easy the problem
is in the delivery and just the details of Subclipse/Eclipse/Java and the
OS and native libraries. I will not go into the details it is just that
this situation creates a lot of bad options to choose from and has made
things difficult to the point where I have to consider if it would not be
better to just abandon the project.
In general, I would rather see us spend more effort supporting the current
release and only ever have another new 1.x release when some significant
new features were fully realized. Even if that means there is never
another new 1.x release.
I am pretty happy with SVN 1.8.x and that is still the only version I run
on servers. If SVN would slow down on new 1.x releases and was going to
just iterate fixes on the current release I might be more inclined to move
to it. But right now, on the server, it is just change for change sake.
There are some fixes but none that are super important to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2019-06-14 15:58:56 CEST