Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of bchesneau@gmail.com
 designates 209.85.128.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAPaJBx5bjw8F1nWdF34n3XGnSgvThuDLYj8kTcuTT5D-TmAfrw@mail.gmail.com>
References: 
 <CAJNb-9qqz5d7mg9-FNQWYfYwUyv9a06nTiqBuXu6BuFA1W6jpw@mail.gmail.com>
	<CAAL6JQhhqx2gOqmLoz8U=BYmqxJwwnGWPp7N_WnWv9jCjE6=Vw@mail.gmail.com>
	<CAPaJBx5bjw8F1nWdF34n3XGnSgvThuDLYj8kTcuTT5D-TmAfrw@mail.gmail.com>
Date: Tue, 2 Apr 2013 20:59:42 +0200
Message-ID: 
 <CAJNb-9p1EaWA85AFiVm+rUaxtgN7cR9DYM8pemx+V5Vs8OOXFQ@mail.gmail.com>
Subject: Re: [DISCUSS] a git workflow based on @dev
From: Benoit Chesneau <bchesneau@gmail.com>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=EEt


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 contrar=
y
>> 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 respons=
e
>> 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 componen=
t
>> 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 an=
d
>> > the mailing lists. We also have a github mirror. I didn't have the tim=
e
>> 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 fo=
r
>> 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 branch=
es
>> >   (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 ca=
n'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 J=
ira
>> > 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=EEt
>>
>> I think it's great. Thanks for bringing this thread.
>>
>
>
>
> --
> NS