Re: Subversion's community health
I agree to all you wrote. But the increased speed of releasing new versions with unstable experimental features somehow contradicts the otherwise mature development state. As a user of the JavaHL API we only consider a feature as stable if it is reflected in all binding APIs, too. -- Best regards, Thomas Singer = syntevo GmbH https://www.syntevo.com https://www.syntevo.com/blog On 2019-06-14 16:34, Eric S. Raymond wrote: Julian Foad : 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. You guys know me. I'm a past contributor, occasional critic, often a supporter. I did my best to push back when Linus Torvalds accused this crew of incompetence. And I, too, have had the recent experience of watching a project I was hugely invested in - GPSD - slide into a semi-active maintainence mode. The main piece of advice I have for all of you is that you should keep your expectations about Subversion's future realistic. The brute fact is that git has taken over the version-control world. It has stomped flat a couple of sttempts to compete with it in DVCS - Mercurial, bzr, monotone. And Subversion is at a massive disdavantage relative to *any* DVCS for reasons that should be too obvious to need repeating. Does Subversion have a future at all? I think the answer is "Yes", but it's not an exciting, sexy future. You guys have only two selling points I can see for new installations (1) Subversion's UI is *massively* simpler than git's, and (2) some customers have political/cultural reasons to prefer a centralized VCS with repositories that can't be easily cloned. I think that's enough for survival. But it's not exciting, not sexy, and not a recipe for drawing in new development talent. Thus, if you try to plan for big things, you will almost certainly fail because you won't be able to collect the investment of developmen time required to realize them. What you *can* hope for is to ship occasional releases of high quality and maintain Subversion's deserved reputation as the best of the pre-DVCS version-control systems. This is what I mean by setting realistic expectations. It means gearing down - accepting that your release tempo is going to be low and your main goal is to keep the issue tracker relatively clean. This is where I am now with GPSD. I had to struggle a bit to accept it, but the truth is GPSD is mature software that doesn't have much of anything left to do in its application domain. In an important way, that is victory. I'll pitch in here myself; I have plans to collect some more information about the semantics of the dump format and add it to the documentation already in the source tree. Because I believe in finishing what I started and leaving behind artifacts that say "Damn, that guy was a pro." You can still have that kind of excellence. It's not a trivial thing.
Re: Subversion's community health
An interesting if slightly sad read. I want to add my support and praise
as a long-time user of Subversion.
I still come across many users out there. Subversion is thriving in one
particular business I work with. The youngsters have brought some Git in
with them but it seems to be led by fashion than anything else.
Subversion remains.
I choose Subversion over all other options for my own personal projects.
I like the simplicity and clarity.
I was recently considering some git-svn monster to allow local branching
on a big Subversion-hosted project but then I discovered the svn
shelving experiments. The checkpointing addition changes everything. I
cannot overstate that. I feel it's important to fully release
shelving/checkpointing and publicise the shift that it brings to working
with Subversion.
Of course, none of this magically brings new developers to the project
but perhaps it will provide motivation.
S.
On 2019/06/14 13:26:41, Julian Foad 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.>
>
> - Julian>
>
>
Re: Docker Svn build environment [was: Subversion's community health]
People wanting to donate a feature or fix a bug with Subversion are increasingly going to be happy with a Docker-based quick start. Most F/OSS teams want tests too, and y'all are very strict there in that regard, and someone who can write tests for your test-base covering code for your codebase is most likely going to be super-OK with Docker. Where that incentivized groups is left with pause for thought is on the consumption of contributions and the schedule for seeing consequential releases. Now, there's another group who want to image machines and shove in "latest released" Subversion. Their problem is downstream maintainers of operating systems for one, and the lack of comprehensive Svn-dev-team install instructions to overcome maintainer choices secondarily. Ubuntu's at 19.04 now, and it's shipping Svn 1.10. The Mac's homebrew is at 1.12 presently, but it is quite often months behind. This group is happy to build from source (if that is reliable) and would use any on-platform or cross-compilation script to target the machine/OS they're interested in. They may not care to edit source. They may even be happy to skip tests - they just want the binaries in situ. How much of the first group would not want to wait for releases, and instead deploy unreleased versions of Subversion? Meaning they've donated a patch, have some assurances that it is being accepted as it meets standards, but don't want to wait any longer before productionizing it to some level?
Re: Docker Svn build environment [was: Subversion's community health]
On Wed, Jun 19, 2019 at 6:36 AM Julian Foad wrote: > Some time within the past year I looked for the best available Docker > deployment of Subversion and found this: > > https://github.com/elleFlorio/svn-docker > "Lightweight Docker image to build a container running an SVN server" > > It might be helpful as a starting point for creating a dev environment. > > This seems like it could be useful for some dev situations and making it easier to run tests but I otherwise do not see the value in it. People on Windows and OSX ultimately want binaries that will run on their OS. On Linux you want something that will work natively on your distro. This will do nothing to assist with that. It would make it easier to throw together a patch and run the tests but ultimately I would expect someone doing this would probably also want to run with their version of the binary they built. By all means, we could create this but we should not make the mistake of believing it solves the main problems. Mark Phippard http://markphip.blogspot.com/
Re: Subversion's community health
Nathan Hartman wrote: All of the above -- being mature, reaching the stability phase, etc -- is true of Subversion 1.x. It is _not_ true of "Subversion" without a 1.x after it. [...] Subversion 1.x is mature. Subversion 2.0 is now on the drawing board. A very good point. [...] Prong 1: Everything you said about stability and availability for 1.x. People need to know that the Subversion they know, love, and rely upon will continue to take care of them. Prong 2: Open up a 2.0-dev branch even if there's nothing to put there yet. In any announcements about 1.x going stable make sure to mention that 2.0 is now open for business. People need to know that there is a future -- and they can help shape it!! That's such a powerful idea, yes! The attitude that we don't have to know what 2.0 will be, but can say "welcome!"... and see where it will lead. Do you want to be the one to start a separate thread about this? - Julian
Re: Docker Svn build environment [was: Subversion's community health]
Some time within the past year I looked for the best available Docker deployment of Subversion and found this: https://github.com/elleFlorio/svn-docker "Lightweight Docker image to build a container running an SVN server" It might be helpful as a starting point for creating a dev environment. - Julian
Re: Subversion's community health
Paul Hammant wrote: Nobody is going to roll up to contribute to 1.x or 2.x Subversion if there is no copy-pasteable instructions for building on Mac, Win and Linux. And there's not - https://svn.apache.org/repos/asf/subversion /trunk/INSTALL - has no apt, nuget or homebrew advice [...] That's a good suggestion for modernizing the 'INSTALL' instructions. My comment from 4 days ago about unconsumed pull requests? Is noted. I agree it is a problem. I will re-open the thread I started in January about that. Dockerized build templates would be great for a quickstart. Moved to "Subject: Docker Svn build environment". - Julian
Docker Svn build environment [was: Subversion's community health]
Paul Hammant wrote: Michael Pilato wrote: Paul Hammant wrote: Nobody is going to roll up to contribute to 1.x or 2.x Subversion if there is no copy-pasteable instructions for building on Mac, Win and Linux. Is there an opportunity here for someone to whip up a Dockerized development environment for Subversion? Volume mapped to local disk for easy editing of source code in your tool of choice, but all the dependencies and such present in the image? Just thinking out loud here... Dockerized build templates would be great for a quickstart. I might have one or two for Svn and if I de-hack them might be shareable. They'd be biased towards Linux for build/test/standup of course, but would be better than nothing. That would be awesome. It could remove the biggest barrier to entry for many developers. Docker is a good choice for this, and I am convinced we'll get the best outcome if we pool our resources into supporting one way well, so count me in. - Julian
Re: Subversion's community health
Dockerized build templates would be great for a quickstart. I might have one or two for Svn and if I de-hack them might be shareable. They'd be biased towards Linux for build/test/standup of course, but would be better than nothing.
Re: Subversion's community health
On 6/18/19 9:50 AM, Paul Hammant wrote: > Nobody is going to roll up to contribute to 1.x or 2.x Subversion if > there is no copy-pasteable instructions for building on Mac, Win and > Linux. And there's not - > https://svn.apache.org/repos/asf/subversion/trunk/INSTALL - has no > apt, nuget or homebrew advice for people wanting to get into > development of Svn. Is there an opportunity here for someone to whip up a Dockerized development environment for Subversion? Volume mapped to local disk for easy editing of source code in your tool of choice, but all the dependencies and such present in the image? Just thinking out loud here...
Re: Subversion's community health
Nobody is going to roll up to contribute to 1.x or 2.x Subversion if there is no copy-pasteable instructions for building on Mac, Win and Linux. And there's not - https://svn.apache.org/repos/asf/subversion/trunk/INSTALL - has no apt, nuget or homebrew advice for people wanting to get into development of Svn. My comment from 4 days ago about unconsumed pull requests? - Paul
Re: Subversion's community health
On Tue, Jun 18, 2019 at 7:00 AM Julian Foad wrote: > Here is my suggestion. > > > Primary goals: > > * Stability > > * Availability All of the above -- being mature, reaching the stability phase, etc -- is true of Subversion 1.x. It is _not_ true of "Subversion" without a 1.x after it. Subversion 2.0 hasn't been born yet. Ironically, now is the time, specifically because stability of 1.x means not introducing huge groundbreaking features. But under no circumstances should such new development be discouraged and turned away!! On the contrary, the Subversion project should encourage it! I believe there _will_ be new development in the future. Partly I believe this because it's on my own to-do list, and I have some big ideas that will _have_ to go in a 2.0 (even if 1.x didn't enter a stability phase). Partly I believe it because Subversion offers some great things that no other tool does. And partly because in my short time on this earth, I've seen entirely too many occasions when something was almost dead and came back stronger than ever, while other things were flying high and mighty and then crashed and burned. The name "Subversion" is actually the perfect name for this project. It's a double entendre. While the technical idea is to control "sub- versions" -- versions between versions -- the word "subversion" means to transform an established social order. I'll say no more. :-) Subversion 1.x is mature. Subversion 2.0 is now on the drawing board. Let's make 1.x as stable and available as possible and let's encourage discussion about 2.0 and all the great things ahead. I recommend a two pronged approach. Prong 1: Everything you said about stability and availability for 1.x. People need to know that the Subversion they know, love, and rely upon will continue to take care of them. Prong 2: Open up a 2.0-dev branch even if there's nothing to put there yet. In any announcements about 1.x going stable make sure to mention that 2.0 is now open for business. People need to know that there is a future -- and they can help shape it!!
Re: Subversion's community health
Here is my suggestion. Primary goals: * Stability - because that's the stage in the project's life cycle - if anyone wants to invest in development, that's fine too, but is not what the current stewards of the project should be concentrating on * Availability - because stability for users (including admins) requires that they can deploy it where they need it, and keep it up to date easily - availability is currently poor -- see "Software Distribution" in https://blog.foad.me.uk/2018/12/07/svn-whats-in-my-head/ For Stability: * encourage commercial engagement for project maintenance * encourage community maintenance by accepting minor feature contributions and experimental initiatives - don't let them compromise stability * seek to remove or hide rough edges in existing features - e.g. hide experimental features behind an opt-in config For Availability: * support availability of up-to-date install packages - including today's cloud/container deployment platforms * improve ease for downstream consumers using our releases - see Mark's response about Subclipse How? * invite companies to contribute their existing build systems - CollabNet, Assembla, RhodeCode, WANdisco * find out what are the main desired target platforms - provide a reference build system for each platform - find and support maintainers for each platform * change our release schedule to focus on maintenance releases - reduce friction in version numbering, compatibility, multiple release lines * improve ease of producing new releases, especially bug fix releases - automate the release steps (aim towards "one click") - reduce friction in backports and releases policies (voting, etc.) -- - Julian
Re: Subversion's community health
Guten Tag Karl Fogel, am Freitag, 14. Juni 2019 um 18:16 schrieben Sie: > I just put out an informal Twitter poll to get a sense of how > people are using Subversion these days: > https://twitter.com/kfogel/status/1139559630059843586 > (Or at least, to get a sense of how Twitter users who happen to see > my tweet are using Subversion these days :-) .) Asking the same here and on the users list might make sense as well. I pretty much have the same use case like you, mostly with deployment to different customers using per-product SVN-repos. authz is simply necessary for us to restrict customers access to only their own tags. Additionally, the usage scenario of SVN better reflects what is needed with my customers: It doesn't make sense to allow them things like local branches to e.g. heavily customize the deployment and they don't even want to do that. Instead, if they change configs or such, that needs to be considered during updates anyway and SVN forces me to do so. That's simply a service to the customers making their life a bit easier. Some of them don't even understand why they should commit simple config changes using a reasonable log message for long term benefit, so run into conflicts because of incompatible local changes from time to time. Those customers wouldn't be able to work any better with e.g. GIT and things like commit vs. push and stuff. Running lots of different GIT-repos per product per-customer wouldn't make my life easier as well. I'm not necessarily such a big fan of local-only-branches possible with GIT for companies as well, because in my opinion, everything employees do should be available to the company mostly. Of course people don't necessarily need to commit using SVN as well, but that's refusing to work in the end. OTOH, for OSS-libs and -apps, Git and GitHub make life a lot easier. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Subversion's community health
On Fri, Jun 14, 2019 at 10:35 AM Eric S. Raymond wrote: > Julian Foad : > > 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. > It's all a matter of publicity. Git gets all the publicity because open source uses Git and open source happens in public. Subversion is applicable to business and other centrally organized entities. Some do their work in public; most don't. Subversion's centralized nature is actually a big strength in those situations -- and while I can go on about its technical superiorities, that's a subject for another thread. The point is that because there is no publicity, you don't see it, and neither do potential users or contributors. To Make Subversion Sexy Again there is a need for visibility and publicity -- Subversion evangelism. It starts with this community changing its thinking TODAY from "we're old and tired" to "we're sexy again." Talk about Subversion. Not just here. Everywhere. With everyone. Raise awareness about the strengths Subversion has today. Talk about Subversion 2.0 and all the wonderful things in it. Yes, even though it doesn't exist yet. Even if the present members of this community won't be the ones implementing it. Talk is cheap, yet it's a powerful thing. Every conversation increases the probability of piquing someone's interests and is a step toward attracting the new blood this community needs.
Re: Subversion's community health
Julian Foad wrote: >Ah, yes -- I didn't mean to discourage anyone from just describing a >problem; that can then help others seek a solution. [...] One thing I wonder is how widely Subversion is in non-published trees, especially corporate trees. For example, my company uses Subversion internally for our entire corporate tree. It has various advantages over Git in that role: the authz controls are such a huge win, you can version directories, you get real copy history, you can update log messages post facto (this has helped us on more than one occasion). While we don't use the path-locking features, some other companies do, presumably because they work with a lot of non-mergable documents. I just put out an informal Twitter poll to get a sense of how people are using Subversion these days: https://twitter.com/kfogel/status/1139559630059843586 (Or at least, to get a sense of how Twitter users who happen to see my tweet are using Subversion these days :-) .) There's nothing wrong with software reaching maturity or even declining in use. Lifecycles happen. On the other hand, there might be untapped willingness out there to support Subversion maintenance and development. It's worth making a bit of effort to find out. Perhaps the model this project depended on for so many years -- a small number of tech companies choosing to pay maintainers as staff -- no longer works well, but some other model would work (e.g, something similar to what Tidelift.com is doing). Best regards, -Karl
Re: Subversion's community health
Three PRs out on GitHub for Subversion spanning years - https://github.com/apache/subversion/pulls ^ "join in" versus "don't join" in is communicated via team welcoming, curating, and consuming of PRs in this age. Sure, Julian's shelve tech is the starting point of a PR system for Subversion itself, but that doesn't mean Svn development can't take advantage of a workflow that millions of devs have adopted today on GitHub. To say no to that *feels like* an arbitrary policy. Towards that in GitHub-land, people dread bug reports remaining unattended. Issues in GH is turned off, of course. They also are put off by incomplete READMEs. Ref https://www.makeareadme.com/ (I have made contribs to that) and a few similar efforts. Lots to say on Svn's README.
Re: Subversion's community health
Julian Foad : > 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. You guys know me. I'm a past contributor, occasional critic, often a supporter. I did my best to push back when Linus Torvalds accused this crew of incompetence. And I, too, have had the recent experience of watching a project I was hugely invested in - GPSD - slide into a semi-active maintainence mode. The main piece of advice I have for all of you is that you should keep your expectations about Subversion's future realistic. The brute fact is that git has taken over the version-control world. It has stomped flat a couple of sttempts to compete with it in DVCS - Mercurial, bzr, monotone. And Subversion is at a massive disdavantage relative to *any* DVCS for reasons that should be too obvious to need repeating. Does Subversion have a future at all? I think the answer is "Yes", but it's not an exciting, sexy future. You guys have only two selling points I can see for new installations (1) Subversion's UI is *massively* simpler than git's, and (2) some customers have political/cultural reasons to prefer a centralized VCS with repositories that can't be easily cloned. I think that's enough for survival. But it's not exciting, not sexy, and not a recipe for drawing in new development talent. Thus, if you try to plan for big things, you will almost certainly fail because you won't be able to collect the investment of developmen time required to realize them. What you *can* hope for is to ship occasional releases of high quality and maintain Subversion's deserved reputation as the best of the pre-DVCS version-control systems. This is what I mean by setting realistic expectations. It means gearing down - accepting that your release tempo is going to be low and your main goal is to keep the issue tracker relatively clean. This is where I am now with GPSD. I had to struggle a bit to accept it, but the truth is GPSD is mature software that doesn't have much of anything left to do in its application domain. In an important way, that is victory. I'll pitch in here myself; I have plans to collect some more information about the semantics of the dump format and add it to the documentation already in the source tree. Because I believe in finishing what I started and leaving behind artifacts that say "Damn, that guy was a pro." You can still have that kind of excellence. It's not a trivial thing. -- http://www.catb.org/~esr/;>Eric S. Raymond
Re: Subversion's community health
Mark Phippard wrote: Making a suggestion here is tough. [...] Ah, yes -- I didn't mean to discourage anyone from just describing a problem; that can then help others seek a solution. Thanks for sharing the problem of building downstream from the frequent releases. - Julian
Re: Subversion's community health
On Fri, Jun 14, 2019 at 9:26 AM Julian Foad 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/
Subversion's community health
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.
- Julian
