Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
I assume the day eglibc will become incompatible with glibc, Debian will redecide which upstream to follow.
Ulrich Drepper's personality
Posted May 7, 2009 6:49 UTC (Thu) by drag (subscriber, #31333)
Now that I've had time to think about it some it seems that the move to eglibc isn't as much
about creating a fork of Glibc.. it's just that it is easier to share the burden of managing patch
sets with other people who are experiencing the same problem.
Maybe the term should be 'SPORK' instead of 'FORK'. I've noticed that this is happenned with a
few different peices of software when people are trying to figure out how to deal with difficult
situations created by upstream developers who otherwise are valuable.
There has formed a multitude of MySQL sporks over the time. Stuff like OurDelta:
As a response to the slow and somewhat negative behavior with Sun Microsystems regarding
Another example coming from Sun would be Go-OO.org
In both cases they don't really want to _fork_ their projects. But they have requirements or
desires that are simply not being addressed by the upstream folks in a timely manner. So in
both cases they try to shove code back upstream, but is a community way of maintaining
their own patches.
Posted May 7, 2009 8:31 UTC (Thu) by nhippi (subscriber, #34640)
The upstream certainly has all the rights to put up whatever QA and codestyle requirements they want. The maintainer of the package has the duty to fulfill such requirements and correct any issues in the patch noted by upstream. The end result is better for everyone - debian gets a better fix, and all the other users get the fix too when upstream releases new version.
But what do when upstream plainly refuses to accept a patch? Or tells you to "Go away, stop wasting everyones time"?
One option in such cases is to start maintaining a explicit fork (or spork, as mentioned here). It is more honest for endusers than maintaining a ever-growing stack of patches hidden in a distribution source package. And if others have the same problem(s) with upstream, the spork allows sharing the maintenance burden.
Other options could be switching the maintainer (it is always the upstream that has co-operation problems...) or dropping the package all together (if there are better alternatives).
Posted May 7, 2009 9:26 UTC (Thu) by pabs (subscriber, #43278)
Posted May 7, 2009 13:19 UTC (Thu) by btraynor (subscriber, #26672)
EGLIBC has been around since November 2006 or so. It is a fork of glibc, given this definition, "a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct piece of software" -- http://en.wikipedia.org/wiki/Fork_(software_development).
Also, #eglibc on freenode is alive.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds