These are the notes for the November 30th, 2014 call, originally recorded at https://pad.riseup.net/p/rIM6J4iHxeP0
0.3 Release blockers
Do any remain? How do they get fixed? Who needs what help, and how do we get them that help?
- sunil: Small Bug: XMPP Server: When setting Hostname in Plinth's hostname-change action, the ejabberd.yml config file gets really screwed up because the regex is too greedy: replaces all occurrences of string with new string.
- jvalleroy: Building Beaglebone images: vmdebootstrap needs modification: Beaglebone loads u-boot from vfat parititon, but flash-kernel does not support vfat. Best strategy I can think of right now, is to have a separate vfat partition for u-boot, and an ext2 partition for /boot. Will require some changes to vmdebootstrap to support this.
- nickdaly: Vmdebootstrap autobuild support: jenkins/buildbot seems to require some changes to make it safe to build on a shared system.
Building for Jessie on Wheezy
Impossible? Being fixed?
- Focus on unstable instead of Jessie?
- Seems to have been fixed recently.
Monkeysphere Apache Authentication
GPG -> SSL cert for WoT authentication through Apache. Difficult to reuse certs/configs: the authentication process is tied to the user name on the cert requiring rewriting config files for new users.
- What about "Let's Encrypt!"? - It could be really useful for FBX. It sounds like they'll be willing to sign certificates in addition to providing you a cert, so they're doing everything right (not requiring a copy of your secret key). However, they require identity verification, so .onion names likely won't be supported.
- Nickdaly: don't remember what .onion ssl certs get us?
Wireless Access Points
What are next TODOs? What are our options?
- Captive wireless AP that has clients connect using Tor Browser. (Allow clients to bypass Tor Browser requirement, but forward their traffic over Tor?)
- Run Multiple wireless APs: one that uses Tor, and one that doesn't? Requires hardware support.
- First steps: add wireless AP configuration to Plinth. Let's not get too far ahead of ourselves here.
- How do we determine internal and external networks? What assumptions about network architecture are safe to make?
- Make wireless mesh networking work!
- Do we just need a web interface to network manager? Do we supply default configurations? Which? Depends what we can learn about the target device.
- When do we target that for? 2.0? Since it's such a big piece of work, maybe it shouldn't block any release.
- Have 1.0 targets, but tag a release after a significant feature change. Make point releases on significant progress.
- The 1.0 targets are ill-defined and hard to find.
Make the tool we want to use, and call it 1.0 when we're happy? What feature would make us deploy a FreedomBox all the time?
- Fonfon: calendar server (radicale in plinth).
- federico3: turn-key mail and calendar server
- Sunil: My Own Mozilla Sync server, owncloud server
- Pere: Browser bookmark server, mail over smtorp with notmuch index
- nickdaly: freedombuddy server that kept naming up to date (requires identity provider)
- jvalleroy: ikiwiki with SSO login
- mjones: apache sso login connected to freedombuddy
- Clint: Monkeysphere client certificate authentication
Contribution volume increasing - still lots of disparate tasks to complete, so targeted point releases are probably not a good idea. Should be an agreement between the key developers, not an announcement to tell people not to work on other areas. We say "we would like to have these features in X.y release", not "these features should be in X.y release".
Reorganization of confirmed TODOs list into an issue tracker and other TODOs into wiki.
- Have a broader 1.0 list, but tag point releases as the features come in.
- How do we manage the todo list? Move the items into the issue tracker. Research items stay on the wiki, but confirmed items to the tracker.
- Where to have the issue tracker?
- alioth, gitorious, debian (debbugs)
- debbugs should be reserved for packaging issues and not necessarily the upstream?
- debbugs should be used for everything because users won't know the difference between packaging issues and source bugs?
- freedomboxfoundation.org should be updated, all that stuff's outdated.
- the wiki has lots of ideas, but not confirmed or well defined requests.
- how do we confirm requests? 2 votes from committers? the list? what's a vote?
- put together a list and ask for a month of discussion, to review during next month's call.
github's issue tracker can tag bugs for target versions! (http://mako.cc/writing/hill-free_tools.html)
- so can bts's tracker
federico3 volunteered to create a bts -> github mirroring tool.
Decide on a good entry point for the project (the wiki?). Update freedombox foundation website.
fbf.org site should point to other documentation because it's difficult to update (only Nick has access to modify), should point to wiki and task list mostly.
Plinth Progress and Future
Dashboard work done by Michael Pimmer (fonfon) and package manager UI, etc.
- Dashboard (plinth merge request #20): looks awesome, still open, close to ready to be merged: needs augeas pagekite lenses.
- create wiki page to track requests for an API and link it in the documentation.
Package manager UI
Sunil: when installing packages via Plinth, it's kinda hokey now. However, if we use the packagekit daemon, we can easily show whether the package is installed, install it, and display a fancy progress bar. Many Debian packages could be exposed through the package manager UI. We'd also need a service starting/stopping framework. Augeas could help us add packages quickly.
- Target: add package installer. makes it easy to write plinth apps faster.
Preferred time, date, and communication method?
- Audio Only: Mumble
- Video Optional: appear.in, meet.jit.si
- Do any of the video tools have ways to disable the video, for low-bandwidth situations?
- Sunil: Timing isn't great, but no technical problems. Video unimportant. Can we move it earlier? (Okay with a slightly later time also, however)
- Pere: video is important to say hello! can we move it back a bit? 19:30 (norway time) is good-ish.
- Nick: as long as it's not required for functional purposes, it should be fine. fallbacks!
Next call: Sunday, September 24 at 17:00 UTC
This page is copyright its contributors and is licensed under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.