Ulrich Drepper's personality [LWN.net]

Ulrich Drepper's personality

Posted May 7, 2009 6:49 UTC (Thu) by drag (subscriber, #31333)
In reply to: Ulrich Drepper's personality by mbanck
Parent article: Debian switching to EGLIBC

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:
http://ourdelta.org/

As a response to the slow and somewhat negative behavior with Sun Microsystems regarding
MySQL releases.

Another example coming from Sun would be Go-OO.org
http://ourdelta.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.

(Log in to post comments)

Ulrich Drepper's personality

Posted May 7, 2009 8:31 UTC (Thu) by nhippi (subscriber, #34640) [Link]

The eglibc switch has it's roots in the openssl patch epic fail. Since then, it was deemed that patching upstream is generally bad. Changes to code should be done with co-operation from upstream. Some developers (such as the glibc maintainer) raised the valid question of what do when upstream refuses to accept patches? (Too lazy to search for the debian-devel specific discussion).

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).

Ulrich Drepper's personality

Posted May 7, 2009 13:19 UTC (Thu) by btraynor (subscriber, #26672) [Link]

Just to be clear, your statement "the move to eglibc isn't as much about creating a fork of Glibc" implies that Debian's use of eglibc creates a fork of glibc.

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.