On Fri, May 16, 2008 at 06:54:18PM +0200, Martin Uecker wrote: > I am not convinced that more technological infrastructure is really > the solution. Isn't simply the upstream source the right place for > collaboration?
NACK, or better: ACK in theory, but not in practice. Sometime you have wonderful upstreams which are willing to cooperate, reactive, and even share with you the love for $DVCS so that you can already exchange patch freely. But sometimes, most in my experience, this good properties do not hold. At that point you can really benefit in sharing patches across distros. I've been doing it a handful of times with Fedora maintainers which are working on OCaml packaging. They can easily point me to a single place on the web where they have patches. And I've benefited from them, as in the past they benefited from patches of mine. It happens that there are patches that upstream is not willing to take (maybe just because he is unreasonable) but in which more than one distro are interested [1]. On the contrary, as the Debian counterpart I cannot point them to a single unified place where my patches are available. Or better, I can but just because all OCaml packages are stored in a single svn repository, with a clear defined policy of only using debian/patches/ and no patches to upstream sources in .diff.gz. On a Debian-wide scale this kind of uniformity is not there: different $VCS, different policies on what to put in .diff.gz and what not. I think we will benefit a lot from a new unified patches.d.o infrastructure which clearly shows what changes we have made to software. ... and this is not only to ease code review which can diminish the risk of future disasters like openssl, but also for share efforts with others, probably the most important mantra of free software. (i.e. full-ack on Raphael's post) Cheers. [1] if you want an example here is one: the library libcamlrun.so implements the OCaml runtime systems as a shared object, if you have installed OCaml you can find it in `ocamlc -where`. It is linked without -fPIC by upstream which does not want to link it with because it slows down performances (which is of course true). Upstream does not want either to provide an additional library libcamlrun_shared.so linked with -fPIC as it will be an extra lib to maintain. In Debian I'm now applying a patch coming from Fedora which adds an extra library libcamlrun_shared.so as there is software, like Apache modules, which won't work if -fPIC is left aside -- Stefano Zacchiroli -*- PhD in Computer Science ............... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the (15:57:15) Bac: no, la demo scema \/ right keys at the right time
signature.asc
Description: Digital signature
