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 19:48:00 GMT
I didn't know about that one. But yes probably!

On Tue, Apr 2, 2013 at 9:26 PM, Noah Slater <nslater@apache.org> wrote:
> https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git
>
>
> 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ît
>> >
>> > 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î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
>> >>
>> >
>> >
>> >
>> > --
>> > NS
>>
>
>
>
> --
> NS

Mime
View raw message