incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [DISCUSS] a git workflow based on @dev
Date Tue, 02 Apr 2013 19:06:45 GMT
What would this Git repos be for?


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

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