kisscommunity

Subject Where Do We Go From Here?
From    Dilyn Corner <dilyn.corner@tutanota.com>
Date    Tues, 23 Feb 2021 5:00:00 -0500

Where to begin!

First, I would like to thank all of who participated in the poll we recently
ran! We had over a hundred responses, which by itself I found quite amazing -
Dylan's little project turns out to be bigger than I had expected. I certainly
wasn't anticipating the outcome we had, but I appreciate that so many of you
thought of me. For those of you who didn't want a new BDFL, I do not blame you;
I myself have been happily maintaining all of my own packages for several months
now with few issues. The beauty of KISS is that you can be your own BDFL :)

I'm certain many of you are curious what I plan to do with these newfound powers
and responsibilities, so I thought I would take some time to explain my plans,
goals, and intentions. I have a tendency to be overly verbose, so I'll break
this up into sections; feel free to read as much or as little as you'd like.

The Guidestones                                                            [1.0]
The Package Manager                                                        [2.0]
The Website                                                                [3.0]
The Repositories                                                           [4.0]
Reddit & IRC                                                               [5.0]
Structure                                                                  [6.0]


[1.0] THE GUIDESTONES
________________________________________________________________________________

I take Dylan quite seriously in his declaration that "[the Guidestones] are a
set of notes which make KISS... KISS". They're explicit, simple, and focused. I
think these principles are what have given us the kind of community we have,
with projects like $/eudaldgr/kiss-live $/wyvertux/wyverkiss $/gkisslinux/grepo
$/Himmalerin/kiss-wayland springing up to fill the gaps and needs of users, by
users. And I think the 'by users' part is the most important thing. That users
want to contribute and explore ideas, concepts, and features make KISS what it
is - a maleable yet sturdy base on which you can create whatever you want.

Specifically, I see no reason to change the goals that define the main
repositories. Dylan had previously spoken about switching to Wayland, only when
it finally became apparant that using Xorg would be essentially impossible. See
his discussion in IRC here:
https://freenode.logbot.info/kisslinux/20200912#c5073615
Drew Devault will yet have his day, it seems.

KISS will continue to target X86_64 primarily, and will be English only. There
should be few if any new packages added to the core repo. The most complicated
thing a majority of people want is a graphical environment that runs a
webbrowser, and that is what they will get. By default, officially supported :)

As such, I see no good reason to change much of the Guidestones. They are in
place for good reason, and altering them should be a last resort. While my own
personal repository is quite different from the core repository - strictly using
Wayland and pursuing software under nonGPL licenses - I have no interest in
imposing these restrictions on KISS as a whole. If that is something a user
wants, they can do it themselves, like I did.

The point on the existence of a 'below governance structure' is an important
one; I do not wish to change this rule, and I will describe at the end what I
intend to do so that the KISS project can avoid going through these last few
months again.


[2.0] THE PACKAGE MANAGER
________________________________________________________________________________

Dylan was previously working on K, a version of kiss written in C. Recently,
$/illiliti/king has taken up a similar project. I commend the effort, and it
will be interesting to see how it turns out! Much like Dylan said when he
started working on it, however, I have no plans of changing the fundamentals of
the package manager much if at all - it is, in my opinion, feature complete, and
most of our focus on it should be on extensions like kiss-orphans and kiss-graph
than packing new lines of code into kiss itself.

There have consistently been talks of adding a maintainer and license file to
packages, adding metadata to the repositories, and otherwise tweaking packages.
My opinion on the matter is that, without good technical reason for doing so,
the way packages are made and distributed is precisely the minimum required, and
maximally efficient. Adding a maintainer file defeats the purpose of using git,
for instance; while a one-line plaintext file may be easier to parse than git
log, kiss-maintainer seems to be more than adequate. A license file or a line in
the version file is interesting, but I don't think ultimately necessary - all
software in the main repositories is necessarily F(L)OSS; extended concerns
about which license is used by what package can be answered by simply
downloading the source and investigating one of the files inside (usually
COPYING or LICENSE). However, should users wish to install the license file WITH
the package, I have no issue with allowing a one-liner to the end of community
build files:

