couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: [DISCUSS] a git workflow based on @dev
Date Fri, 10 May 2013 19:32:14 GMT
Just a quick follow up about that.

I started some work today on that topic using the Go language (and the
awesome lib it provides to use the github api).

Basically I have 1 agent subscribed the ml and watching the github
events. It will do all the logic to link pr with mails threads and so
on. I expect to make a release sometimes next wee and commit first
bits over the week-end.

Hopefully it will work as expected.

- benoit

On Thu, Mar 28, 2013 at 11:12 AM, Benoit Chesneau <> wrote:
> 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
>   syntax
> - 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
> [1]

View raw message