Bug 759319 - Update package to new fork
Update package to new fork
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: gts (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Ralf Corsepius
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-01 19:28 EST by Jonathan Underwood
Modified: 2015-02-17 08:59 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 08:59:35 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Jonathan Underwood 2011-12-01 19:28:05 EST
Description of problem:
The last release from the original upstream at gts.sourceforge.net was 0.76 in 2006, though the changelog there shows changes into 2010.

The gerris project have forked GTS at gfs.sourceforge.net and added to it. Interestingly the link to the source code repository from the original site now points to the gerris repository. So, it seems the gerris fork is now the upstream.

The gerris project release regular snapshots of gerris and gts - the current gerris snapshot requires the current gts snapshot to build.

I'm in the process of putting together packages for submission to Fedora of gerris and gfsview for Fedora and EPEL which would need the gts package updating to the recent snapshot. How do you feel about updating the GTS package in Fedora to track the snapshot releases from the gerris project?

The snapshot tarballs are available here:

http://gfs.sourceforge.net/wiki/index.php/Download

Annoyingly the tarballs do not contain any version info in their name, but I see that the GTS version is still set to 0.7.6. I am unsure of the modifications change ABI, but seem to change API.
Comment 1 Ralf Corsepius 2011-12-02 01:50:52 EST
(In reply to comment #0)
> Description of problem:
> The last release from the original upstream at gts.sourceforge.net was 0.76 in
> 2006, though the changelog there shows changes into 2010.
> 
> The gerris project have forked GTS at gfs.sourceforge.net and added to it.
> Interestingly the link to the source code repository from the original site now
> points to the gerris repository. So, it seems the gerris fork is now the
> upstream.
Yikes ... gts has always been poorly maintained, when it was alive ... but this is worse.
 
> The gerris project release regular snapshots of gerris and gts - the current
> gerris snapshot requires the current gts snapshot to build.
Why? I checked their sources and only found many cosmetical changes, several minor bug-fixes, them having added dpkg related files, _one_ presumable major bug fix and change which probably is a functional addition.

I.e. unless they rely upon this "functional addtion", I don't see why they have to rely upon "their version".

> I'm in the process of putting together packages for submission to Fedora of
> gerris and gfsview for Fedora and EPEL which would need the gts package
> updating to the recent snapshot. How do you feel about updating the GTS package
> in Fedora to track the snapshot releases from the gerris project?

My opinion:
*  It's impossible for a distro to support a project, which applies a rolling release model and doesn't release stable tarballs.

* I consider it to be foul play of a project (here: gerris) and dirty work of this project's maintainers to bundle hacked-up sources of another project (here: gts) - "Hostile take over".
Instead, they should have renamed and reversioned their hacked-up version, which would allow parallel installation or they should formally take over the original project.


> The snapshot tarballs are available here:
> 
> http://gfs.sourceforge.net/wiki/index.php/Download
> 
> Annoyingly the tarballs do not contain any version info in their name,
I see. That's one of my points above.

> but I
> see that the GTS version is still set to 0.7.6. I am unsure of the
> modifications change ABI, but seem to change API.
I'll furtherly check details. ATM, I am inclined to harvest gerris's rolling tarballs and to add the useful parts of it as patches to Fedora's gts, should their works be compatible to the original gts.

Should they not be compatible, this won't work. My advise then would be you to rename their gts and to ship it independently of the original gts.

May-be you could try to contact gerris upstream and try to clarify the situation?
Comment 2 Jonathan Underwood 2011-12-02 06:48:29 EST
Hi Ralf,

(In reply to comment #1)
[snip]

> > The gerris project release regular snapshots of gerris and gts - the current
> > gerris snapshot requires the current gts snapshot to build.
> Why? I checked their sources and only found many cosmetical changes, several
> minor bug-fixes, them having added dpkg related files, _one_ presumable major
> bug fix and change which probably is a functional addition.
> 

Yes - it's the latter which gives rise to the requirement.

[snip]

> My opinion:
> *  It's impossible for a distro to support a project, which applies a rolling
> release model and doesn't release stable tarballs.
> 

Agreed.

> * I consider it to be foul play of a project (here: gerris) and dirty work of
> this project's maintainers to bundle hacked-up sources of another project
> (here: gts) - "Hostile take over".

Well, I don't think it's a hostile takeover in any sense, since the original upstream webpage link to the source tree now points to the gerris sources, so it very much appears to have been coordinated.


> Instead, they should have renamed and reversioned their hacked-up version,
> which would allow parallel installation or they should formally take over the
> original project.
> 

Well, this wouldn't be good, as then we'd have two different libraries in Fedora which have 99.99% of their code which very much goes against packaging principles.


> I'll furtherly check details. ATM, I am inclined to harvest gerris's rolling
> tarballs and to add the useful parts of it as patches to Fedora's gts, should
> their works be compatible to the original gts.
> 
> Should they not be compatible, this won't work. My advise then would be you to
> rename their gts and to ship it independently of the original gts.
> 
> May-be you could try to contact gerris upstream and try to clarify the
> situation?

I will certainly send an email and see what their response is. I think the main concern is getting them to release stable versioned releases, and to take care over ABI issues.

If, as I suspect, it turns out that gerris is essentially the upstream of GTS, are you happy to switch the Fedora packages to that? 

What I haven't established yet is if anything else in Fedora links against GTS.
Comment 3 Ralf Corsepius 2011-12-02 08:14:41 EST
(In reply to comment #2)
> (In reply to comment #1)
> [snip]

> > * I consider it to be foul play of a project (here: gerris) and dirty work of
> > this project's maintainers to bundle hacked-up sources of another project
> > (here: gts) - "Hostile take over".
> 
> Well, I don't think it's a hostile takeover in any sense, since the original
> upstream webpage link to the source tree now points to the gerris sources, so
> it very much appears to have been coordinated.
> 
> 
> > Instead, they should have renamed and reversioned their hacked-up version,
> > which would allow parallel installation or they should formally take over the
> > original project.
> > 
> 
> Well, this wouldn't be good, as then we'd have two different libraries in
> Fedora which have 99.99% of their code which very much goes against packaging
> principles.

Pardon, but that's how forking works. They taking somebody else's works and make something increasingly incompatible out of it == they have forked and will have to implement measures their fork doesn't conflict with the original works.


> > May-be you could try to contact gerris upstream and try to clarify the
> > situation?

From what I can gather, what has happened is the gerris project having taken Debian/Ubuntus's gts patches (Most of them we don't have because they are mostly cosmetic) and started to hack upon them (There seem to be personal connections between Debian and gerris), with them expecting all the world to take over their hacked up version.

To me this qualifies as a plump hostile takeover or may-be just naivity and low quality of works.

FWIW: 
- Debian/Ubuntu has this hacked-up version
- openSuSE ships vanilla "gts-0.7.6" (without any patches, and without multilib compatible pkg-config)
- We ship more or less vanilla gts-0.7.6 (with multilib-compatible pkg-config).

All versions are known suffer a broken testsuite, which renders all judgement on gts's actual quality into speculation.

> I will certainly send an email and see what their response is. I think the main
> concern is getting them to release stable versioned releases, and to take care
> over ABI issues.
> 
> If, as I suspect, it turns out that gerris is essentially the upstream of GTS,
> are you happy to switch the Fedora packages to that? 
> 
> What I haven't established yet is if anything else in Fedora links against GTS.

Well, yes, gts is only of little importance in Fedora. A quick check (could be some packages escaped me) tells. it currently is only used by kd3 (also maintained by me), nevertheless it's quite fairly widely used elsewhere (e.g. by me ... some older, own works (not of public interest) use it.)

FWIW: I meanwhile am fairly confident the gerris-gts is mostly compatible to the original version. There is only one change, I need to investigate deeper (They inlined 2 hardly used functions, which formerly were conditionally inlined).
Comment 4 Jonathan Underwood 2011-12-04 19:09:29 EST
Hi Ralf,

So, the gerris team have clarified the situation in this thread:

https://groups.google.com/group/gerris-devel/browse_thread/thread/c6753c870343cee3?hl=en

As you'll see there, the gerris author is in fact the original GTS author, so it's not actually a fork - apologies for mischaracterizing it as a fork in this bug report. The latest tarball is available here:

http://gts.sourceforge.net/tarballs/

As you'll see it is in fact date versioned. I personally think this is what we should package for Fedora as it contains fixes since the 2006 0.76 tarball, and will allow me to package gerris and gfview for Fedora. The author indicates it should be ABI compatible. Are you amenable to this course of action?
Comment 5 Jonathan Underwood 2011-12-05 09:44:18 EST
I've now made these changes on the el6 branch, so if you like you can simply merge or cherry pick from there.
Comment 6 Ralf Corsepius 2011-12-07 22:27:24 EST
I upgraded rawhide to gts-snapshot-111025.

However, I did not copy/merge your el6 package, but went a different way, because I had to apply patches, because upstream's configuration is pretty broken and contains a larger number of "not so harmless"-bugs.
Comment 7 Fedora End Of Life 2013-04-03 13:12:39 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 8 Fedora End Of Life 2015-01-09 11:53:47 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.
Comment 9 Fedora End Of Life 2015-02-17 08:59:35 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

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

Note You need to log in before you can comment on or make changes to this bug.