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?
zack@{upsilon.cc,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
Attachment:
signature.asc
Description: Digital signature