Update
This commit is contained in:
parent
4aab758b5c
commit
d530adc171
24
custom.css
Normal file
24
custom.css
Normal file
@ -0,0 +1,24 @@
|
||||
h1 {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
div > p {
|
||||
padding-left: 40px;
|
||||
}
|
||||
|
||||
div > ul {
|
||||
padding-left: 53px;
|
||||
}
|
||||
|
||||
.centered {
|
||||
p {
|
||||
padding-left: 0px !important;
|
||||
margin-left: 0px !important;
|
||||
margin-right: 60px;
|
||||
padding-right: 20px;
|
||||
}
|
||||
ul {
|
||||
padding-left: 0px !important;
|
||||
}
|
||||
text-align: center;
|
||||
}
|
||||
49
notes.md
49
notes.md
@ -10,45 +10,62 @@
|
||||
- functions
|
||||
- libraries
|
||||
- programs (unix)
|
||||
|
||||
- lesson: specifications
|
||||
- LSP (open source milestone)
|
||||
|
||||
- lesson: caring about features and code instead of maintenance and collaborations
|
||||
|
||||
- lesson: dicatorships work
|
||||
- lesson: users (user experience)
|
||||
- what if you diverge from the happy path
|
||||
|
||||
- decision making (processes)
|
||||
- lightweight when risk of mistakes is low (can revert?)
|
||||
- lesson: how to drive change
|
||||
- good value proposation (e.g. when breaking backwards compat)
|
||||
- risk: can you revert?
|
||||
|
||||
- tests in CI are garbage
|
||||
|
||||
- you guessed it, I like small programs
|
||||
|
||||
- self-perception/myth
|
||||
|
||||
- how to test (on the end users system)
|
||||
- tests in CI are garbage
|
||||
- tests vs good code
|
||||
|
||||
- reverse dependencies <-> me <-> users
|
||||
- collaboration vs boundaries, communication
|
||||
|
||||
|
||||
- what distribution work taught me for programming
|
||||
- autotools intro?
|
||||
|
||||
|
||||
- mindful about what you don't know
|
||||
|
||||
|
||||
- posix principles and their connection to functional programming (streams)
|
||||
|
||||
- navigation
|
||||
|
||||
- strings
|
||||
- open source politics
|
||||
- how to drive change
|
||||
- how to handle contributions (contribution experience, PRs, documentation, mentoring,. ..)
|
||||
- collaboration
|
||||
- open source politics
|
||||
- how to drive change
|
||||
- how to handle contributions (contribution experience, PRs, documentation, mentoring,. ..)
|
||||
- respect other projects when contributing
|
||||
- bus factor
|
||||
- enabling and supporting (switching from coding wizard to support role)
|
||||
- boundaries vs collaboration
|
||||
|
||||
- relationship between industry and FOSS
|
||||
- what is the main currency (money vs energy)
|
||||
- bus factor
|
||||
|
||||
- feedback from universities regarding Haskell tooling
|
||||
- respect other projects when contributing
|
||||
- enabling and supporting (switching from coding wizard to support role)
|
||||
|
||||
- project life cycles
|
||||
- support
|
||||
- stability vs. ..
|
||||
- boundaries vs collaboration
|
||||
- trust, respect, relationship
|
||||
- working mode in open source
|
||||
- dealing with expectations
|
||||
- how to test (on the end users system)
|
||||
- what if you diverge from the happy path
|
||||
|
||||
- stability vs. ..
|
||||
- why is stability an interesting goal?
|
||||
|
||||
|
||||
221
nus.md
221
nus.md
@ -1,6 +1,24 @@
|
||||
% Two decades of Open Source
|
||||
% Julian Ospald
|
||||
% Sep 20, 2024
|
||||
---
|
||||
output:
|
||||
slidy_presentation:
|
||||
duration: 45
|
||||
title: Two decades of Open Source
|
||||
author: Julian Ospald
|
||||
date: Sep 20, 2024
|
||||
---
|
||||
|
||||
## Follow the presentation {.centered}
|
||||
|
||||
{#id .class height=500px}
|
||||
|
||||
## Structure of this talk
|
||||
|
||||
1. Introduction (about me and my career)
|
||||
2. Open Source (what it is and its value)
|
||||
3. First chapter: Gentoo and package management
|
||||
4. Second chapter: GHCup
|
||||
5. Third chapter: Haskell Core Libraries
|
||||
6. Lessons learned
|
||||
|
||||
# Introduction
|
||||
|
||||
@ -80,7 +98,7 @@
|
||||
* will stop maintenance at some point
|
||||
* don't care much about their users
|
||||
|
||||
# Gentoo and package management
|
||||
# First chapter: Gentoo and package management
|
||||
|
||||
## What is Gentoo
|
||||
|
||||
@ -146,7 +164,7 @@ src_install() {
|
||||
- shipping a "chain" instead of a single artifact
|
||||
* high impact on small mistakes (e.g. assuming a specific shell)
|
||||
|
||||
## Packaging challenges (pt 2.)
|
||||
## Packaging challenges (pt. 2)
|
||||
|
||||
* communication between teams/maintainers
|
||||
* execution of large changes
|
||||
@ -166,18 +184,19 @@ src_install() {
|
||||
* combining components to a coherent system (init system, coreutils, kernel, ...)
|
||||
* a choice of **defaults**
|
||||
|
||||
## Why Gentoo made me a better programmer
|
||||
## Programming lessons
|
||||
|
||||
* primary packaging skill: being meticulous
|
||||
* small mistakes -> big impact
|
||||
* being as precise as possible about what you want to achieve
|
||||
* long term maintenance of small code pieces
|
||||
* intense review culture
|
||||
* strict policies and workflow guidelines
|
||||
* how to learn complex system
|
||||
|
||||
# GHCup
|
||||
# Second chapter: GHCup
|
||||
|
||||
## Demo
|
||||
## Demo {.centered}
|
||||
|
||||
{#id .class height=500px}
|
||||
|
||||
@ -232,14 +251,6 @@ curl -s -L \
|
||||
- VSCode, stack, cabal-install integration
|
||||
* {#id .class width=32 height=32px} CI provisioning (e.g. github actions)
|
||||
|
||||
## The difference to Gentoo
|
||||
|
||||
* one-man project (mostly)
|
||||
* much tighter coupling between upstream (e.g. GHC developers) and downstream (GHCup developers)
|
||||
* heavier on relationship issues
|
||||
* much more responsibility
|
||||
* position of authority
|
||||
|
||||
## Relationships in detail
|
||||
|
||||
Dependencies:
|
||||
@ -255,7 +266,7 @@ Dependencies:
|
||||
- platform support
|
||||
- binary distributions (the `.tar.gz`/`.zip`)
|
||||
|
||||
## Relationships in detail
|
||||
## Relationships in detail (pt. 2)
|
||||
|
||||
Dependents:
|
||||
|
||||
@ -269,3 +280,179 @@ Dependents:
|
||||
- 🧰 tools
|
||||
- [vscode-haskell](https://github.com/haskell/vscode-haskell), [Haskell playground](https://play.haskell.org/), [nvim-lsp-installer](https://github.com/williamboman/nvim-lsp-installer)
|
||||
|
||||
## Programming lessons
|
||||
|
||||
* writing a small single-purpose program from scratch
|
||||
* how to design command line interfaces
|
||||
* high impact of decisions (not just mistakes)
|
||||
- bugs now affect GitHub CI and companies
|
||||
- can make "Haskell" look bad
|
||||
* no one to review
|
||||
- => review your own code
|
||||
* constantly thinking about ways to improve reliability
|
||||
- can't rely on anyone else to catch bugs
|
||||
|
||||
## The difference to Gentoo
|
||||
|
||||
Both deal with installation, but...
|
||||
|
||||
* more code to maintain (not just packaging) for me
|
||||
* one-man project (mostly)
|
||||
* much tighter coupling between upstream (e.g. GHC developers) and downstream (GHCup developers)
|
||||
* heavier on relationship issues
|
||||
* less dependencies, but much more responsibility
|
||||
* position of authority
|
||||
- what to consider?
|
||||
* most of my work today is support
|
||||
|
||||
# Third Chapter: Haskell Core Libraries
|
||||
|
||||
## What are Haskell Core Libraries?
|
||||
|
||||
* bundled with the compiler
|
||||
* fundamental building blocks (primitives)
|
||||
* base library
|
||||
- available to all programs by default
|
||||
- contains the "Prelude" (standard library)
|
||||
|
||||
## Core libraries I maintain
|
||||
|
||||
* filepath
|
||||
* unix
|
||||
* os-string
|
||||
* file-io
|
||||
|
||||
## Challenges
|
||||
|
||||
* changes are extremly expensive
|
||||
* writing good primitives is hard (non-specific APIs)
|
||||
* lots of odd knowledge
|
||||
- e.g. Windows filepaths
|
||||
- `C:foo`
|
||||
- `/bar`
|
||||
- `\\?\GLOBALROOT\Device\Harddisk0\Partition2\foo\bar`
|
||||
- Posix standard
|
||||
* portability
|
||||
|
||||
## Core Libraries Committee
|
||||
|
||||
* 7 members
|
||||
* manages API changes of `base` only
|
||||
* requires a proposal
|
||||
* requires impact assessment for breaking changes
|
||||
* requires an up-front implementation of the change
|
||||
* ensures other core libraries have active maintainers
|
||||
* does not interfere with maintenance
|
||||
|
||||
## Driving changes across core libraries (case study)
|
||||
|
||||
Abstract FilePath Proposal:
|
||||
|
||||
- Haskell String type: `type String = [Char]`
|
||||
- `Char` is a unicode code point
|
||||
- not bytes
|
||||
- is interpreted (decoded)
|
||||
- depends on locale
|
||||
- affects most core libraries
|
||||
- implement as a breaking change (base), or...
|
||||
- in "user-space"
|
||||
- lack of higher authority
|
||||
- building consensus
|
||||
- convincing multiple maintainers
|
||||
- patching many libraries
|
||||
- open source politics
|
||||
|
||||
## Programming lessons
|
||||
|
||||
* how to design good primitives
|
||||
- as opposed to abstractions
|
||||
* considering every impact of API changes
|
||||
* doing history research on past design choices
|
||||
- important design decisions may not be documented
|
||||
- may look innocent
|
||||
- chaning them might be devastating
|
||||
|
||||
# Lessons Learned
|
||||
|
||||
## Collaboration
|
||||
|
||||
::: incremental
|
||||
|
||||
* main currency in Open Source is energy
|
||||
* treat contributors like kings
|
||||
* be mindful about boundaries (tricky balance)
|
||||
* respect other projects workflows
|
||||
* driving large changes requires
|
||||
- consensus
|
||||
- support
|
||||
- a good value proposition
|
||||
- a good execution plan (risk, breakage, ...)
|
||||
* Haskell Foundation
|
||||
|
||||
:::
|
||||
|
||||
## Project maintenance
|
||||
|
||||
::: incremental
|
||||
|
||||
* dicatorships work, but are not sustainable
|
||||
* plan for your departure
|
||||
* bus factor is your constant enemy
|
||||
* good decision making processes
|
||||
- lightweight when risk is low
|
||||
- elaborate when risk is high
|
||||
* actively think about the contribution experience
|
||||
- comment early
|
||||
* how to maintain the project vision?
|
||||
|
||||
:::
|
||||
|
||||
## User Experience
|
||||
|
||||
::: incremental
|
||||
|
||||
* UX is harder than CS
|
||||
* yet often an afterthought
|
||||
* toolchains often lack a holistic UX vision
|
||||
* UX vision gets easily lost in "maintenance mode"
|
||||
* feature creep
|
||||
* maintainer turnover
|
||||
* collective decisions
|
||||
* UX is a fascinating problem (e.g. OS)
|
||||
- plug & play (intuition... about interfaces)
|
||||
- happy path (control)
|
||||
- defaults (expectations... about behavior)
|
||||
|
||||
:::
|
||||
|
||||
## Stability vs Progress
|
||||
|
||||
* 🤼 conflicting goals
|
||||
* ⚔️ breaking API can have large rippling effects
|
||||
- experience report of a facebook engineer on GHC upgrades
|
||||
* 🗼 small breakages add up
|
||||
- large projects have hundreds of dependencies
|
||||
* 🗣️ many discussions in the Haskell community
|
||||
- upgrade cost
|
||||
- language changes (Haskell report)
|
||||
- academic background of Haskell (academia vs industry?)
|
||||
- the role of committees
|
||||
* ⚖️ how to strike a balance?
|
||||
- SemVer does not solve it (why?)
|
||||
|
||||
## Composition
|
||||
|
||||
* I love small programs
|
||||
* categories of composition
|
||||
- functions
|
||||
- libraries
|
||||
- programs
|
||||
* unix philosophy
|
||||
- 🛠️ do one thing and do it well
|
||||
- ⚗️ pipes, compose stdout and stdin (re-usable)
|
||||
* how to make your project composable?
|
||||
- https://clig.dev/
|
||||
|
||||
## Questions/Arguments? {.centered}
|
||||
|
||||
{#id .class height=500px}
|
||||
|
||||
Loading…
Reference in New Issue
Block a user