[Dev] Goals/direction for the coming year
lukeshu at lukeshu.com
Fri Mar 31 21:28:46 GMT 2017
On Fri, 31 Mar 2017 16:38:28 -0400,
> 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?
Not yet :) But if we're building some custom build server software
> > 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.
Yeah, .gitignore is fine, we'd just have to prune the existing commits
I do want to track the secrets though; so perhaps have a separate
(private) repository for secrets? We used to do that with SSL certs,
but that was just to sync them between servers.
> >> 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
> > 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)
The Gogs developers don't really accept pull requests or
contributions. The bus-factor of Gogs is roughly 1. Gitea exists to
fork the stewardship and community (well, fork the stewardship in
order to enable a community to form), more than it does to fork the
> >> 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 :)
If you have an idea of what it needs to include, that would be good.
> >> - 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.
pandoc is best way of writing mediawiki
> 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
Me either. I used to be really invovled with the wiki, but like I
said, I've burnt out.
> 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).
Oh, I was also working on a better git-mediawiki-remote. I tried
using plain git-mediawiki-remote, but there ended up being problems
Being able to handleit as a git merge would be really cool.
> 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
For basic pages, that works well enough, but once you start using
transclusion and templates, it starts to be troublesome.
> 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.
~ Luke Shumaker
More information about the Dev