* [PATCH v2 2/2] doc: start reproducibility document
2020-04-13 11:32 7% [PATCH v2 0/2] rerolled doc updates Eric Wong
@ 2020-04-13 11:32 6% ` Eric Wong
0 siblings, 0 replies; 4+ results
From: Eric Wong @ 2020-04-13 11:32 UTC (permalink / raw)
To: meta
Not new ideas, just gathering thoughts.
Thanks to Kyle Meyer for a grammar fix.
---
Documentation/reproducibility.txt | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/reproducibility.txt
diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt
new file mode 100644
index 00000000..af3e5366
--- /dev/null
+++ b/Documentation/reproducibility.txt
@@ -0,0 +1,29 @@
+reproducibility => forkability
+------------------------------
+
+The ability to fork a project is a checks and balances
+system for free software projects. Reproducibility is key
+to forkability since every mirror is a potential fork.
+
+git makes the code history of projects fully reproducible.
+public-inbox uses git to make the email history of projects
+reproducible.
+
+Keeping all communications as email ensures the full history
+of the entire project can be mirrored by anyone with the
+resources to do so. Compact, low-complexity data requires
+less resources to mirror, so sticking with plain-text
+ensures more parties can mirror and potentially fork the
+project with all its data.
+
+Any private or irreproducible data is a barrier to forking.
+These include mailing list subscriber information and
+non-federated user identities. The "pull" subscriber model
+of NNTP and Atom feeds combined with open-to-all posting
+means there's no need for private data.
+
+If these things make power hungry project leaders and admins
+uncomfortable, good. That was the point. It's how checks
+and balances ought to work.
+
+Comments, corrections, etc welcome: meta@public-inbox.org
^ permalink raw reply related [relevance 6%]
* [PATCH v2 0/2] rerolled doc updates
@ 2020-04-13 11:32 7% Eric Wong
2020-04-13 11:32 6% ` [PATCH v2 2/2] doc: start reproducibility document Eric Wong
0 siblings, 1 reply; 4+ results
From: Eric Wong @ 2020-04-13 11:32 UTC (permalink / raw)
To: meta
Thanks to Kyle and Leah for comments.
Eric Wong (2):
doc: add technical/whyperl
doc: start reproducibility document
Documentation/reproducibility.txt | 29 +++++
Documentation/technical/whyperl.txt | 170 ++++++++++++++++++++++++++++
2 files changed, 199 insertions(+)
create mode 100644 Documentation/reproducibility.txt
create mode 100644 Documentation/technical/whyperl.txt
Interdiff against v1:
diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt
index 4e56ada4..af3e5366 100644
--- a/Documentation/reproducibility.txt
+++ b/Documentation/reproducibility.txt
@@ -3,7 +3,7 @@ reproducibility => forkability
The ability to fork a project is a checks and balances
system for free software projects. Reproducibility is key
-to forkability since every mirror is potential fork.
+to forkability since every mirror is a potential fork.
git makes the code history of projects fully reproducible.
public-inbox uses git to make the email history of projects
diff --git a/Documentation/technical/whyperl.txt b/Documentation/technical/whyperl.txt
index b0a0d16b..11ae7c2a 100644
--- a/Documentation/technical/whyperl.txt
+++ b/Documentation/technical/whyperl.txt
@@ -11,7 +11,7 @@ Other languages and runtimes may eventually be a possibility
for us, and this document can serve as our requirements list
for possible replacements.
-As always, comments and corrections and additions welcome at
+As always, comments, corrections and additions are welcome at
<meta@public-inbox.org>. We're not Perl experts, either.
Good Things
@@ -26,9 +26,9 @@ Good Things
have to waste bandwidth or space with giant toolchains or
architecture-specific binaries.
- Furthermore, Perl documentation is typically installed as
- manpages, allowing users to quickly access and learn it
- offline.
+ Furthermore, Perl documentation is typically installed
+ locally as manpages, allowing users to quickly refer
+ to documentation as needed.
* Scripted, always editable by the end user
@@ -48,15 +48,14 @@ Good Things
* Predictable performance
While Perl is neither fast or memory-efficient, its
- performance and memory use are predictable and does not
- require GC tuning by the user.
+ performance and memory use are predictable.
public-inbox is developed for (and mostly on) old
hardware. Perl was fast enough to power the web of the
late 1990s, and any cheap VPS today has more than enough
RAM and CPU for handling plain-text email.
- Low hardware requirements increases the reach of our software
+ Low hardware requirements increase the reach of our software
to more users, improving centralization resistance.
* Compatibility
@@ -79,12 +78,12 @@ Good Things
GNU/Linux distros and BSD ports.
There should be no need to rely on language-specific
- package managers such as cpan(1), those systems increase
+ package managers such as cpan(1). Those systems increase
the learning curve for users and systems administrators.
* Compactness and terseness
- Less code generally means less bugs. We try to avoid the
+ Less code generally means fewer bugs. We try to avoid the
"line noise" stereotype of some Perl codebases, yet still
manage to write less code than one would with
non-scripting languages.
@@ -160,7 +159,7 @@ being used, they're just not interesting.
* Lightweight threading
While lightweight threading implementations are
- convenient, they tend to be significantly heavier than a
+ convenient, they tend to be significantly heavier than
pure event-loop systems (or multi-threaded event-loop
systems)
^ permalink raw reply related [relevance 7%]
* Re: [RFC] doc: start reproducibility document
2020-04-07 9:37 6% [RFC] doc: start reproducibility document Eric Wong
@ 2020-04-08 0:24 7% ` Kyle Meyer
0 siblings, 0 replies; 4+ results
From: Kyle Meyer @ 2020-04-08 0:24 UTC (permalink / raw)
To: Eric Wong; +Cc: meta
Eric Wong <e@yhbt.net> writes:
> Not new ideas, just gathering thoughts.
Thanks. Ideas will are always be new to some :) It's nice to make them
easy to discover for someone exploring the project tree.
It reads well to me.
> +The ability to fork a project is a checks and balances
> +system for free software projects. Reproducibility is key
> +to forkability since every mirror is potential fork.
Missing an "a" in front of "potential".
^ permalink raw reply [relevance 7%]
* [RFC] doc: start reproducibility document
@ 2020-04-07 9:37 6% Eric Wong
2020-04-08 0:24 7% ` Kyle Meyer
0 siblings, 1 reply; 4+ results
From: Eric Wong @ 2020-04-07 9:37 UTC (permalink / raw)
To: meta
Not new ideas, just gathering thoughts.
---
Documentation/reproducibility.txt | 29 +++++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
create mode 100644 Documentation/reproducibility.txt
diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt
new file mode 100644
index 00000000..4e56ada4
--- /dev/null
+++ b/Documentation/reproducibility.txt
@@ -0,0 +1,29 @@
+reproducibility => forkability
+------------------------------
+
+The ability to fork a project is a checks and balances
+system for free software projects. Reproducibility is key
+to forkability since every mirror is potential fork.
+
+git makes the code history of projects fully reproducible.
+public-inbox uses git to make the email history of projects
+reproducible.
+
+Keeping all communications as email ensures the full history
+of the entire project can be mirrored by anyone with the
+resources to do so. Compact, low-complexity data requires
+less resources to mirror, so sticking with plain-text
+ensures more parties can mirror and potentially fork the
+project with all its data.
+
+Any private or irreproducible data is a barrier to forking.
+These include mailing list subscriber information and
+non-federated user identities. The "pull" subscriber model
+of NNTP and Atom feeds combined with open-to-all posting
+means there's no need for private data.
+
+If these things make power hungry project leaders and admins
+uncomfortable, good. That was the point. It's how checks
+and balances ought to work.
+
+Comments, corrections, etc welcome: meta@public-inbox.org
^ permalink raw reply related [relevance 6%]
Results 1-4 of 4 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2020-04-07 9:37 6% [RFC] doc: start reproducibility document Eric Wong
2020-04-08 0:24 7% ` Kyle Meyer
2020-04-13 11:32 7% [PATCH v2 0/2] rerolled doc updates Eric Wong
2020-04-13 11:32 6% ` [PATCH v2 2/2] doc: start reproducibility document Eric Wong
Code repositories for project(s) associated with this public inbox
https://80x24.org/public-inbox.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).