# NLNet Milestone tasks
-TODO
+Part of applying for NLNet's Grants is a requirement to create a list
+of tasks, each of which is assigned a budget. On 100% completion of the task,
+donations can be sent out. With *six* new proposals accepted, each of which
+required between five (minimum) and *ninteen* separate and distinct tasks,
+a call with Michiel and Joost turned into an unexpected three hour online
+marathon, scrambling to write almost fifty bugreports as part of the Schedule
+to be attached to each Memorandum of Understanding. The mailing list
+got a [leeetle bit busy](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-March/005003.html)
+right around here.
+
+Which emphasised for us the important need to subdivide the mailing list into
+separate lists (below).
# Georgia Tech CREATE-X
# Public-Inbox and Domain Migration
-TODO
+As mentioned before, one of the important aspects of this project is
+the documentation and archiving. It also turns out that when working
+over an extremely unreliable or ultra-expensive mobile broadband link,
+having *local* (offline) access to every available development resource
+is critically important.
+
+Hence why we are going to the trouble of installing public-inbox, due
+to its ability to not only have a mailing list entirely stored in a
+git repository, the "web service" which provides access to that git-backed
+archive can be not only mirrored elsewhere, it can be *run locally on
+your own offline machine*. This in combination with the right mailer
+setup can store-and-forward any replies to the (offline-copied) messages,
+
+Now you know why we absolutely do not accept "slack", or other proprietary
+"online oh-so-convenient" service. Not only is it highly inappropriate for
+Libre Projects, not only do we become critically dependent on the Corporation
+running the service (yes, github has been entirely offline, several times),
+if we have remote developers (such as myself, working from Scotland last
+month with sporadic access to a single Cell Tower) or developers in emerging
+markets where their only internet access is via a Library or Internet Cafe,
+we absolutely do not want to exclude or penalise such people, just because
+they have less resources.
+
+Fascinatingly, Linus Torvals is *specifically*
+[on record](https://www.linuxjournal.com/content/line-length-limits)
+about making sure that "Linux development does not favour wealthy people".
+
+
+TODO (Veera?) bit about what was actually done, how it links into mailman2.
+
+# OpenPOWER HDL Mailing List opens up
+
+It is early days, however it is fantastic to see responses from IBM with
+regards to requests for access to the POWER ISA Specification
+documents in
+[machine-readable form](http://lists.mailinglist.openpowerfoundation.org/pipermail/openpower-hdl-cores/2020-March/000007.html)
+I took Jeff at his word and explained, in some detail,
+[exactly why](http://lists.mailinglist.openpowerfoundation.org/pipermail/openpower-hdl-cores/2020-March/000008.html)
+machine readable versions of specifications are critically important.
+
+The takeaway is: *we haven't got time to do manual transliteration of the spec*
+into "code". We're expending considerable effort making sure that we
+"bounce" or "bootstrap" off of pre-existing resources, using computer
+programs to do so.
+
+This "trick" is something that I learned over 20 years ago, when developing
+an SMB Client and Server in something like two weeks flat. I wrote a
+parser which read the packet formats *from the IETF Draft Specification*,
+and outputted c-code.
+
+This leaves me wondering, as I mention on the HDL list, if we can do the same
+thing with large sections of the POWER Spec.
# Build Servers
projects / crowdsupply.git / commitdiff