IRC meeting/2010-10-14

From Freenet Wiki
Jump to: navigation, search



Project management

Code refactoring
the source is bloated. there used to be more contributors to freenet and there's a lot of cruft that have accumulated over the years, back from when java had next to no libraries. IMO it's time to replace some of them, which would reduce future maintenance and entry barrier for new devs.
Some of this touches on other issues e.g. if we use the Java crypto code we get to use hardware acceleration, but we may be constrained on block size, which would mean lots of rewriting; and we can't add extra rounds as was recommended some time back due to weaknesses in AES-256...
project work-time
we have one full-time coder working mainly on freenet core development. other areas are neglected, such as documentation, UI, apps (talk, search), etc. we need to address this, IMO urgently.
We need more devs! We should discuss what the barriers are to volunteers. If we have funding for additional paid devs that would be really awesome too but I'm not aware of a queue forming for my job. :)
Release timing in general, and remaining key issues for 0.8.


Smar and Nikerabbit have a suggestion for a translation system that works via a wiki
translatewiki extension - idea is to use scripts to import/export between git, then translators can use the nicer interface that it provides to do translations more easily.
user interface
"look and feel" seems outdated, some parts are awkward to use (downloads/uploads), arguably confusing terminology, not dynamic, etc.
both Windows and non-Windows.


New load management
i.e. what the blah has toad being doing this last month. Data persistence, general network performance, etc. (Closely related to previous)
Freetalk status report.
Library current poor performance, next steps.
Fundamental security issues
Darknet insecurity, opennet insecurity, what should we do about it when, what should we tell people, etc.
Merge timing for zidel's low level rewrite.
Database crypto / database auto-backups / database-cached-in-memory.
The first issue was somewhat intractable and me and Ian have made a decision, but people might want to re-discuss it anyway.


Meeting started at 19:15 UTC. Present (time of arrival):

  • (19:00) nextgens, TheSeeker, Smar, zidel, infinity0, Nikerabbit, notsorandomnick, kingpawn, Dieppe, sanity, Nioate, toad_, asfdf5353, ljb, Bombe
  • (19:10) Goodgood
  • (19:20) p0s
  • (19:30) tsp
  • (20:00) Tommy[D]
  • (20:30) mhatta__, saces, Xov

Record of points raised:


Translation updates

  • Smar proposes we setup Translatewiki to make the translate process easier.
  • nextgens and toad_ explain the current translations system and the update process.
  • Various people note that any new update process needs to accommodate anonymous contributions (e.g. from Freenet/FMS)
  • p0s and toad_ note that the current system does not automatically invalidate translations when the master version (English) is changed.
  • Nikerabbit explains how Translatewiki works and its features, including import/export.
  • General discussion follows, on how to integrate this into the git history, preserving authorship.
    • Translatewiki can export authorship information; this can be parsed and commits made manually. It's possible but not trivial to write scripts that do this.
  • infinity0 proposes to help set this up on Freenet's servers if Smar writes the bulk of the scripts. This is accepted.

JS-only UI (1/2)

  • tsp notes that a JS-only UI forces usage of graphical browsers.
  • Various people offer opinions on the issue of a JS-only UI. Many seem to favour a JS-optional UI.


Windows installer

  • toad_ and nextgens bring up problems with the current windows installer, and give a brief of its history.
  • nextgens notes that the hardest part is to continuously maintain it, to ensure that it keeps working.
  • toad_ points out that he needs to purchase copies of Windows for testing purposes.
  • Various people discuss ways of implementing a windows installer, including MSI/NSIS and even using a VM.
  • infinity0 notes that this doesn't solve the problem of needing a regular maintainer.
  • p0s argues that the windows installer is an important component and therefore by default falls to toad_ if no other suitable person can be found.
  • toad_ accepts this solution in the case where our current maintainer Zero3 doesn't show up in time for the next release.
  • sanity offers to provide windows licenses.


JS-only UI (2/2)

  • sanity and nextgens argue that the security argument against a JS-only UI doesn't make sense.
  • toad_ points out difficulties with users who have disabled JS or use a non-JS browser.
  • sanity notes that GWT supports various accessibility protocols.
  • sanity argues that this does not apply to the vast majority of the (existing and potential) user base, who would be inconvenienced by these special considerations.
  • toad argues that it may apply to a signficant portion of the active contributing community.
  • sanity and nextgens discuss whether a new UI is really necessary. p0s argues for a transition phase.
  • infinity0 asks for a summary of the arguments surrounding a JS-only UI. This will be posted elsewhere soon. TODO link.
  • The issue is left open for now.
  • Dieppe offers to start work on a mock-up.


  • p0s gives a report on the progress of Freetalk. A few bugs left, but some disruptive architectural changes are needed.
  • sanity suggests prioritising effort on the most release-critical parts.
  • p0s accepts, and estimates the work-time left to be a few dozen man-hours.

GSoC projects

  • nextgens gives a report on the GSoC projects, of which 2 out of 3 were a success.
  • nextgens advises toad_ to merge the code quickly, included some leftover code from last year's GSoC.
  • toad_ talks about the issues surrounding this, but agrees that he'll try to do this soon.


Release schedule (1/3)

  • sanity brings up the release schedule
  • toad_ talks about how the GSoC merges will affect it, and new features like new-load-management and anti-DoS measures


  • p0s notes the number of issues left on the bugtracker and its poor state of maintenance.
  • infinity0 notes that the bugtracker and the wiki are not well-structured enough, and that often people dump items without relating it to other items.
  • toad_ notes that the roadmap page on the bugtracker is crowded with unclosed minor bugs.
  • nextgens notes that the translation update system is inefficient, partly due to a confusion of responsibilities.
  • nextgens and infinity0 argue for creating "roles" for volunteers, to clarify someone's expected responsibilities. Examples include "l10n co-ordinator" and "bugtracker maintainer". After some discussion this is accepted, to help track of work to be done.
  • infinity0 suggests maintaining an overview page on the wiki to keep track of the project's overall progress.


Release schedule (2/3)

  • toad_ explains issues surrounding Library, such as data persistance and better search functionality.
  • toad_ explores developing a filesharing plugin, but p0s and infinity0 suggest to focus on solving existing problems, rather than overstretch development effort.
  • p0s re-emphasizes the number of minor bugs on the bugtracker
  • toad_ and infinity0 argue about attracting users vs attracting devs.

Future meetings

  • infinity0 proposes to make these meetings regular. A period of 4 weeks is accepted.


Release schedule (3/3)

  • General discussion on a release date for 0.8 follows. Suggested times range from November to January, depending on features completed.
  • The issue is left open for now.
Personal tools