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 _______________________________________________ Dev mailing list [email protected] https://lists.parabola.nu/mailman/listinfo/dev
