How to become a Parabola hacker

From ParabolaWiki
Jump to: navigation, search

This is not a guide but some guidelines that seemed to have worked in the past:

1 General Advices

  • Be around. People don't care about your big plans if you don't stick around and make friends. Reporting non-free bugs and participating in mailing list discussions is a key to build trust. Specially hang around on the IRC channel and talk to people so they get to know you and you to them. Building a rapport and community around Parabola and Free Software is what drives the our project.
  • Be patient. We're not the fastest people to solve things :P
  • Have fun and be respectful, no one likes an annoyance. In case of doubt, we have an IRC Policy.
  • Make yourself comfortable using Parabola itself. It is difficult to be a developer unless you are fairly accustomed to using the very system. Read documentation, perform basic administrative tasks and installations.
  • Make yourself comfortable using cryptographic public key infrastructures. You're going to use a lot of SSH and GPG.
  • Make yourself comfortable using building tools. You don't have to be an expert to be a part of us, just be willing to learn.
  • Create a public GPG key and get someone to verify it. Getting it signed by more than three Parabola Developers will do.

These are just some things we've said in the past -- Fauno (talk) 21:13, 20 July 2015 (UTC)

2 Learn to contribute to the Parabola Community Repository [pcr]

2.1 Familiarize yourself with the Parabola build tools

  • Learn to use makepkg and about writing PKGBUILDs
  • Install and learn to use libretools
  • Find a package you want to upgrade, fix, or contribute as a packaging request
  • Create or find and modify a working PKGBUILD
  • Build it with makepkg. Install it, test it.
  • If it works, build it again in libretools, test it.
  • If that works, test that it builds for all 3 architectures.

If all that works, attach the PKGBUILD to either a Redmine issue or the dev mailing list, documenting what you have learned, about the licensing, or any special snags or caveats that were needed to build the software. Be patient while the devs look it over and double checking all the things; then hopefully, enjoy the package when it appears.

2.2 Adding new packages to [pcr]

When adding a new package, there are a few more things to consider.

  • Check the license as completely as you can and document what you find
  • Ask yourself:
    • What is the maintenance load of this package?
    • Is it going to break often?
    • How difficult is it to fix?
    • How often will it or its 100 dependents (e.g. python, java) update and need reworking?
    • Am I willing to continue supporting this after contributing it?

Continual support, entails reworking patches and repeating the packaging procedure for future releases, for as long as one can. Ideally, that would be for years. Continual support is not expected for existing packages.