Bug 594481

Adding robmv to Cc. Robert, this is essentially aspiring to replace your trilead-ssh2. I would be glad if you took over this; would you mind obsoleting trilead-ssh2 once this is in and maintaining this instead?

Being a drop-in replacement of trilead-ssh2 in the package is just a matter of flipping a bcond in the spec file of this.

I will glad take it, but something must be decided before having another package. Ganymed was moved to Trilead, then Trilead droped the project, and the original author returned with http://www.cleondris.ch/opensource/ssh2/ now since akurtakov is doing a better job maintaining svnkit than me, I have not touched much this package until people decide which one will be the most used version:

repoquery --whatrequires ganymed-ssh2

maven-wagon-0:1.0-0.2.b2.7.fc12.noarch
eclipse-slide-0:1.3.14-2.fc12.noarch
eclipse-slide-0:1.3.13-2.fc12.noarch

and

repoquery --whatrequires trilead-ssh2

svnkit-0:1.3.0-1.fc12.noarch
trilead-ssh2-javadoc-0:213-6.fc12.x86_64

and now we will have a third fork? we must decide which one to use and patch other packages to use it. This is the first time I hear about orion-ssh2 (as I told I have not touched svnkit recently, akurtakov is virtually the package owner, probably we should switch ownership) adding CC to akurtakov

It looks that svnkit already migrated to orion-ssh2

Robert, 
How did you get the idea that svnkit migrated to orion-ssh2?
If we are sure that orion-ssh2 is what svnkit will use I'm all in favour of deprecating trilead-ssh2. 
TBH, I've never liked all this ssh libraries. They are all pretty much dead.

(In reply to comment #2)
> and now we will have a third fork? we must decide which one to use and patch
> other packages to use it. This is the first time I hear about orion-ssh2 (as I
> told I have not touched svnkit recently, akurtakov is virtually the package
> owner, probably we should switch ownership) adding CC to akurtakov

orion-ssh2 is more of a merger of trilead-ssh2 forks, than another fork (since many of them were created as trilead-ssh2 development ceased).

Lubomir, 
Please drop this gcj parts, it's not nice to sneak gcj in when I just want
svnkit.

Robert, 
Can you dedicate some time to make svnkit work with orion-ssh2 and making
upstream svnkit use it. Oh and if you can update svnkit to the latest verstion
:)
Sorry but I won't be able to dedicate any time for it soon.

Lubomir, Have you tried getting http://www.cleondris.ch/contact/ to join your work?

