You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Martin Harris <ma...@cloudsoftcorp.com> on 2014/06/04 11:27:05 UTC

Fwd: Usergrid Github workflow

Hi Folks,

Given the recent discussions here, I thought this might be of interest to
those of you not also subscribed to the usergrid dev list

Cheers

M

---------- Forwarded message ----------
From: Dave <sn...@gmail.com>
Date: 3 June 2014 20:50
Subject: Usergrid Github workflow
To: "jfarrell@apache.org" <jf...@apache.org>
Cc: "dev@usergrid.incubator.apache.org" <de...@usergrid.incubator.apache.org>


Following up on this thread...

There was some discussion of this topic on the private ASF board of
directors mailing list, but I still don't understand what specific things
about our process do not comply with ASF policy (and I strongly dislike
discussing things like this in private; this is an open source projects and
our discussions should be open).

Anyhow, based on those private discussions, I now understand that the other
projects with GitHub-centric processes do things slightly different than
the way we do things on Usergrid. Processing an incoming PR requires more
manual steps, but they are able to take advantage of some nice Infra
support for echoing GitHub comments back to the project mailing lists and
JIRA integration too. Let's look at what they do.

 I believe this is an accurate high-level summary of the ASF approved
process used by other projects:
- Contributor forks projects read only GitHub repo
- Contributor submits PR to project on GitHub
- Comments echoed to project mailing list
- Committer merges PR into a local clone of the ASF repo
- Committer pushes change to ASF git repo
- Committer closes PR and does not merge (because the repo is read-only)

Downsides
- Much less convenient
- Accepting a PR takes many keystrokes instead of one button press
- If you want to work via GitHub you must fork, not commits allowed to
project repo

I believe we need to propose some specific changes to our contribution
workflow, and the seek feedback on the public incubator general and
infrastructure mailing lists. So let's look at our process as it stands
today.

Here is a high level summary of our current process:
- If contributor is committer, they can work in branch of our Github repo
- If not, contributor must work in fork of repo
- Contributor submits PR to project on GitHub
- A committer reviews, comments on and merges the pull request
- Periodically a committer pulls from GitHub repo and pushes ASF Git repo

Downsides
- PRs and comments not echoed to project mailing list (yet)
- Manual steps required to sync GitHub repo with ASF Git repo (but this
could be automated).

So, apart from fixing those "downsides" what do we need to fix about our
process? In other projects the contributor's commit happens on GitHub, it
is merged and pushed to ASF Git. That is essentially the same thing we do.
Like I said, I still don't understand what specific problems there are with
our process, except from those downsides.

So, I see at least two possible options for us:

1) adopt the Infra-approved process and and accept the downsides, extra
manual steps, required committer forks etc.

2) fix this limitations of our process, i.e. figure out how to echo PRs and
PR commands to our mailing lists and automate our sync process.


Thoughts?

Thanks,
- Dave

>



-- 
Martin Harris
Lead Software Engineer
Cloudsoft Corporation Ltd
www.cloudsoftcorp.com
Mobile: +44 (0)7989 047-855