couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject [DISCUSS] a git workflow based on @dev
Date Thu, 28 Mar 2013 10:12:23 GMT
I should have posted it since a while but was side tracked by work and
travel. Anyway here is a workflow I had in mind since a long time. It's not
here to forbid the use of Github PR or system like one. On the contrary it is
trying to find a way to work with them while keeping the @dev mailing-list as
the first citizen. This is just a proposal. If there are any legal or
technical constraints that seem to stop it then let me know in response to
this thread as well.

Git has been designed from the ground to work with email and many commands
inside git are just here for that: git-format-patch(1), git-apply(1), git-am(1),
git-send-email(1). It's really easy to send a patch via email and test it on
any source code. I would like to use this feature as the core component of
our workflow.

Today we are using 2 main tools in the Apache CouchDB project: Jida and
the mailing lists. We also have a github mirror. I didn't have the time to
test the review tool we have, and if someone did I would be happy to have a
feedback on its usage.

So what I propose as main workflow is this one:

- The main git repo centralize features & fixes which have a ticket in Jira,
  also master & release branches. We probably need a develop branch for C-I
  where fix/features branches should land before going in master or releases
  branches but that's another topic.
- Patches should be sent and discussed on the mailing-list. So anyone susbcribed
  on the mailing-list can comment them and update the thread with new patches.
- Once a patch has been reviewed or lazily reviewed (ie. after a time, noone
  responded), a developer commit it on a branch on the main repo.
- After a final approval the patch will land in one of the main branches
  (release, master, develop).

This workflow allows us to keep git decentralized and let small groups or
individials to manage the code outside apache while keeping main discussions
for patch integration on the ml.

What about JIRA:

- If a patch is answering to an issue in JIRA, it *must* link to it in using a
- Each response could be eventually appended to the JIRA ticket, but maybe we
  could just link the mailing list thread?

What about GITHUB Pull Requests:

Since we have a mirror on github, I'm kinda agree with Noah that we can't
really forbid the use of PR. Especially since most want it.

In my understanding and reading the Github API [1], PRs are some kind of
patches. As a patch they could be hooked to the ML.

The proposed workflow for PR is:

1. When creating a PR a thread is created on the ML
2. Each new patch to the PR is sent to the ML
3. Any new comment on the PR is sent to the ML
4. Any comment on the ML is sent to the PR. We could find a syntax as well to
annotate a line just like github does.
5. Any patches sent to this ml thread is also added to the PR.

In that case noone need to subscribe on Github and the dev ml is the first
citizen. It can be extended to other systems if needed.

I reckon this workflow imply some work to handle PR notifications or Jira
integration, but at the end I think it's a win-win solution preserving our
neutrality while opening ourself to others. I'm happy to help on that work. I
will probably also need the help of @davisp since he knows more about the
Apache Foundation internals than me.

Anyway let me know what you think about it.

- benoƮt


View raw message