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 <[email protected]> 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] http://developer.github.com/v3/pulls/
