Any problems with our commit workflow?

[Andrew Phillips <ap...@qrmedia.com>]

Just following up on Jake Farrell's comment over at general@i.a.o [1]:

"As for the Github workflows that are starting to be used, I am not a
proponent of them. These workflows are not ideal as they repositories are
not under any Asf control and infra can not help if there are any issues,
its up to the project to take care of its own. Also with the JClouds and
now Usergrid projects using this flow adds a lot of overhead for
initial contributions as they have in the workflow the requirement to
ensure an ICLA are on file for the contributor. Most committers do not have
access to see the status of this. Also since these projects are not working
directly against the primary repository it is up to them to ensure that
committers are the only ones submitting code to the primary repository and
then syncing that code at some point over to the ASF repositories in order
to make a release."

Personally, I think our GitHub workflow works well for our contributor  
base, and I don't feel as they committers suffer from exceptionally  
burdensome overhead as a result. As far as I'm aware, we're also  
covering all the legal bases that we need to cover.

Still: anyone else see any problems with the current review and commit flow?

ap

[1] http://markmail.org/message/r6w7fmjqjg6guxc3

Re: Any problems with our commit workflow?

[Andrew Phillips <ap...@qrmedia.com>]

> stated otherwise. From an IP standpoint, I am happy with the level of
> assurance that provides.

Thanks for clarifying, David!

ap

Re: Any problems with our commit workflow?

[David Nalley <da...@gnsa.us>]

On Mon, Feb 3, 2014 at 7:32 PM, Andrew Bayer <an...@gmail.com> wrote:
> We're probably not 100% ideal on the ICLA side - I really, really want
> GitHub to add an ICLA-or-copyright-assignment option to pull requests, so
> that we can make this explicit. But we're not in a bad place here, just not
> quite as clear as I'd like to see.
>

ICLA isn't needed for most contributions. We don't have any concept of
copyright assignment at the ASF, copyright remains with the original
author. The ASL is pretty explicit that contributions made to the
codebase are assumed to be under the same license unless explicitly
stated otherwise. From an IP standpoint, I am happy with the level of
assurance that provides.

--David

Re: Any problems with our commit workflow?

[Andrew Phillips <ap...@qrmedia.com>]

> Just answered the incubator thread clarifying our workflow.

Thanks, Ignasi! I see Bertrand responded with a couple of "TODO" items  
;-) But overall it looks like our PR process is fine, if I'm reading  
him correctly.

ap

Re: Any problems with our commit workflow?

[Ignasi Barrera <na...@apache.org>]

Just answered the incubator thread clarifying our workflow.
El 04/02/2014 01:33, "Andrew Bayer" <an...@gmail.com> escribió:

> We're probably not 100% ideal on the ICLA side - I really, really want
> GitHub to add an ICLA-or-copyright-assignment option to pull requests, so
> that we can make this explicit. But we're not in a bad place here, just not
> quite as clear as I'd like to see.
>
> That said, Jake's a bit confused as to our workflow. I think he's under the
> impression that we push actual commits to GH first and then from there to
> ASF - i.e., that we follow the full pull request workflow, when in fact we
> just use pull requests as our code review etc process. If we were actually
> doing what he seems to think we're doing, yeah, that'd be a real problem
> and I'd've thrown up barriers to it - and hell, we never would have
> graduated! So if someone would like to educate Jake as to what we're really
> doing, I think we can get this cleared up.
>
> A.
>
>
> On Mon, Feb 3, 2014 at 8:12 AM, Ignasi Barrera <ignasi.barrera@gmail.com
> >wrote:
>
> > I'm totally ok with our workflow. Don't want to make start a flame on
> > that thread (as it won't help answering the question), but here is
> > what I like:
> >
> > * People is used to GitHub pull requests. I think it is the easiest
> > path nowadays to contribute to a project, and it helps and enourages
> > people to do so. So IMHO we should keep it.
> > * Having the ICLA in place is not a must in our workflow. Only for big
> > contributions or for companies contributing. But we are not asking for
> > them in most patches.
> > * There is no overhead added to make the code reach the ASF repos, as
> > those are the only ones where commiters push changes.
> >
> > * It's true that we have to deal with our custom mirroring to the
> > jclouds org, but we have already addressed that, have full control on
> > the CI system and CloudBees people is nice :)
> >
> > On 3 February 2014 16:59, Andrew Phillips <ap...@qrmedia.com> wrote:
> > > Just following up on Jake Farrell's comment over at general@i.a.o [1]:
> > >
> > > "As for the Github workflows that are starting to be used, I am not a
> > > proponent of them. These workflows are not ideal as they repositories
> are
> > > not under any Asf control and infra can not help if there are any
> issues,
> > > its up to the project to take care of its own. Also with the JClouds
> and
> > > now Usergrid projects using this flow adds a lot of overhead for
> > > initial contributions as they have in the workflow the requirement to
> > > ensure an ICLA are on file for the contributor. Most committers do not
> > have
> > > access to see the status of this. Also since these projects are not
> > working
> > > directly against the primary repository it is up to them to ensure that
> > > committers are the only ones submitting code to the primary repository
> > and
> > > then syncing that code at some point over to the ASF repositories in
> > order
> > > to make a release."
> > >
> > > Personally, I think our GitHub workflow works well for our contributor
> > base,
> > > and I don't feel as they committers suffer from exceptionally
> burdensome
> > > overhead as a result. As far as I'm aware, we're also covering all the
> > legal
> > > bases that we need to cover.
> > >
> > > Still: anyone else see any problems with the current review and commit
> > flow?
> > >
> > > ap
> > >
> > > [1] http://markmail.org/message/r6w7fmjqjg6guxc3
> >
>

