[Dev] Goals/direction for the coming year

[Luke Shumaker]

Hi guys,

I though we should maybe have a conversation about where we want
Parabola to go.  What goals we have.

1 year is an arbitrary length of time that is long enough to
accomplish bigish things, but is still short-ish term.

These are things burning a whole in my head

 - Reproducible builds

   Last year at LibrePlanet I attended h01ger's talk on reproducible
   builds.  I went in with the attitude that reproducible builds were
   nice, but that Parabola would never have them.  But I came out
   thinking "Parabola will be reproducible by next LibrePlanet."  That
   didn't happen, because I'm a lazy fuck.

   This involves doing a better job of tracking exactly what source
   went in to a package.  I have the necessary changes to libretools
   already planned.

   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.

   This also means we need to redo db-cleanup to not prune packages
   mentioned in any current package's `.BUILDINFO`.

 - Build server

   This is important for reproducible builds, and for i686 support
   after November.

   In addition to all of the normal build server things, I think this
   should borrow techniques from reproducible-builds.org; use
   disorderfs and such.

   It is my understanding that we have one physical server being
   dedicated for this task.

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

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

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

   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.

-- 
Happy hacking,
~ Luke Shumaker