Home

Welcome to the mintupload development wiki! Our ToDo section has been moved to Issues, so if there’s something you especially want done, vote it up! Oh, btw, we use tabs for indentation, contrary to pep8.

If you branch the code, I recommend following a similar structure to that outlined here, specifically having a fixes branch for little things you notice while you’re doing something else. The second most important point is separate branches for each feature.

Branches Explanation

• Be more disciplined with git branches, anything not directly related to current branch shouldn’t be committed.
• Keep changes for a commit small, if a bug is introduced, it’s much easier to find when rolling back.
  • As a guideline: if it takes more than one line of text to describe the changes, it should be split into multiple commits
• Little fixes should be shoved on fixes branch, it’s then much easier to merge back in, or push upstream.

1. gloria (or other release named branches)
   • This will always reflect the upstream official repo version
   • All commits on this branch are really clem’s
2. master – major changes, e.g. new configuration management when complete.
   • This will always reflect the ppa version
   • Should be considered release candidate quality.
3. community – provides a testing period for new features before they make it to master.
   • Main integration branch
   • Should be considered beta quality.
4. all others are feature branches, and should be branched off community until ready for integration.
   • Should be considered alpha quality.

The fixes branch is different:

• Little fixes (sometimes bugfixes) that don’t change anything major, so stability is guaranteed.
• Can be based off release named branches, when fixes affect the main release, (basically my way of indicating bugs to clem in new code)
• Can be based off master, when upstream has finalised development for release, and rejected any remaining changes.
• Should be considered the same quality as the respective branches.