[Dev] Goals/direction for the coming year

[Luke Shumaker]

On Fri, 31 Mar 2017 16:38:28 -0400,
fauno wrote:
> 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
anyway...
 
> > 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
first.

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
> 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)

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
code itself.

> >> 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
> though.

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
with that.

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
> wikis.

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.

-- 
Happy hacking,
~ Luke Shumaker