Progress call: 17:00 UTC
- 1 issue report to follow-up: Mount encrypted ext4 disk
https://discuss.freedombox.org/t/mount-encrypted-ext4-disk/124
- Copy to issue tracker / Debian bugs
- Hardware kit discussion
Possible integration of a 2nd storage device in next version of Lime2 & Pioneer kit
- Would we prefer a 2nd SD card slot?
- Backups - Cannot be the only proper solution for backups.
- Software RAID
- Use 2nd disk when available
- Generic solution
- Or a big case that fits an external storage device connected to the SATA port?
- More reliable than SD card
- Cost
- Would we prefer a 2nd SD card slot?
- Explore A64-based OLinuxino board
- quad-core
- 64-bit processor
performance comparable to RasPi3
- 2 GB RAM
- in-built flash storage
- Cost is slightly higher
- Outcome: explore with Olimex shipping A64-based boards instead of the A20 board. The higher cost of this board can be offset by removing features like the battery, HDMI and Audio jacks, and possibly the chips for HDMI and audio
- Battery
- Consider to remove or make optional
- Some issues with rebooting device with battery connected.
- More useful in areas without constant power (places with daily, if momentary, outages would benefit from having the battery)
- On the other hand, there aren't reported cases of data corruption when a LIME2 powered off in cases of power outage.
- Avoid potential issues with sudden shutoff
- Adds complexity to shipping/setup process: Ships with battery disconnected.
Outcome: we should recommend that the battery be made optional, not a default feature of the kits. Some users in areas with frequent power outages do need the battery (it provides more longevity for the FreedomBox installation).
- HDMI / audio jack / corresponding chip could be removed from the pioneer edition LIME2
- Physical connectors
- 2nd Ethernet port for router use-case
- More expensive
- Lamobo R1
- 5 ethernet connections
- Olimex can consider how this board was made profitable
- Code of Conduct / Governance
FreedomBox Foundation applying for grant from Mozilla
- Grant requires all applicants to have a Code of Conduct
- Integrating Debian Code of Conduct
- Integrating ideas from Mozilla checklist
- 2 items to discuss:
- Clarifying responsibilities of leadership
- What each person is responsible for
- Can help solve some miscommunication.
- Clarifying responsibilities of leadership
- Cycles of feedback
- Make it clear what the feedback and implementation process looks like.
- Seems like endless feedback on some RFCs.
- Propose to set end date.
- i. For basic community conduct, the Debian CoC:
ii. For the other project governance matters, we should use Mozilla’s checklist as a blueprint: https://github.com/mozilla/diversity/blob/master/evaluation_tools/governance-basic.md
- Danny's first thoughts about what a governance document could do for us:
- a. Informally doing but could be better: “Our project leadership is designed with cycles of feedback and review”
- b. Not doing but would like to do: “Responsibilities of leadership are clearly documented.”
- c. Could do better: “We strive to encourage and recognizes the quietest voices, and not just those with the most confidence, and volume.”
- d. Not doing but would be very easy to create an opt-in convention (e.g. if preferred, anyone can add their pronouns next to their name in agenda items): “We have provided a way for everyone to share their pronouns, and respect those in our conversations and communication.”
- Bounties
https://discuss.freedombox.org/t/it-would-be-great-to-have-a-bounty-section/145/11
- Would need to be managed by 3rd party like Bountysource.
- Does Bountysource support integration with gitlab/salsa issues?
- Check that platform supports our values like privacy.
Would require governance by core maintainers (because the maintainers decide what features get integrated into FreedomBox)
- Problems with bounties
- Need clearly defined, separate features, ready for implementation
- Clear way of how contributions happen
- Connection to / dependence on Debian
- Alternatives to bounties:
- Open Collective - allows contributors to submit expenses to be approved
- Criteria for acceptance of the bounty request:
- 1. relevant packages are available in Debian
- 2. core maintainers agree to integrate the feature upon completion
- Treat as experiment, see how it goes
- What this experiment looks like: core maintainers working with the person who is offering a bounty for wireguard, helping him/her to define the tasks of the bounty, and monitoring execution.
- First task: evaluation of bountysource.com. Is it a platform that respects our values?
- Subsequent tasks: Sunil is willing to detail the problem and review the code when it comes up.
- Timeline: We can test a bounty program in June, July, August 2019, and revisit it in September 2019
- What this experiment looks like: core maintainers working with the person who is offering a bounty for wireguard, helping him/her to define the tasks of the bounty, and monitoring execution.
- Public Searx instance
- 1. Use with Tor browser
- Add option to serve it publicly
- Front page link
- Add option to serve it publicly
- 2. Even with login:
- 1. Use with Tor browser
- Searx not compatible with new google UI
- Probably fixed in 0.16
- Possible upgrade path through backports
- Add ddg, startpage, and qwant as alternatives
- Probably fixed in 0.16
- Option for administrator to set default search engines used by Searx
- Git applications
- Developer-centric, not a priority for core project
- Could be contributed as patches
- Gitweb
- Developer-centric, not a priority for core project
- Searx to use Tor