Re: Any problems with our commit workflow?

[Andrew Bayer <an...@gmail.com>]

We're probably not 100% ideal on the ICLA side - I really, really want
GitHub to add an ICLA-or-copyright-assignment option to pull requests, so
that we can make this explicit. But we're not in a bad place here, just not
quite as clear as I'd like to see.

That said, Jake's a bit confused as to our workflow. I think he's under the
impression that we push actual commits to GH first and then from there to
ASF - i.e., that we follow the full pull request workflow, when in fact we
just use pull requests as our code review etc process. If we were actually
doing what he seems to think we're doing, yeah, that'd be a real problem
and I'd've thrown up barriers to it - and hell, we never would have
graduated! So if someone would like to educate Jake as to what we're really
doing, I think we can get this cleared up.

A.


On Mon, Feb 3, 2014 at 8:12 AM, Ignasi Barrera <ig...@gmail.com>wrote:

> I'm totally ok with our workflow. Don't want to make start a flame on
> that thread (as it won't help answering the question), but here is
> what I like:
>
> * People is used to GitHub pull requests. I think it is the easiest
> path nowadays to contribute to a project, and it helps and enourages
> people to do so. So IMHO we should keep it.
> * Having the ICLA in place is not a must in our workflow. Only for big
> contributions or for companies contributing. But we are not asking for
> them in most patches.
> * There is no overhead added to make the code reach the ASF repos, as
> those are the only ones where commiters push changes.
>
> * It's true that we have to deal with our custom mirroring to the
> jclouds org, but we have already addressed that, have full control on
> the CI system and CloudBees people is nice :)
>
> On 3 February 2014 16:59, Andrew Phillips <ap...@qrmedia.com> wrote:
> > Just following up on Jake Farrell's comment over at general@i.a.o [1]:
> >
> > "As for the Github workflows that are starting to be used, I am not a
> > proponent of them. These workflows are not ideal as they repositories are
> > not under any Asf control and infra can not help if there are any issues,
> > its up to the project to take care of its own. Also with the JClouds and
> > now Usergrid projects using this flow adds a lot of overhead for
> > initial contributions as they have in the workflow the requirement to
> > ensure an ICLA are on file for the contributor. Most committers do not
> have
> > access to see the status of this. Also since these projects are not
> working
> > directly against the primary repository it is up to them to ensure that
> > committers are the only ones submitting code to the primary repository
> and
> > then syncing that code at some point over to the ASF repositories in
> order
> > to make a release."
> >
> > Personally, I think our GitHub workflow works well for our contributor
> base,
> > and I don't feel as they committers suffer from exceptionally burdensome
> > overhead as a result. As far as I'm aware, we're also covering all the
> legal
> > bases that we need to cover.
> >
> > Still: anyone else see any problems with the current review and commit
> flow?
> >
> > ap
> >
> > [1] http://markmail.org/message/r6w7fmjqjg6guxc3
>

Re: Any problems with our commit workflow?

[Ignasi Barrera <ig...@gmail.com>]

I'm totally ok with our workflow. Don't want to make start a flame on
that thread (as it won't help answering the question), but here is
what I like:

* People is used to GitHub pull requests. I think it is the easiest
path nowadays to contribute to a project, and it helps and enourages
people to do so. So IMHO we should keep it.
* Having the ICLA in place is not a must in our workflow. Only for big
contributions or for companies contributing. But we are not asking for
them in most patches.
* There is no overhead added to make the code reach the ASF repos, as
those are the only ones where commiters push changes.

* It's true that we have to deal with our custom mirroring to the
jclouds org, but we have already addressed that, have full control on
the CI system and CloudBees people is nice :)

On 3 February 2014 16:59, Andrew Phillips <ap...@qrmedia.com> wrote:
> Just following up on Jake Farrell's comment over at general@i.a.o [1]:
>
> "As for the Github workflows that are starting to be used, I am not a
> proponent of them. These workflows are not ideal as they repositories are
> not under any Asf control and infra can not help if there are any issues,
> its up to the project to take care of its own. Also with the JClouds and
> now Usergrid projects using this flow adds a lot of overhead for
> initial contributions as they have in the workflow the requirement to
> ensure an ICLA are on file for the contributor. Most committers do not have
> access to see the status of this. Also since these projects are not working
> directly against the primary repository it is up to them to ensure that
> committers are the only ones submitting code to the primary repository and
> then syncing that code at some point over to the ASF repositories in order
> to make a release."
>
> Personally, I think our GitHub workflow works well for our contributor base,
> and I don't feel as they committers suffer from exceptionally burdensome
> overhead as a result. As far as I'm aware, we're also covering all the legal
> bases that we need to cover.
>
> Still: anyone else see any problems with the current review and commit flow?
>
> ap
>
> [1] http://markmail.org/message/r6w7fmjqjg6guxc3