<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 09/01/2010 01:07 PM, Jonas Smedegaard wrote:
<blockquote cite="mid:20100901110745.GU12548@jones.dk" type="cite">It
is a <b class="moz-txt-star"><span class="moz-txt-tag">*</span>much<span
 class="moz-txt-tag">*</span></b> slower process to convince a Debian
package maintainer to implement reliable packaging configurability for
our needs than to hack ourselves on top of an installed package, but
all hacks we invent we must <b class="moz-txt-star"><span
 class="moz-txt-tag">*</span>maintain<span class="moz-txt-tag">*</span></b>
too, which is too likely to bit-rot down the road.
</blockquote>
<br>
That's a tough one. I think it'll take too way much time and hassle for
our config changes to reach FB users. I also doubt maintainers would be
willing to have alternative configs
in their packages that they'd need to maintain, basically treating FB
as an arch against which they would be required to test on. I think we
must write our own patches and maintain them, in the end, that's part
of our job. Of course, if it's something that can be merged into the
official package, that's the way to go. But I'm talking about things
that cannot, things specific to our project (like eg. Apache config to
be able to run GNU social out of the box). So I'd talk about scenarios
where we do write and maintain our code for our specific needs. One
could imagine a maintainer accepting one FB dev as a co-maintiainer and
waiting for his patches before releasing their package, but that's
unlikely to happen. So if we have to write code ourselves, we could
just have our own set of diff patches that are applied to official
config files (eg. freedombox-configs package). However, therein lies
another problem also: FB users obviously cannot update to new versions
of packages, before we correct the configs, which not only delays the
package inflow, but also requires a mechanism which would do that. I
think we'd all agree having a repo of our own is a "bad thing", but
what else is there? Then again, maybe they would maintain for the
Freedom Box if we can get them interested. I don't know.<br>
<br>
--Luka Mar&#269;eti&#263;<br>
</body>
</html>