Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJNb-9pCJp-h-rFMn5tKrpEJa1F1Vp8dp-3jNMEdCtyQrKMbkw@mail.gmail.com>
References: 
 <CAJNb-9qqz5d7mg9-FNQWYfYwUyv9a06nTiqBuXu6BuFA1W6jpw@mail.gmail.com>
	<CAAL6JQhhqx2gOqmLoz8U=BYmqxJwwnGWPp7N_WnWv9jCjE6=Vw@mail.gmail.com>
	<CAPaJBx5bjw8F1nWdF34n3XGnSgvThuDLYj8kTcuTT5D-TmAfrw@mail.gmail.com>
	<CAJNb-9p1EaWA85AFiVm+rUaxtgN7cR9DYM8pemx+V5Vs8OOXFQ@mail.gmail.com>
	<CAPaJBx7yAOOeR-Dsvr9j7gHXHN+0F5fcmwkPD-LtGPWYGWtRqA@mail.gmail.com>
	<CAJNb-9pCJp-h-rFMn5tKrpEJa1F1Vp8dp-3jNMEdCtyQrKMbkw@mail.gmail.com>
Date: Tue, 2 Apr 2013 20:25:59 +0100
Message-ID: 
 <CAPaJBx40FigffXP7YRUxL8gz7YLVBub+mw7Wkym1=jHnceU8ow@mail.gmail.com>
Subject: Re: [DISCUSS] a git workflow based on @dev
From: Noah Slater <nslater@apache.org>
To: "dev@couchdb.apache.org" <dev@couchdb.apache.org>
Content-Type: multipart/alternative; boundary=e89a8f22c6810f14ff04d965b558

--e89a8f22c6810f14ff04d965b558
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

couchdb-admin.git might be a good place for it?


On 2 April 2013 20:08, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <nslater@apache.org> wrote:
> > What would this Git repos be for?
> >
>
> to start the work on some scripts. Can also be done somewhere in the
> repo we already have? What would it be the best according to you?
>
> - beno=EEt
> >
> > On 2 April 2013 19:59, Benoit Chesneau <bchesneau@gmail.com> wrote:
> >
> >> 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 wor=
k
> 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 lega=
l
> 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 fro=
m
> >> >> the command line using these tools. I believe I linked them somewhe=
re
> >> >> 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: Ji=
da
> >> and
> >> >> > the mailing lists. We also have a github mirror. I didn't have th=
e
> >> 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 bran=
ch
> >> 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 abili=
ty
> >> >> 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 t=
he
> >> >> 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 synta=
x
> 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=EEt
> >> >>
> >> >> I think it's great. Thanks for bringing this thread.
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > NS
> >>
> >
> >
> >
> > --
> > NS
>


--=20
NS

--e89a8f22c6810f14ff04d965b558--