[Dev] Goals/direction for the coming year

Luke Shumaker lukeshu at lukeshu.com
Fri Mar 31 19:44:42 GMT 2017

On Fri, 31 Mar 2017 10:03:39 -0400,
fauno wrote:
> >  - Reproducible builds
> [...]
> >    As far as enforcing reproducible builds (which would be the *very*
> >    last step), I was thinking that it should require the package to be
> >    built 3 different times: 2 by build servers, and once by a human.
> does it involve building three autonomous toolchains from scratch? :P

Oh, I forgot to say that "3 different times" wouldn't apply to
packages imported from Arch.

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.

> >  - Code reviews
> >
> >    So this one is tricky.  It requires community buy-in.  I'd love to
> >    see "mandatory" code reviews on every code and infrastructure
> >    change we can viably do that for.  This is NOT primarily to catch
> >    mistakes.  This is more to make sure that at least 2 humans know
> >    about every change that is made.
> >
> >    This is about documenting changes, and spreading knowledge through
> >    the community of developers.  This is not about getting a rubber
> >    stamp saying "lgtm".
> >
> >    I'm not sure what the tooling around this should look like.
> for infrastructure, at least a way to review changes after the fact.  it
> would be interesting to experiment with public configuration (minus
> secrets such as session keys, privkeys of all sorts, etc) so /etc gets
> pushed to our public repos, or something built publicly is pushed to
> /etc.

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

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.

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

>                     so the next urgent server change doesn't take two
> weeks of our time (which i don't have much lately as you know so i can't
> help though i'd like to)
> >  - Better bug tracker 
> >
> >    In the last 2 years, I've opposed all proposals to switch bug
> >    trackers.  Not because I like our tracker.  I was tired of change.
> >    Our current tracker is the 4th tracker the project has had in the 6
> >    years I've been with the project.
> >
> >    I don't want churn.  I don't want "let's try X", only for us to
> >    decide X is bad a couple months or a year later.  I want a good
> >    discussion first.  I want this to be a carefully considered
> >    decision.
> my fault :(
> >    Our tracker is bad.  Maybe the problem is Redmine, maybe the
> >    problem is how we have Redmine configured.  It's hard for users to
> >    report bugs.  It's hard for potential contributors to find simple
> >    bugs to get started with.  And I don't think any of the current
> >    devs like it.  I think everyone who has opposed a change have
> >    opposed it for the same reason I have.
> i'm thinking github's issue tracker is simple and featureful enough to
> be usable by anyone, but of course we won't use that.  gitlab is similar
> and you can also reply by email, but it's very heavy on resources and,
> at least on the instance i run for work, fairly unstable.  i don't know
> of any issue tracker similar to git{hub,lab}'s that isn't integrated to
> a vcs.

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

We could start doing work on <https://gitlab.com/parabola/>, but I'm
happier leaving it as just a dumb mirror.

> >    I'm not sure that we want to participate in Google Summer of Code,
> >    but today at LibrePlanet, I heard a very compelling argument from
> >    Tom Callaway that structuring your stuff such as to be eligible for
> >    GSoC, is a good way inviting people to be involved.  I was
> >    persuaded.
> what would this entail?

Oh man, he made it sound like there was a whole document, but now that
I search for it, the answer is "have already published some free
software, and have at least 2 people (1 mentor, 1 administrator)."

So I'm going to assume the soft requirements:

 - Decent mentoring program for new contributors
 - Task tracker that associates difficulty with tasks, so that a
   would-be contributor can get an idea of what they could possibly do
   in X ammount of time.

I'll re-watch his talk and see what else he specifically said.

> >    Now, I think that our community does a better job of turning users
> >    into devs than most other communities.  I feel like if you hang out
> >    on IRC long enough you eventually become a committer.  But many
> >    users won't hang out on IRC.  A user who doesn't hang out on IRC
> >    should be able to make a "drive-by" bug report or patch, and I
> >    don't feel like that's happening.
> this should be an item!

Oh, phrased another way: I feel like our social resources are great
for would-be contributors, but our tech/doc/et c. resources aren't.

> - Parabola Hackers
> for years we haven't had a clear policy on who and how can become a
> parabola hacker and i think the unofficial documentation[0] isn't really
> in use[1].  by looking at its history[2] it never was a live document
> though it tries to resume the common sense:  you're welcome to make
> friends and send some patches!
> i've been seeing random emails saying "here's my pubkey" on this list,
> where i just assume someone told these people to do it, but then there's
> no follow up from another parabola hacker.  it makes me think it's
> written down somewhere and people just tries it out.

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!?"

> i'd like to see more drive-by patches, but also as a way to become a
> parabola hacker and expand more than the tiny set of people doing
> everyday stuff.  i know i burned out a few years back, i'm happily
> surprised other hackers haven't, but i don't like the overall situation
> where few people does a lot a things and no one knows exactly who does
> what or has access to.

Oh, I definitely burn out too.  I sometimes dissapear for months at a
time.  I make up excuses about being busy with other things, but the
truth is that I simply burn out for a while.

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


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

> having said this, i don't think we have to obsess over numbers, booming
> can be very damaging to a community as great as this :)
> - Donations
> i think my term as parabola delegate towards ceata has ended a while
> ago.  do we want to review this?  i'm happy to keep doing it, since its
> the only regular task i can contribute to lately.

If you're happy to keep doing it, I'm happy for you to keep the position.

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

More information about the Dev mailing list