(In reply to comment #3)
> Robert, 
> How did you get the idea that svnkit migrated to orion-ssh2?

I read http://orion-ssh2.sourceforge.net/ but now that I check more carefully that page say

"Who uses Orion SSH2 code 
...
*  SVNKit 
    Subversion client library uses Trilead SSH2"

so it is a guess that SVNKit plans to use it, I remember the first time I wrote on the SVNKit mailing list about the dead of trilead-ssh2 that someone told me that if needed they will host it

http://old.nabble.com/ganymed|trilead-ssh2-status-td23549604.html#a23549604

(In reply to comment #6)
> Lubomir, Have you tried getting http://www.cleondris.ch/contact/ to join your
> work?    

Nope. orion-ssh2 is not my project, I merely helped ajmas to do a release and merge known forks into it. At the time, both trilead-ssh2 and ganymed-ssh2 were unmaintained, so I did not bother letting them know.

Moreover, ganymed-ssh2 does not seem compatible with trilead-ssh2; at the very least they use a different name space. Purpose of orion-ssh2 is to pick up the work where trilead stopped, put and end to dozens of random trilead-ssh2 forks that came to an existence.

(In reply to comment #7)
> ... it is a guess that SVNKit plans to use it, I remember the first time I wrote
> on the SVNKit mailing list about the dead of trilead-ssh2 that someone told me
> that if needed they will host it

That list merely enumerates software that uses trilead-ssh2's private forks or was in danger of doing so. Plan is to give those projects a chance to migrate to a community maintained code base so that their contributions don't get lost.

(In reply to comment #5)
> Robert, 
> Can you dedicate some time to make svnkit work with orion-ssh2 and making
> upstream svnkit use it.

I will to that. If I recall correctly, the only change was a single added method and one with the same functionality went in via another merger of another fork, thus getting svnkit to use it is utterly trivial.

(In reply to comment #5)
> Lubomir, 
> Please drop this gcj parts, it's not nice to sneak gcj in when I just want
> svnkit.

I will do that only if Robert agrees, I based this on his package, I wish that he maintained this, and will not remove functionality without his consent (despite none of the my packages that are meant to use orion-ssh2 use those). Robert?

> 
> Moreover, ganymed-ssh2 does not seem compatible with trilead-ssh2; at the very
> least they use a different name space. Purpose of orion-ssh2 is to pick up the
> work where trilead stopped, put and end to dozens of random trilead-ssh2 forks
> that came to an existence.

there is a reason for that, ganymed-ssh2 is the original implementation and trilead-ssh2 was the first to change package names, as I mentioned there are still old packages that depends on the original implementation.

> (In reply to comment #5)
> > Robert, 
> > Can you dedicate some time to make svnkit work with orion-ssh2 and making
> > upstream svnkit use it.
> 
> I will to that. If I recall correctly, the only change was a single added
> method and one with the same functionality went in via another merger of
> another fork, thus getting svnkit to use it is utterly trivial.
> 

I sent an email to Christian Plattner (ganymed-ssh2 author) telling about this bug report, we should give him the opportunity to know about orion-ssh2 and maybe join it or orion-ssh2 people to join the original codebase project

> (In reply to comment #5)
> > Lubomir, 
> > Please drop this gcj parts, it's not nice to sneak gcj in when I just want
> > svnkit.
> 
> I will do that only if Robert agrees, I based this on his package, I wish that
> he maintained this, and will not remove functionality without his consent
> (despite none of the my packages that are meant to use orion-ssh2 use those).
> Robert?    

No problem for me, I always maintained gcj bits thinking in PowerPC users, but now that PowerPC is not a primary target platform, and OpenJDK zero assembler JIT are maturing we think we can remove the GCJ dependency

Robert, thanks for pointing me to this issue.

Regarding the trilead release: yes, looking back it was a bad idea to rename the library (and the contained namespaces). It only lead to confusion. When I left Trilead, of course nobody wanted to maintain it anymore.

I recently published a new release on http://www.cleondris.ch/ssh2 using the old namespace (the one that still many people use), this release has the all features of the trilead version and more. This is the one I will maintain in the future. Note: it is fully backwards compatible to the first release of ganymed-ssh2! 

Regarding Orion: I do not like it, they never contacted me or Trilead, their additions are simple and think they do not give proper credit. Of course, just my opinion.

I will happily add any feature to the ganymed-ssh2 code base (including those fixes that went into orion) to ease your packaging, but you have to decide which one you will use.

Cheers,
 Christian

Well, firstly -- are we sure that a package review request is exactly the best place to discuss this?

(In reply to comment #10)
> Regarding the trilead release: yes, looking back it was a bad idea to rename
> the library (and the contained namespaces). It only lead to confusion.

Lightly put -- renaming namespace is not the best idea, doing it twice after most users moved to the new namespace deliberately breaking compatibility is downright stupid.

> Regarding Orion: I do not like it, they never contacted me or Trilead, their
> additions are simple and think they do not give proper credit.

I believe noone contained either trilead or ganymed because both parties demonstrated their uninterest in the code base. I have not learned about regained interest in ganymed until after we've got involved in orion-ssh2 to get the project back to life. It's fine that you don't like our efforts, but you're to blame for the mess and all the private forks of ssh2, not us.

I find it unfair that you accuse us of not giving a proper credit. We've taken the trilead code base as it was; basically only change we did was changing the project name in README, which was because Trilead is a trade mark and to avoid confusion.

Moreover, we've carefully preserved every single bit of authorship information about the code we pulled in from third parties in GIT and documented it in license file. Could we do more?

> Of course, just
> my opinion.

It matters here, I guess.

> I will happily add any feature to the ganymed-ssh2 code base (including those
> fixes that went into orion) to ease your packaging, but you have to decide
> which one you will use.

Well, I strongly prefer the idea of having just a single code base if possible. Therefore, if newly respawned ganymed-ssh2 proves viable (at the very least by having  IntelliJ IDEA, Hudson and DSSH switched to it), I'm happily going to loose interest in orion-ssh2 and will withdraw this review request:

PS: If you're going to pull from us, please do so from GIT, where commit metadata is preserved, unlike from SVN: https://sourceforge.net/scm/?type=git&group_id=273755

Thank you in advance

(In reply to comment #11)
> I believe noone contained either trilead or ganymed

s/contained/contacted/ ...

Namespaces were renamed only once, namely for the Trilead fork. The latest ganymed-ssh2 release is no fork and no re-brand, it is the direct continuation of the original ETH release (check the official homepage at ETH, http://www.ganymed.ethz.ch/ssh2, it points users to http://www.cleondris.ch/ssh2 and nowhere else).

I am certainly not to be hold responsible for any private fork of the code base. Everybody is, of course, free to do so. IntelliJ IDEA, Hudson and DSSH all have their proper reasons to use a private fork (btw: unfortunately, they never came up with a feature request).

I just downloaded the latest orion-ssh2 release "214" from Sourceforge. However, according to the included README.txt, this is supposed to be "213". According to the LICENCE.txt, this code includes improvements from third parties. Looking at the HISTORY.txt, no such features/fixes are listed - not surprising, since this seems to be the unchanged HISTORY.txt from some Trilead release. Who is making a mess here?

Again, if there is any crucial feature missing in ganymed-ssh2 that is needed by some package in the Redhat tree then I will happily add it to the stable ganymed-ssh2 code base.

Hi Christian,
I want to express my personal opinion on this issue.

(In reply to comment #13)
> I am certainly not to be hold responsible for any private fork of the code
> base. Everybody is, of course, free to do so. IntelliJ IDEA, Hudson and DSSH
> all have their proper reasons to use a private fork (btw: unfortunately, they
> never came up with a feature request).
The natural workflow for a OSS developer is:
1. find an issue in some project
2. checkout latest codebase to see whether it is not fixed
3. fix the problem for the latest codebase
4. send patch to the projects issue tracker (bugzilla, jira, mantis, whatever)

Note that steps 2-4 are not possible for ganymed-ssh2. I know we can contact you in person and we have done that but I have to admit that these are things that will make a lot of people not consider it an opensource project resulting in them not trying to submit a feature request or patch. 
Please tell me if I'm wrong and I didn't managed to found these things on the site.

> 
> Again, if there is any crucial feature missing in ganymed-ssh2 that is needed
> by some package in the Redhat tree then I will happily add it to the stable
> ganymed-ssh2 code base.    
As a packager I can show several things that are present in orion and missing in ganymed:
* a source only tarballs - saves us the work to remove binaries from it
* build files - saves us the work to compile manually
* pom.xml file - saves us the work to come with our own for maven integration

Don't take this as bashing ganymed I respect your work as the original author but the guys from orion has done the integration work to make trilead suitable and easy to use for bigger audience.
In short everyone will win if you guys manage to join your efforts in one really opensource project.

Wondering if anyone could review this...
For the record, svnkit builds against this just fine.

I suppose Michal will do it because he took the bug.

This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.