incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: [DISCUSS] a git workflow based on @dev
Date Tue, 02 Apr 2013 18:59:42 GMT
Cool,

Thanks Randall & Noah for the feedback. I think we are all OK to start
to  work on that then. Randall can you provide a link for the tool you
mention in the cassandra project? I would be interested by them.


To start all the process I will open a git repo somewhere so we can
start to hack all together. Not until the end of the week i'm actually
busy at work.

- benoît


On Sat, Mar 30, 2013 at 2:03 PM, Noah Slater <nslater@apache.org> wrote:
> Your proposal looks good Benoit. I'd be happy to see us work towards this.
>
>
> On 29 March 2013 22:17, Randall Leeds <randall.leeds@gmail.com> wrote:
>
>> 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.
>>
>
>
>
> --
> NS

Mime
View raw message