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

[paxcoder]

On 09/01/2010 06:19 PM, Jonas Smedegaard wrote:
> On Wed, Sep 01, 2010 at 04:47:51PM +0200, paxcoder wrote:
>> 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 don't quote get your point here. Why would users need to reinstall 
things in any scenario?

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

Yes, but this is supposed to be a product for your Average Joe, with a 
sleek and easy-to-use interface. The interface would be upgraded for new 
versions of programs (or more frequently perhaps, backends to these 
programs would be updated) just like it's the case with Webmin, or 
phpmyadmin or any web or non-web based GUI front-end. Filesharing? I 
pressume you mean as part of GNUnet - GNUnet would upgrade just fine - 
like any other debian package. If you mean distributed storage or some 
other "non-standard" thing we might come up with, we'll just need to 
make a new packet for it. We should not chip away from the project for 
convenience.

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

To be quite honest, stable is virtually pointless to me. I can see why 
admins would want it - it gives them a sense of security, but I have no 
use of it, it's obsolete. We could I guess offer the "older version" 
(stable) of Freedom Box software stack alongside our primary based on 
unstable. I mean who'd still want to run GNU social alpha once there's a 
full version available? If others want to base FB primarily on stable I 
can't stop them from doing it. So far, though, you're the first one who 
said that.

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

A blend that I think will prove quite unlike the main distro. It's meant 
for different things, and it does common things differently. But I'm not 
a DD so I don't really know all that can and cannot be done with 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.

I guess you're right.

> 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 can still make a unified web gui to configure packages that way 
instead (or automatize things), I'm up for it.

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

That's the part I didn't know. Any links about Config::Model?

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

No, that's easy too. But I didn't know there were any other workarounds 
until you told me. You'll have to teach me (and other non-DD's) the 
tools to do this though.

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

I deprecate "local" modifications too. I'm still concerned with 
viability of making the project subset of the official distro, but for 
now, I'll take your word that it can be done. As long as it doesn't 
limit us in what we're set to do, I'm perfectly happy. Or more 
universally, I say obey the standards (de-facto or otherwise), unless 
they conflict with freedom or progress.

Regards,
--Luka Marčetić