MEGA65 Development Guidelines

Owned by Oliver Graf
Last updated: Sept 22, 2024
3 min read

Repositories

The default branch of the main MEGA65 repositories is the development branch. We intentionally did move away from master/main, as we wanted to emphasize that the default branch is not meant to be in a defined release state.

If a release is being made, we will branch a release-XXX branch from development, bring this to a release state through patching and testing, and then create a release from the automatic builds.

All repositories except mega65-rom are publicly accessible. For the ROM you need to have bought a MEGA65 and request access through our Discord (in the #rom channel).

Automatic Builds

Automatic builds are provided via our Jenkins Builder. Development builds are automatically uploaded to Filehost, but are also accessible via the Jenkins frontend.

Collaboration

If you like to collaborate, you are welcome to do so!

The simples way to help is to test new development version or feature/bugfix branches and report results. If you find a bug or like a feature, please create an ISSUE on the best matching repository. So that means mega65-core for Core, mega65-rom-public for ROM, or perhaps one of the others, if it is more specific.

Please note that you should not close an issue on your own after it was fixed! We do work on branches for a fix, and the maintainer will close the issue after it was merged.
So if you just want to report that the problem is solved, please just use a comment for this.

If you are feeling like you could do some fixes or features on your own, you are welcome to do this!Please make a fork and aim all your branches and PRs towards the development branch. Please talk us on the Discord server. The people in the Steering Group user group are the ones making the decisions.

Also keep in mind that the team consists of volunteers only! Nobody is getting paid, and we all have day jobs we have to attend to. If we don’t answer, we most likely did not see your post. Try to recontact us, possibly using the Steering Group callout. Also use issue comments, this will inform the issue owner, followers and also the organization owners.

Internal Steering Group Processes

Tools

There are ways to stay informed about issues and development:

  • subscribe to issues to get mails (assigning yourself will also get you subscribed)

    • the organization owners (gardners and lydon) alsways get informed

    • other developers are not aware of new issues that are not posted on discord in addition to the issue opening

  • the NEW label shows issues that have not been triaged yet

  • the Steering Group Milestone marks issues that need to be discussed

Workflow

  • new tickets get NEW label (by the issue templates)

  • if discussion is needed, Steering Group Milestone is attached

  • the issue gets discussed on discord in a steering-topic (closed)

    • a poll is being done (abstain option, 3 days)

  • afterwards the issue is tagged with either SGA / SGD label (accepted / declined)

  • after fate of ticket was decided, NEW is removed and appropriate other labels and milestone is attached

    • a issue that is deemed a release requirement is directly tagged with the release milestone, so that we know what is needed for release

    • a normal issue is tagged with near/far/volunteer first

  • after a issues has been handled, it will be placed in the current release milestone, so you can find all release issues by clicking on the milestone