Publish log entry

1 files changed, 97 insertions, 0 deletions

diff --git a/blog/2019/02/17/netsurf_and_ick.mdwn b/blog/2019/02/17/netsurf_and_ick.mdwn
new file mode 100644
index 0000000..6c8ebde
--- /dev/null
+++ b/blog/2019/02/17/netsurf_and_ick.mdwn
@@ -0,0 +1,97 @@
+[[!meta title="Netsurf and Ick"]]
+[[!tag netsurf]]
+[[!meta date="2019-02-17 16:08"]]
+
+Netsurf (http://www.netsurf-browser.org/) is a lightweight and
+portable web browser. It targets several older operating systems, for
+which it is often the only graphical web browser.
+
+Netsurf is cross-built for many older operating systems which can not
+support native build. It is natively built on a number of esoteric
+systems for which cross-building is not possible. For some more modern
+operating systems, NetSurf is built for several different toolkits and
+target kinds, including some pure-test-related builds whose outputs
+are coverage reports, test summaries, etc, rather than executable
+artifacts.
+
+NS currently uses Jenkins, but finds it problematic. A particular
+problem is that current versions of Jenkins want a version of Java
+that is newer than what is supported on some of the systems NS
+targets. Jenkins has also proven to be inflexible to use. NS is
+interested in replacing Jenkins with Ick, eventually.
+
+The NetSurf project has sunk a significant amount of effort into
+making the older Jenkins fit-for-use, so while replacement is
+desirable, there will need to be an easy pathway to transition to Ick,
+or to have Ick run alongside Jenkins while jobs are migrated piecemeal
+over time.
+
+Another significant issue with Jenkins for the NetSurf project is that
+of configuration management. Jenkins' ability to be configured without
+use of its web-UI is, while not limited as such, unpleasant to work
+with. Significant security issues surround the JNLAPI and as such,
+given the age of the Jenkins in use, NetSurf are unable to automate
+configuration management. A feature of Ick which attracts the project
+is the possibility of git-based configuration of the CI system.
+However, the project does find the web-UI useful from time to time in
+order to make small tweaks to configuration (for example when
+debugging a CI job). Ick will need to support some configuration
+changes through a web-UI (ideally making and pushing git commits
+behind the scenes).
+
+NS is divided into many components, sub-projects, each of which builds
+something like a library used by other components. The various
+components thus have build dependencies on each other, and if a
+dependency changes, any components that build-depend on it need to be
+built and tested as well.
+
+Some components are host-based tools which are consumed by many
+downstream variants of component builds. For example, the binding
+generator is built for each host (e.g. `x86_64` Linux vs. `i686`
+Haiku) and is then consumed by any downstream build running on that
+host, regardless of its target (e.g. on `x86_64` Linux, a build of
+NetSurf targetting AmigaOS).
+
+The NS project hosts its own builders, and there is at minimum ssh
+access to them. They may need to have each builder run multiple
+workers, to use hardware efficiently. The builders are not all
+co-located in the same physical location: being frugal with bandwidth
+use is a concern.
+
+All of the builders are linked to a virtual LAN (single broadcast
+domain across multiple sites). This means that in situations where
+bandwidth is a concern, non-encrypted protocols are considered just as
+secure as encrypted ones. While SSH is available to all hosts, some
+are perhaps less reliable than others. It would behoove Ick to not
+rely on communication purely via SSH if at all possible. Sadly Python
+is not necessarily available on all hosts either. A small C-based
+agent may be required for maximum flexibility and minimum risk of
+TTY/SSH related issues.
+
+NetSurf has CI notifications routed to a number of targets including
+the project IRC channel, a mailing list, and an RSS feed from the
+Jenkins. In order for these routes to be useful, NetSurf would find
+the ability to construct rules in order to filter and route
+notifications very useful indeed. For example, every successful or
+failed build should not be notified to IRC, instead only when a job
+changes state from success to failure or back. Ensuring that
+notifications carry useful semantic information and links will also be
+desirable.
+
+NetSurf makes use of Jenkins' history of builds, allowing the project
+to trace non-fatal issues through builds. These link back to the git
+repositories at the specific commits built, and this is considered a
+critical feature of the UI.
+
+NetSurf would very much like it if the CI could be easily configured
+to deploy branch-based builds in a way which will not confuse artifact
+handling, and will allow developers to build a branch across many
+repositories in order to simplify the testing of the development of a
+new feature which crosses libraries. Such a concept is often referred
+to as "system branches".
+
+It would be best if these builds were not created by default for any
+branch, but rather that there was a simple way for a developer to
+activate a set of jobs for a branch. Perhaps by adding the branch name
+to a configuration in Ick via either the web-UI or via the git
+configuration. Or perhaps by pattern of branch name.