install -Dm644 COPYING "$1/usr/share/$1/$1.$licensename"

This wouldn't violate the package guidelines, it's easily greppable for curious
users, and everyone else can check the sources.

There are a few small bugs in kiss; the infamous KISS_SU bug which caused a
flurry of Reddit posts for instance, along with a few other ones. I would hope
to fix these, and am more than happy to accept patches which add small, quality
of life changes that do not fundamentally alter the package manager - in my
eyes, kiss is essentially 'feature complete'.


[3.0] THE WEBSITE
________________________________________________________________________________

With Dylan's disappearance, many things have slowly crumbled. The domain expired
earlier this month, SSL certificates have expired, and of course the main
repositories have been untouched. There has been a lot of discussion on IRC
since January about what to do should Dylan not return before the website
expires, and a loose plan emerged.

Ideally, we (I, I guess) will be purchasing the domain when it goes up for
auction sometime in March. This is to ensure some level of continuuity between
Dylan's time as BDFL and the time we are in now.

Conversations have been had on IRC (we talk a lot on IRC, you should look into
joining us) and many users showed interest in taking a self-hosted direction
with many features of KISS instead of relying so much on GitHub, which many
users take issue with. My primary concern with self-hosting is that we would be
at the mercy of the hoster. And while I would certainly choose someone
trustworthy, that doesn't change the fact that we would be relying on a system
in some closet somewhere in the world. The distributed nature of a host like
GitHub is useful, if not ultimately necessary.  Mirroring the site, on the other
hand, I have no real issue with. If people would like to mirror the website or
the repositories, a few links can be added to the main repositories and site
mentioning their existence. I will be looking into doing some sort of mirroring
as well.

Speaking of mirrors, $/mcpcpc has been working on converting the website away
from the bare-bones, minimalistic plaintext the website is currently utilizing
and turning it into something more rich. You can find it here https://mcpcpc.com/k1ss
While his efforts are appreciated, one of the beauties of the site as it stands
is how simple and lightweight it is - honestly, a feat one sees rarely in the
Modern Web(tm). I don't intend on making their work the official incarnation of
the site, but users are certainly more than welcome to use it instead if that is
what they would prefer. KISS is essentially self-documenting, and bundling the
website with the package manager is convenient and, I think, best done from the
simplest sources possible.

People have been talking about switching to Gemini. While this is perhaps
arguably more inline with our goals and principles than the 'average Web', I
fear it is far too restrictive - but maybe this is just my 'old man yells at
clouds' moment. Again, I am not opposed to people mirroring the site to Gemini,
and I am fine with making reasonable and good changes to the site if that would
help. And, of course, linking to their work for the users who want that option.


[4.0] THE REPOSITORIES
________________________________________________________________________________

Much like the website, people are curious about where the repositories should be
- going even as far as to suggest we drop git entirely for fossil.  First and
foremost, I think switching to fossil is at best incredibly difficult. git is
so deeply ingrained in the functioning of KISS, a lot of work would have to be
done for such a transition. That being said, I see no good reason it couldn't
theoretically be supported - if we do not lock users into coreutils or init, why
should we lock them into VCS? I will be exploring this soon(tm) in my own
repository. As it stands, KISS will be sticking to git for a while, if not
forever.

Gaining access to $/kisslinux is probably never going to happen, so
hopefully we will be able to telegraph to the world to look elsewhere. An
interim repository at $/kiss-community was setup by a few members, and I see no
good reason to change from it - no sense in making users switch to
Yet Another Upstream ReposiTory.

