Skip to content

Latest commit

 

History

History
62 lines (42 loc) · 4.22 KB

README.md

File metadata and controls

62 lines (42 loc) · 4.22 KB
Raw

GNOME Calendar

gnome-calendar gnome-calendar

Below you will find some instructions to help you contribute to this snap. The general workflow will be to submit PRs from your fork onto the "stable" branch. Once the pull request has been submitted, there is a GitHub action that will automatically launch a build of the snap that you can use for testing. And then once the PR has been merged the GitHub action will launch a build on launchpad that will be automatically uploaded to the snap store, in the candidate channel, for more extensive testing.

Known bugs

Snap still doesn't allow to access to Gnome Control Center through DBus, so the options to configure online accounts from Gnome Calendar doesn't work.

How to contribute to this snap

Initial setup

Here is the workflow for submitting a change to the stable branch, and getting it published in the snap store in the candidate channel. If this is your first time contributing to this snap, then there are a couple of things you need to do as a one-time setup to get ready to submit your first pull request:

  1. Fork the repository into your own GitHub namespace.
  2. Clone your fork.
  3. In addition to your fork, you need to also add this remote repository. To make things a bit more intuitive, let's rename your fork's remote too (since "origin" is hardly descriptive):
git remote rename origin myfork
git remote add ubuntu https://github.com/ubuntu/gnome-calendar.git
git fetch --all

Submitting changes in a pr

Once you're all setup for contributing, keep in mind that you want the git information to be all up-to-date. So if you haven't "fetched" all changes in a while, start with that:

git fetch --all -p

Now that your git metadata has been updated you are ready to create a bugfix branch, make your changes, and open a PR.

  1. All PRs should go to the stable branch so create your branch as a copy of the stable branch:
git checkout -b my-bugfix-branch ubuntu/stable

Note that some projects may have a different main branch (for example, many projects still use 'master' instead of 'stable'). If so, just besure to replace the branch name from 'stable' to the correct branch name in the above command.

If you're unsure which branch to submit PRs agains, it is suggested to open the PR against whatever default branch gets checked out when you clone the repo. And if another destination for the changes is determined later, you can always update the PR.

  1. Make your desired changes and push them to your fork:
git push myfork my-bugfix-branch

Once this branch has been pushed to your fork, you should update the local branch tracking so it tracks the branch pushed to your fork:

git branch -u myfork/my-bugfix-branch
  1. When you feel they're ready for submitting to the main repository (stable branch), open up a pull request from your my-bugfix-branch to the ubuntu/stable branch.
  2. Once you've opened the PR, it will automatically trigger the build-test action that will launch a build of the snap. You can watch the progress of the snap build from your PR (Show all checks -> Details). Once the snap build has completed, you can find the built snap (to test with) under "Artifacts".
  3. Someone from the team will review the open PR and either merge it or start a discussion with you with additional changes or clarification needed.
  4. Once the PR has been merged into the stable branch, then on the next git mirror sync (every 4 hours), launchpad will trigger a build of the snap that gets published to the snap store into the candidate channel. After sufficient testing of the snap from the candidate channel, then the reviewer (a Collaborator of the snap in the store) will promote the snap to the stable branch in the snap store.