couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: [DISCUSS] a git workflow based on @dev
Date Fri, 29 Mar 2013 22:17:42 GMT
On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau <bchesneau@gmail.com> 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.

Yes. I love these. It is my preferred workflow. I even have tools that
I snagged from the Cassandra project for sending patche to JIRA from
the command line using these tools. I believe I linked them somewhere
on the wiki, but I can document this better if other people have an
interest.

>
> 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.

+1. Committers have been using branches for this, but it's good to
have a workflow where others can have branches. The email (or) JIRA
workflow, when it's well tooled with git, gives everyone this ability
by making it easy to contribute what they've done in their local
branches. Github is merely a place to post those branches, but if the
patches contained therein can hit us another way, like JIRA or ML,
that's a win.

>
> 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?

Getting COUCHDB-XXXX mentions in the ML linked like trackbacks in JIRA
would be outstanding. If we also had Github pull requests going to the
dev list people could even transitively contribute to JIRA via pull
requests.

>
> 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.

Perfect. This is what I've been thinking, too. I suspect everyone
would find this a fantastic situation if we can work it technically.

> 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.

I'm also happy to help. If we lay out the individual scripts needed I
can work on some of them.

>
> Anyway let me know what you think about it.
>
> - benoƮt

I think it's great. Thanks for bringing this thread.

Mime
View raw message