As far as hosting the repositories on GitHub is concerned, my worries for
self-hosting the website carry over here. Relying on a black box in someone's
closet is worse, I think, than on multiple black boxes scattered across the
world. Our current single point of failure is the BDFL, not the hardware of some
poor soul. Mirroring the repositories, however, I am fine with.  Honestly, I
have never done such a thing - the most I've ever hosted is a media server off
of a screendead laptop in 2008. Hosting outside of GitHub will be explored and
proper announcements made should something change, but there will always at
least be a mirror of the repositories on GitHub. Here it was born, and here it
shall stay.


[5.0] REDDIT & IRC
________________________________________________________________________________

I got notified literally while writing this that my request for Mod privileges
on the subreddit has been granted, so I suspect several of you will have gotten
here from there. Hello! While Dylan may not have been hands-off with the
subreddit by choice but rather by ignorance, I will take a similar track;
pinning things that are relevant, announcing changes as they come, etc. I'll
always be around in there, silently watching...

Somebody other than me has submitted a request for the IRC channel.  I'm not
terribly concerned with the IRC - it barely had moderation to begin with, some
might say...

Mostly, I'd just like to update the Song of the Day more than once every five
months :) The IRC channel will continue, under someone's (or noone's) control,
in perpetuity. No plans for Discord, Matrix, Telegram, Whatsapp, Slack, Teams,
or Newsgroups. Y'all are more than welcome to start your own, if you'd like. But
I won't be joining them.


[6.0] STRUCTURE
________________________________________________________________________________

This is, I think, the most important topic to tackle. Obviously we were left out
in the cold rather abruptly. I didn't terribly mind it - Dylan did after all say
that he wanted the distro to be easily maintainable my one person. Plus, I don't
rely on community very much at all for my packages. But most people don't want
to bother with checking for their own updates and making their own packages; who
can blame them? Eliminating duplication of effort is important. I don't know how
long I'll be around (I plan to live forever, so far so good), and I'd like to
see the repositories, wiki, website, etc. be more resilient and avoid having a
single point of failure.

The point of having a BDFL is to ensure total control over the direction,
trajectory, and development of the project. My primary aim is to follow the
things Dylan specified as closely as possible. The point of a BDFL is NOT to
disrupt the experience of users, but to ensure consistency and focus for the
project. When it comes to a Linux distribution, updates in large part means
security updates and bug fixes. I want to ensure users aren't exposed due to my
own failure or disappearance. Dylan was resistant to letting other people
maintain even just community; I have a different take.

* The responsibility of checking packages for correctness and merging PRs in the
main repositories falls to me, with one extra user having access to the main
repo and (a potentially different) user having access to community. My intention
here is not that they have just as much responsibility or authority over the
repository, but instead to (1) merge PRs and respond to issues should they stay
open for 'too long', and (2) to ensure that, should something happen to me, the
repositories carry on. Think of them not as assistants, but failsafes.

* The responsibility of releasing updated tarballs of KISS falls to me. Nobody
else should feel compelled to do this, unless I'm just *poof* gone.

* The responsibility of keeping up with the website and wiki falls to me, with
one other, different than the previous persons, also having access.

The point is not to have multiple people in charge. Changes to anything
regarding the package manager, inclusion in the repositories, adjustments to
documentation, etc.etc.etc. should all go through me.
The point is instead to ensure that, should I disappear or be deposed because
I'm a jerk, users aren't left exposed. I don't want this to be Void. I don't aim
to hold anyone's hand, but at the same time there is no good reason users of a
distribution should not be allowed to opt into having their updates funneled
through a singular channel.  That is, after all, the point - if users don't want
that, they can choose otherwise.

I have no announcements of who these people will be, but the changes won't
effect much of how you would expect things to function if Dylan were still here.

I am of course willing to hear feedback on this stark shift from Dylan's
previous policy, and suggestions on any of this are welcome. You can always find
me in IRC #kisslinux (I always read the logs), you can talk to me at
$/dilyn-corner or on Reddit (u/dilyn), and email is always an option:
dilyn.corner@tutanota.com. If you find my address, you can even mail me a
letter if you want.


In conclusion, thanks for your faith.

___