[Freedombox-discuss] don't write code - user-friendly configuration

[Jonas Smedegaard]

On Wed, Sep 01, 2010 at 04:47:51PM +0200, paxcoder wrote:
>On 09/01/2010 01:07 PM, Jonas Smedegaard wrote:
>>It is a *much* 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 *maintain* too, which is too likely to bit-rot down the road.
>
>That's a tough one. I think it'll take too way much time and hassle 
>for our config changes to reach FB users.

Skolelinux instructs its users to reinstall to newer major releases 
rather than upgrading.  I find that unacceptable for FreedomBox.

I would prefer a very simple FreedomBox - e.g. providing only routing 
and a single web page with Web-ID and Webfinger - which was upgradeable, 
over one with e.g. filesharing and a CMS which could not reliably be 
fully automatically be upgraded to next major Debian release.

Sure, adventurous users can always throw in testing, unstable or even 
experiemental additions, but I find it crucial that what we offer 
officially is as reliable as Debian itself, which to me means that it 
must *be* Debian itself.


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

Hey, you exagerate: FreedomBox is not an architecture but a Blend.

What package developers should be willing to do is not adopt a hardcoded 
combination of choices fitting our needs, but simply make it possible to 
express through debconf each of those many choices that we decide 
constitutes a "FreedomBox" installation of Debian.


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

A Debian packaging of GNU social should ideally work out of the box no 
matter if used as part of FreedomBox or some other blend of Debian.

If it does not, then we should not maintain local hacks to enable it, 
but help work with the package maintainer(s) to fix that weakness in the 
packaging.

If it does work but not configured how we need it, then we should not 
maintain local hacks to improve it, but help work with the package 
maintainer(s) in making the packaging more configurable.

If we pass on some GNU social configuration choices to our users and 
discover that the packaging only reliably supports install-time 
customizations, then we should not maintain local hacks to cover over 
that, but help work with the package maintainer(s) in e.g. using 
Config::Model to improve reliability in dealing with non-virgin 
configfiles.


>So I'd talk about scenarios where we do write and maintain our code for 
>our specific needs.

It is dead easy to start local hacks, and difficult to imagine how we 
will forget to properly maintain it.

It is dead easy to shoot ourselves in the foot.


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

Again, you exaggerate: We can file bugreports.  We can engage it 
discussing existing bugreports.  We can provide patches to bugreports.  
None of that need co-maintainership, just devotion to our needs.

Funny enough, local hacks may even need *more* work: Initially the hacks 
might be simpler (but we don't know, as we don't care to ask others for 
peer review as is implicitly done through bugreports), but we then not 
only need to invent all hacks ourselves (when filing bugreports others 
might come up with patches) but also maintain the hacks for eternity (or 
until we later do what we should've done at first: convince the package 
maintainer(s) to adopt our hacks or help come up with something possibly 
more complex but then usable in a broader scope).


>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?

So you agree that local hacks won't fly, or did I misunderstand and your 
point above is something else?


Kind regards,

  - Jonas

-- 
  * Jonas Smedegaard - idealist & Internet-arkitekt
  * Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20100901/5deb32f6/attachment.pgp>