[Guide] Contributing to Gitano
by Daniel Silverstone
Hi all,
The purpose of this message is to provide a little background on how I want to
run the contribution process for Gitano in the near-future. tl;dr - series on
the ML, review on the ML, merge afterwards.
Background
----------
Up until now, the commits to master of Gitano (and the related projects) have
been made by myself and a few others directly; and then a few more by mailing
list patches, pull requests, etc. This has been somewhat ad-hoc and it needs
to be settled down. The release of 1.0 seems like a good point to do that at.
Managing policy
---------------
Currently this email is to be considered the official statement on how things
will be, but going into the future I expect to document the contribution
process on the wiki and then I'll post to the list to indicate when the wiki is
to be considered the canonical statement on how to contribute.
Master repo branch policy
-------------------------
The repository for Gitano, and associated projects, will continue with 'master
is the development HEAD' as the primary policy. In addition, I expect that the
master branch of any given repository will be passing all its tests. I won't
call that 'releaseable' at this point, but we may move toward
master-always-releaseable in the future.
Anyone with push access to the Gitano repository will be encouraged to
namespace their work into branches named for their username and what the branch
is for. For example, if I were updating the admin manual, I might have a
dsilvers/admin-manual-updates branch.
Who is affected
---------------
The ideal will be for every contributor to the Gitano repositories to be
treated identically. This is not currently possible for technical reasons
(though after the release of Debian Stretch, I will be able to ameliorate the
situation) and so the rules will be that every contribution should be reviewed
on the mailing list, or else by at least one of the Gitano core contributors
before it is pushed to master. Anyone is permitted to review on the mailing
list and I will be looking for a +1 from a core contributor other than the
patch author before merge will be permitted.
Merge or fast-forward
---------------------
Since I'd like to be in a position to say that every commit on the master
branch should pass tests, where a change is complex and needs to be split into
multiple independent changes which cannot be divided for bisect reasons then
the changes will be merged with a merge commit. Where a series of commits
is safe to bisect then we will prefer fast-forwards in order to simplify the
history.
Commit message policy
---------------------
At this time, I'm not going to impose any commit message policy. I've been
looking at semantic commit messages and similar, but for now I don't want to
lock anything down.
---
If there's anything I've missed then I'll follow up later. If anyone has any
input on this then I'd love to hear it, and otherwise I look forward to having
changes reviewed on the mailing list after the release of 1.0.
If anyone wants to take on the task of updating the wiki with instructions on
using git send-email (or perhaps git-series) for all this then I'd love to see
it.
Thank you all for your contributions, and I hope to see more contributions as
we move into the post 1.0 world.
D.
--
Daniel Silverstone http://www.digital-scurf.org/
PGP mail accepted and encouraged. Key Id: 3CCE BABE 206C 3B69
6 years, 10 months
- 1
- 0
- ← Newer
- 1
- Older →