[Freedombox-discuss] don't write code - user-friendly configuration
- Subject: [Freedombox-discuss] don't write code - user-friendly configuration
- From: firstname.lastname@example.org (Jonas Smedegaard)
- Date: Wed, 1 Sep 2010 18:19:06 +0200
- Message-id: <[🔎] 20100901161906.GY12548@jones.dk>
- In-reply-to: <[🔎] 4C7E6797.email@example.com>
- References: <20100830091544.GB5282@jones.dk> <AANLkTikK9OpGPzSwhsU5JJiShhQmANiQCqJs+x065Hc0@mail.gmail.com> <20100830100427.GG5282@jones.dk> <AANLkTi=3_qtco2ghMBvxrorBXrx=HafCLWkUooHHO4_j@mail.gmail.com> <20100830114308.GK5282@jones.dk> <AANLkTimiAYomQZJtgFz0SqGb2PE0c+zaLK=1Kb4Fna1V@mail.gmail.com> <20100831095554.GP5282@jones.dk> <firstname.lastname@example.org> <[🔎] 20100901110745.GU12548@jones.dk> <[🔎] 4C7E6797.email@example.com>
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
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
>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
So you agree that local hacks won't fly, or did I misunderstand and your
point above is something else?
* 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
Size: 836 bytes
Desc: Digital signature