Re: [DISCUSS] a git workflow based on @dev

[Benoit Chesneau <bc...@gmail.com>]

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 <ns...@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 <ra...@gmail.com> wrote:
>
>> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau <bc...@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

Re: [DISCUSS] a git workflow based on @dev

[Noah Slater <ns...@apache.org>]

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


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

> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <ns...@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 <bc...@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 <ns...@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 <ra...@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

Re: [DISCUSS] a git workflow based on @dev

[Benoit Chesneau <bc...@gmail.com>]

I didn't know about that one. But yes probably!

On Tue, Apr 2, 2013 at 9:26 PM, Noah Slater <ns...@apache.org> wrote:
> https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git
>
>
> On 2 April 2013 20:08, Benoit Chesneau <bc...@gmail.com> wrote:
>
>> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <ns...@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 <bc...@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 <ns...@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 <ra...@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

Re: [DISCUSS] a git workflow based on @dev

[Noah Slater <ns...@apache.org>]

https://git-wip-us.apache.org/repos/asf?p=couchdb-admin.git


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

> On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <ns...@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 <bc...@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 <ns...@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 <ra...@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

Re: [DISCUSS] a git workflow based on @dev

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Apr 2, 2013 at 9:06 PM, Noah Slater <ns...@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 <bc...@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 <ns...@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 <ra...@gmail.com> wrote:
>> >
>> >> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau <bc...@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

Re: [DISCUSS] a git workflow based on @dev

[Noah Slater <ns...@apache.org>]

What would this Git repos be for?


On 2 April 2013 19:59, Benoit Chesneau <bc...@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 <ns...@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 <ra...@gmail.com> wrote:
> >
> >> On Thu, Mar 28, 2013 at 3:12 AM, Benoit Chesneau <bc...@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

Re: [DISCUSS] a git workflow based on @dev

[Benoit Chesneau <bc...@gmail.com>]

On Tue, Apr 2, 2013 at 9:39 PM, Randall Leeds <ra...@gmail.com> wrote:
> On Tue, Apr 2, 2013 at 11:59 AM, Benoit Chesneau <bc...@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.
>
> https://wiki.apache.org/cassandra/GitAndJIRA

Thanks!

Re: [DISCUSS] a git workflow based on @dev

[Randall Leeds <ra...@gmail.com>]

On Tue, Apr 2, 2013 at 11:59 AM, Benoit Chesneau <bc...@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.

https://wiki.apache.org/cassandra/GitAndJIRA