On Fri, 31 Mar 2017 16:38:28 -0400, fauno wrote: > Luke Shumaker <[email protected]> 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 _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
