incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <...@jsonified.com>
Subject Re: [DISCUSS] a git workflow based on @dev
Date Tue, 14 May 2013 17:26:42 GMT
\o/

thanks Benoit, that will be handy.

On 10 May 2013 21:32, Benoit Chesneau <bchesneau@gmail.com> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message