You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2013/03/28 11:12:23 UTC
[DISCUSS] a git workflow based on @dev
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.
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.
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?
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.
In that case noone need to subscribe on Github and the dev ml is the first
citizen. It can be extended to other systems if needed.
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.
Anyway let me know what you think about it.
- benoît
[1] http://developer.github.com/v3/pulls/
Re: [DISCUSS] a git workflow based on @dev
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Re: [DISCUSS] a git workflow based on @dev
Posted by 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
Posted by Noah Slater <ns...@apache.org>.
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
Posted by Randall Leeds <ra...@gmail.com>.
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.
Re: [DISCUSS] a git workflow based on @dev
Posted by Dave Cottlehuber <dc...@jsonified.com>.
\o/
thanks Benoit, that will be handy.
On 10 May 2013 21:32, Benoit Chesneau <bc...@gmail.com> wrote:
> Just a quick follow up about that.
>
> I started some work today on that topic using the Go language (and the
> awesome lib it provides to use the github api).
>
> Basically I have 1 agent subscribed the ml and watching the github
> events. It will do all the logic to link pr with mails threads and so
> on. I expect to make a release sometimes next wee and commit first
> bits over the week-end.
>
> Hopefully it will work as expected.
>
> - benoit
>
> On Thu, Mar 28, 2013 at 11: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.
> >
> > 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.
> >
> > 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?
> >
> > 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.
> >
> >
> > In that case noone need to subscribe on Github and the dev ml is the
> first
> > citizen. It can be extended to other systems if needed.
> >
> >
> > 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.
> >
> > Anyway let me know what you think about it.
> >
> > - benoît
> >
> >
> >
> > [1] http://developer.github.com/v3/pulls/
>
Re: [DISCUSS] a git workflow based on @dev
Posted by Benoit Chesneau <bc...@gmail.com>.
Just a quick follow up about that.
I started some work today on that topic using the Go language (and the
awesome lib it provides to use the github api).
Basically I have 1 agent subscribed the ml and watching the github
events. It will do all the logic to link pr with mails threads and so
on. I expect to make a release sometimes next wee and commit first
bits over the week-end.
Hopefully it will work as expected.
- benoit
On Thu, Mar 28, 2013 at 11: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.
>
> 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.
>
> 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?
>
> 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.
>
>
> In that case noone need to subscribe on Github and the dev ml is the first
> citizen. It can be extended to other systems if needed.
>
>
> 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.
>
> Anyway let me know what you think about it.
>
> - benoît
>
>
>
> [1] http://developer.github.com/v3/pulls/