Ending my RHEL backports support for Subversion

[Nico Kadel-Garcia <nk...@gmail.com>]

I've been publishing backports of Subversion over at github.com  for
RHEL based operating systems for some years now. They used to be
published at RPMForge while that was still active. And it was useful
to me, and to some others, to get up-to-date releases on current or
older operating systems, especially for the long-term RHEL based
systems.

Unfortunately, it's gotten too expensive for me to do. There are
several factors. The big one is the updated requirements with each
major release. Using more recent new technologies, like serf, and
SQLite are understandable upstream changes, but it means integrating
support for them for another set of RPM's for those components, and
building up the support chains for tools like updated serf, multiplies
the work and threatens other stable tools which might use serf. It's
an old issue for many projects, but the return on investment of my
time has pretty much evaporated with RPMforge defunct.

I'm also afraid that the other big  factor, for me, is the
long-missing "obliterate" feature. The lack of any graceful way to
clear inappropriately committed or discarded content has become the
biggest reason *not* to use Subversion, and I can't burn my
engineering time backporting software without a graceful way to clean
up the inevitably bulky or security sensitive bad commit.

Re: Ending my RHEL backports support for Subversion

[Paolo Di Pietro <pd...@diviana.net>]

I'm sad for your leave.

There are a lot of problems in the Sw Eng area, which should be 
addressed to enable people to cooperate without being overkilled.

If we want the Open * to survive, we need to avoid fragmenting the 
efforts, and try to converge them on single 'platforms'.

This is not an easy nor politically correct choice, but, One of this 
should be, IMHO, the choice is between survival or not an entire large 
group of people.

I should like to discuss how to build an 'OTT' approach to let users use 
Subversion, or github, or whatever they like with a standard interface.

As I'm telling from Y2000, we should create ontologies to let the 
content (and not the tools) to cooperate.

I'd like to talk with people about this.

Have a good luck!

Paolo


On 9/18/2016 2:34 PM, Nico Kadel-Garcia wrote:
> I've been publishing backports of Subversion over at github.com  for
> RHEL based operating systems for some years now. They used to be
> published at RPMForge while that was still active. And it was useful
> to me, and to some others, to get up-to-date releases on current or
> older operating systems, especially for the long-term RHEL based
> systems.
>
> Unfortunately, it's gotten too expensive for me to do. There are
> several factors. The big one is the updated requirements with each
> major release. Using more recent new technologies, like serf, and
> SQLite are understandable upstream changes, but it means integrating
> support for them for another set of RPM's for those components, and
> building up the support chains for tools like updated serf, multiplies
> the work and threatens other stable tools which might use serf. It's
> an old issue for many projects, but the return on investment of my
> time has pretty much evaporated with RPMforge defunct.
>
> I'm also afraid that the other big  factor, for me, is the
> long-missing "obliterate" feature. The lack of any graceful way to
> clear inappropriately committed or discarded content has become the
> biggest reason *not* to use Subversion, and I can't burn my
> engineering time backporting software without a graceful way to clean
> up the inevitably bulky or security sensitive bad commit.


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus