---

12.7.3 Managing Patches and Branches

Changes should be posted to dezyne-devel@nongnu.org. Leave time for a review, without committing anything.

As an exception, some changes considered “trivial” or “obvious” may be pushed directly to the staging branch. As Dezyne uses a strictly linear history, and master cannot be reset on Savannah, the staging branch is used to accumulate such commits. This includes changes to fix typos and reverting commits that caused immediate problems. This is subject to being adjusted, allowing individuals to commit directly on non-controversial changes on parts they’re familiar with.

To help coordinate the rebasing of wip-* feature branches, you must send an email to dezyne-devel@nongnu.org each time you create a branch, and specify which branch it is based on, which can be another wip-* feature branch.

1. The commits on the branch should be a combination of the patches relevant to the branch. Patches not related to the topic of the branch should go elsewhere.
2. Any changes that can be made on the staging branch, should be made on the staging branch. If a commit can be split to apply part of the changes on staging, this is good to do.
3. Dezyne uses a strictly linear history, which means branches are rebased or re-created rather than merged.

12.7.4 Addressing Issues

Peer review (see Submitting Patches) and tools such as build-aux/indent.scm and the test suite should catch issues before they are pushed. Yet, commits that “break” functionality might occasionally go through. When that happens, there are two priorities: mitigating the impact, and understanding what happened to reduce the chance of similar incidents in the future. The responsibility for both these things primarily lies with those involved, but like everything this is a group effort.

The people involved in authoring, reviewing, and pushing such commit(s) should be at the forefront to mitigate their impact in a timely fashion: by pushing a followup commit to fix it (if possible), or by reverting it to leave time to come up with a proper fix, and by communicating with other developers about the problem. A revert commit should always state the reason for reverting.

If these persons are unavailable to address the issue in time, other committers are entitled to revert the commit(s), explaining in the commit log and on the mailing list what the problem was, with the goal of leaving time to the original committer, reviewer(s), and author(s) to propose a way forward.

Once the problem has been dealt with, it is the responsibility of those involved to make sure the situation is understood. If you are working to understand what happened, focus on gathering information and avoid assigning any blame. Do ask those involved to describe what happened, do not ask them to explain the situation—this would implicitly blame them, which is unhelpful. Accountability comes from a consensus about the problem, learning from it and improving processes so that it’s less likely to reoccur.

12.7.5 Commit Revocation

In order to reduce the possibility of mistakes, committers will have their Savannah account removed from the Dezyne Savannah project after 12 months of inactivity; they can ask to regain commit access by emailing the maintainers, without going through the vouching process.

Maintainers¹⁶ may also revoke an individual’s commit rights, as a last resort, if cooperation with the rest of the community has caused too much friction—even within the bounds of the project’s kind communication guidelines (see Contributing). They would only do so after public or private discussion with the individual and a clear notice. Examples of behavior that hinders cooperation and could lead to such a decision include:

• repeated violation of the commit policy stated above;
• repeated failure to take peer criticism into account;
• breaching trust through a series of grave incidents.

When maintainers resort to such a decision, they notify developers on dezyne-devel@nongnu.org; inquiries may be sent to maintainers@dezyne.org. Depending on the situation, the individual may still be welcome to contribute.

12.7.6 Helping Out

One last thing: the project keeps moving forward because committers not only push their own awesome changes, but also offer some of their time reviewing and pushing other people’s changes. As a committer, you’re welcome to use your expertise and commit rights to help other contributors, too!