[Dev] Goals/direction for the coming year

[fauno]

Luke Shumaker <lukeshu at lukeshu.com> writes:
> So the packager would build the package locally, the same as they do
> now.  When the upload it, it would kick off jobs on 2 different build
> servers.  The package isn't actually published until the 2 build
> servers finish.  If either of those 2 jobs comes back different than
> what the packager uploaded, then the packager gets a notification that
> something is probably wrong with their PKGBUILD.  If they both come
> back the same, then it runs db-update and publishes the package.

do we have the software for this?

> Everyone in hackers.git should have access to the git repository of
> `/etc` on either server (`/etc/.git`).  It's readable only by root,
> but everyone should have sudo (a somewhat terrifying thought).

hehe

> It does include secrets.  I'm not opposed to pruning the secrets out
> of the repo and publishing them, but we'd have to be very careful
> about no secrets ever accidentally getting added.  Somewhere in my
> .bash_history on one of the servers is a pretty exclude good list of
> secrets passed to `git diff` commands.

or a .gitignore maybe?  i just thought of a pre-commit hook that
inspects commited files to check they don't have pem style headers.  it
would've to be more smart to find actual password thought.

>> i'm not keen on puppet/ansible/etc but i do think infrastructure needs
>> to be reproducible,
>
> I thought I agreed with you, then I found Holo <holocm.org>.  Then I
> found the documentation lacking, so I read the source to figure out
> how it worked.  Then I found a bunch of edge-cases that I care about,
> and spent way too many hours filing pull requests :)
>
> Anyway, I've slowly been trying to move all of the server
> configuration in to holo (Ansible has playbooks, Holo has holograms)
> <https://git.parabola.nu/server/config.git/>.  I'm not using Holo's
> native language (`holo-build`) though, I'm using plain
> bash/PKGBUILDs.  I think holo-build is valuable if you are deploying
> your holograms to DPKG or RPM systems, but I don't think that it buys
> you much on Pacman.

ha! i've been looking at holo for another project, but i dislike toml
syntax and i also saw it recommends to put the contents of files inside
the package description (instead of having it on a directory and just
`install --mode` it)

i've been rolling out my own set of makefiles, with great success and
some drawbacks, but i won't push it here (i haven't published them
either).

> If we're talking about GitLab, we should probably also consider Gitea
> (the community fork of Gogs)?

why was it forked?  gogs/gitea could be useful too, though i don't have
experience with any of them (i was waiting for the pull request feature
and they i waited too long)

> I know we love our Adhocracy, but I do think having tiers or
> categories of developer-ness would help.  Going from zero to suddenly
> having full credentials, same as one of the long-term core developers,
> is like drinking from a fire hose.  "Welcome to Parabola, I've given
> you access to push packages, also you're now root on the
> servers. Hopefully you have good opsec!" "WAIT, WHAT!?"

hahaha
>> a policy we stablished on another group i participate is for new people
>> to have a "shadow", a sort of sponsor, one or two hackers that can show
>> you the ropes, are ready to be queried when you're in doubt on how to do
>> something and maybe ask you to do things (delegation is really
>> important!).
>
> +1

i can draft something if others see this useful :)

>>               we also have irregular get togethers to have beers and
>> just chat, but i don't see it happening here :P
>
> You don't need to rub it in! :)

SOON

>> - Wiki
>> 
>> is it alive?
>
> I'm *actually 100%* burnt out on the wiki.
>
> The previous wiki was bad because it didn't have MediaWiki syntax, and
> so copying things form ArchWiki was hard.
>
> This wiki is bad because it doesn't have plain files; everything is
> locked away in MySQL.  Merging from ArchWiki is easier, but tedious.
>
> Now newer hackers that have only been around for this wiki are
> advocating to a return to a files-based non-MediaWiki.
>
> Both are bad.
>
> For a bit I was working on fork of MediaWiki that uses git as the
> backend instead of SQL.

we've been over this on another project (i'm on too many projects) and
in the end, when we installed mediawiki it turned to be the most used
wiki of all.

the syntax is horrible, but you can write things on markdown and convert
from and back to mediawiki using pandoc.

i'd like to see the Translation plugin installed, which helps
translators keep up to date with changes in articles.  and people can
notice when the article on a language is outdated.  i don't know how
much work would it be to convert the current translation system to it
though.

it would be interesting to be able to pull and prune articles from
archwiki, so you don't have to default to it (i almost never use
parabola wiki).  also, it seems every attempt to make mediawiki
distributed is dead (or as dormant as cthulhu).

there're some special arguments to access the article on mediawiki
syntax or rendered but without the site theme surrounding it which i
think could be useful to build a tool that can pull and push between
wikis.

such tool could also present diff'ing tools for humans to solve
conflicts :)

there're also plugins like mediawikifs or vim-mediawiki (iirc) that
allow you to edit a mw instance as regular files.


-- 
.oÓ)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 617 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20170331/ec60b3d7/attachment.sig>