Distribution-friendly projects - Part 1

Posted Mar 27, 2008 19:25 UTC (Thu) by Sho (guest, #8956)
Parent article: Distribution-friendly projects - Part 1

Personally, I'm opposed to the upstream vs. downstream picture painted here. For me, upstream
projects are shared spaces where parties interested in a particular project convene to develop
it to address their (potentially disparate needs), i.e. so-called downstream developers should
actually engage in upstream development to get their needs met (such as features, or the
flexibility to make the software act and look in the ways required by the distribution). The
changes affected upstream then subsequently trickle downstream.

Not doing it this way, i.e. supposing that upstream provides a certain raw kind of software
and last mile development (including, frequently, the addition of entire new features) should
happen in the distributions, usually leads to severe quality control problems. The downstream
developers may not be or usually are not familiar enough with the codebases they work on to
affect significant changes without causing regressions or defects, and by doing the work
downstream rather than in the shared upstream space, they actively evade peer-review from
those who are in the know.

With the kernel in particular, we've seen that problem grow to unholy dimensions (as distro
kernels often were significant forks in the 2.4 era), but thankfully mostly addressed it by
now (except for the embedded space). In the userspace arena, it's still pretty bad, however,
with distributions grabbing and applying undone patches from left and right to differenciate
their offerings from their competitors, with consequently little interest to share or push
upstream. The result is that userspace applications shipped by distributions can often times
be in considerably worse shape than the original upstream releases.

Now, you're Gentoo guy, and I know that Gentoo generally has a relatively sane policy when it
comes to the extent of the deviations from upstream that it will ship, and that it will
generally try to push upstream whatever it comes up with first. Unfortunately, that's not true
for everybody in the market.

to post comments

Distribution-friendly projects - Part 1

Posted Mar 28, 2008 0:47 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

This is shortsighted. Stuff like the X Window System, OpenOffice, TeX, or even {,x}emacs run (and are compiled from the same source!) on a large variety of different systems, from Windows to Linux over all sort of propietary Unix systems and *BSDs.

At least Fedora (after a longish time during which Red Hat shipped heavily patched packages) is relying ever more on working closely with the upstream developers, and shipping as close to vanilla sources as feasible. Several of the Fedora packagers are actually active upstream developers. I'd be surprised if other distributions didn't do likewise.

Distribution-friendly projects - Part 1

Posted Mar 28, 2008 15:52 UTC (Fri) by tzafrir (subscriber, #11501) [Link] (1 responses)

Kernel 2.4 (Or actually: kernels before the new 2.6 development model: around 2.6.5?) were
examples of packages that required large ammounts of patches. Their release cycles were very
long. The latest stable kernel simply didn't support latest hardware. A distribution had to
backport many drivers just to support the latest hardware. And if you backport drivers, you
eventually have to backport some other useful features.

Indeed the fix for that was an upstream change of the development model.


Pushing upstream is the right thing to do (in the long run) for the downstream package
maintainer, as maintaining a difference means more work for new upstream versions. And people
are lazy.

Distribution-friendly projects - Part 1

Posted Mar 28, 2008 18:10 UTC (Fri) by Sho (guest, #8956) [Link]

> Kernel 2.4 (Or actually: kernels before the new 2.6 development 
> model: around 2.6.5?) were examples of packages that required 
> large ammounts of patches.

Upstream definitely has to do its part, yes. If the upstream project doesn't understand itself
as a shared space for a variety of stakeholders, there's little a distribution can do - except
perhaps fork, and make a new, proper upstream to go to.

Distribution-friendly projects - Part 1

Posted Apr 1, 2008 5:34 UTC (Tue) by eean (subscriber, #50420) [Link]

Well I don't know anyone who straddles the upstream/downstream fence more then Diego. But he
really is the exception. This article talks about how they have some fundamental differences.
You may not like the upstream and downstream split, but it exists.

With Amarok, sometimes I end up feeling like downstream is more concerned with packaging
standards and guidelines then quality control. "If it compiles and starts, ship it" kind of
attitude. This is mostly found in non-profit poweruser distros. Examples include a couple
years ago Debian removing (or marking it as "suggested") the Ruby dependency on Amarok,
despite it being required for Lyrics (and now scoring as well). Recently some other distro I
hadn't heard of put Amarok scripts into a different package that wasn't default, breaking
these features. So a user came in to #amarok and blamed Amarok for not handling this issue
better (an issue created by the distro). (Gentoo has a 'ruby' use flag, but I've never heard
of such complaints from Gentoo users, I guess because USE flags are more obvious then random
extra packages.)

However probably the most annoying thing (commercial or not) downstream has done was hire a
Indian programmer to work on media devices for Amarok 1.3 when Amarok 1.4 had totally
re-worked media devices and had been released for a while. But the programmer had apparently
been directed to just use the Amarok that they had packaged already. It was a waste of their
money and a waste of a potential development resources for us. This is kind of a separate
"suits not understanding the most basic parts of collaborative development", which is odd
since it's not so different from in-house development. I had a similar issue recently with
someone adding some nice features for Amarok 1.4 when we have it in a feature freeze; they
didn't communicate with us until after they had done much of the coding.