Hello,
in the following I try to address some points you mentioned according to our development workflow.
Jack Curran wrote:
Is the master branch supposed to be a copy of the latest public release and is only updated every time a full public release is announced? Staging seems to be the active development branch. So I made my pull request to that branch. Although I am not sure which branch I am supposed to make pull requests to? The genode contributions page says to make pull requests to the master branch.
As a rule of thumb, every line of development should have a corresponding issue in the issue tracker. This will be the place where we will discuss your ongoing work. If there is no issue for your topic, please create one. Once there exists the issue with a short description about what your line of work is about, create a new topic branch based on the genodelabs/master branch.
The master branch is where we master the Genode history after successful quality testing. From the Foundations [1]: "this branch is fixed and will never change". The mastering process is manual work that is based on a carefully selected state of the staging branch and happens when time has come. Genode releases are the result of special quarterly mastering processes and, thus, just one point in the Genode commit history on master. The staging branch is our workbench for merging fixes and other contributions. It is a harsh environment and things may break while the branch is progressing. The staging history is not fixed and may change at any time without warning up to the last branch point from master. The mastering process involves updating staging to the master state (by force-push!).
Jack Curran wrote:
Should I use the master branch for my development in this case and reference my commits to the issues from my master branch?
In 99 percent of the cases: Yes, definitely. Only stray from path if you know the ramifications and aren't afraid of manual rebasing. The merge of your contribution may involve a final rebase onto staging (which is much easier than working on staging for weeks with regular updates).
Jack Curran wrote:
Sorry, I believe I misread the Genode Contributors guide. Genode does not use pull requests, they copy commits that are referenced within issues? So I should make an issue in the repository, then reference my commit against it and genode will copy that into their repository?
In general pull requests and issues only have slight differences on GitHub as we use its features. The before mentioned work of merging to the staging branch and mastering the master branch is a manual step-by-step process that leaves no room for automatic rebasing and stuff. The vast majority of contributions requires discussions and code fixups. So, if you like to contribute chose issue or pull requests as you like (but never both in parallel for the same topic). The core team will respond the way that fits our workflow best: comments, reviews, suggestions for changes inside the commit pages.
Spencer wrote:
I'm curious about this too - looking at the github repo, it seems like there's a mix of pulls into staging and into master. The git flow section of https://genode.org/documentation/genode-foundations-24-05.pdf is a little ambigious - it mentions staging as being the place to put untested changes and then requests that topic branches be pulled from the most current genodelabs/master.
I hope I addressed the ambiguity in my description above.
[1] https://genode.org/documentation/genode-foundations/24.05/development/Git_fl...
Best regards