Writable github repos?

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

Hi folks,

Do you have a cup of coffee/tea handy? If not you might want to go get
one first, this will be a long email with lots of pondering which
would likely be assisted by a warm beverage.

I am pondering whether it's possible for projects at the ASF to use
github writable repos.

Let me set the stage for what we have today with github:

* We mirror hundreds of repositories to github [1]
* We have a comprehensive integration with github [2]
* A majority of projects that use git as their VCS are using the
integration and using github as the locus for contribution.

In the github integration model we essentially sync all of the
happenings from github back to the projects mailing list. (and vice
versa for those folks who choose to use the mailing list.)

My personal preference is that the ASF is the locus for development
activity; but I also want to be pragmatic and not force my preferences
on all of the individual projects. I also recognize that we are part
way there; by accepting contributions at github and using that
workflow, we've moved in that direction a bit.

That led me to wondering - what's keeping us from using a writable git
repo? It's not without problems and challenges.

So that led me tossing together a straw-man proposal in my head for
what we'd use as an experiment:

Requirements:
* No guarantee that this will ever emerge from a test, and may be
discontinued at any time during the test.
* 6 month term, with monthly reporting for the duration.
* Test shall consist of a single, mature, healthy, TLP
* github repo must reside within the Apache organization on github
* Access would be managed by infra (e.g. projects would not get admin
access to their repos.
* Github integration must be enabled with activity flowing to lists.
* Force rewrites disabled (this is something that must be performed
out of band by GH staff at present)
* Commit mails directed to commits@$foo.a.o
* Github repo synced frequently somewhere on a.o - and backed up.

I've also reached out to folks from Eclipse to discuss their
experience. Their concerns were project continuity (should github pull
a CodeSpaces[3]), and IP/Legal concerns. They require a CLA be signed
for each contribution, so some of that is easily obviated because we
have no need to audit the author of each pull request to confirm that
they have a CLA signed. They also have admin access restricted to
their infrastructure team.

I am sure there are other concerns that I haven't thought about yet;
so what are they?

Thoughts, comments, flames?

--David

[1] https://github.com/apache
[2] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
[3] http://codespaces.com

Re: Writable github repos?

[Mark Struberg <st...@yahoo.de>]

I think the reason why I prefer jira patches or git format-patch via email to the list is that it's really clear what you get. A pull request can obviously contain many different commits from different people.
When applying a pull request, then they often get either squashed or rebased to not totally mess up the history. And after such a step you have a nice and straight history, but you don't know who did what.
I have no problem with small pull requests which are easy to overview what changes they contain and if there is additional communication via JIRA and mailing list

Maybe it's purely an educational thing and we just have to point out the risks.

LieGrue,
strub




> On Saturday, 28 June 2014, 3:56, Benson Margulies <bi...@gmail.com> wrote:
> > On Fri, Jun 27, 2014 at 9:54 PM, Joe Schaefer
> <jo...@yahoo.com.invalid> wrote:
>>  Two things Benson: first your ICLA is really about third-party 
> contributions and your acceptance and incorporation thereof.  It doesn't 
> spell out precisely your due-diligence requirements, but the gist of it is that 
> you are confident you have the legal rights necessary to include the 
> contribution.  If you aren't that confident, then we ask that you request an 
> ICLA from the contributor.
> 
> Understood. If I have a point, it's that the quality of the execution
> of these responsibility varies on a scale of something to Mark.
> 
> 
>> 
>>  Second, there is nothing stopping a well-funded "evil" 
> organization from securing a PMC post on a project with a bogus ICLA, so the 
> idea that we need to fear only third party contributions is nonsense.  There are 
> a number of ways to game the system.  As you say it boils down to reasonable 
> assurances based on the likelihood and potential impact of harm.
>> 
>> 
>> 
>>  On Friday, June 27, 2014 8:49 PM, Benson Margulies 
> <bi...@gmail.com> wrote:
>> 
>> 
>> 
>>  On Fri, Jun 27, 2014 at 7:58 PM, Joseph Schaefer
>>  <jo...@yahoo.com.invalid> wrote:
>>>  I think that is the point of an icla for committers, because otherwise 
> the apache license suffices.
>>> 
>>>  Sent from my iPhone
>>> 
>>>>  On Jun 27, 2014, at 5:25 PM, Mark Struberg 
> <st...@yahoo.de> wrote:
>>>> 
>>>>>  On Friday, 27 June 2014, 23:17, Joseph Schaefer 
> <jo...@yahoo.com.INVALID> wrote:
>>>>>  We might simply ask github to provide push records to us.
>>>> 
>>>> 
>>>>  This would at least solve the problem with who pushed what.
>>>>  Are you talking about pushes to an ASF project repo on github or to 
> all github commits we pull in for a pull-request?
>>>> 
>>>>  And how to solve the problem that it's way too easy to pull 
> foreign changes is still not clear to me.
>> 
>>  I think that there is a gap between theory and practice.
>> 
>>  First, many, perhaps most, commits are by committers. As an
>>  organization, we trust committers. Full stop. While there's a theory
>>  of PMC review, how many PMC members are pretending to be
>>  mechanical-turk Black Ducks carefully vetting commits?
>> 
>>  For non-committer patches, the safety comes from social interaction.
>>  Someone emails in a patch. We don't really know that it's their own
>>  work. When something looks really fishy, a committer might take
>>  notice. But mostly we trust. I think that Mark is exceptional. OK, a
>>  github commit can have a fake source. How often to we get JIRAs,
>>  patches, or pull requests that come with zero social interaction?
>>  Generally, if someone posts a JIRA, or a PR, or whatever, there's a
>>  trail of discussion. For one thing, this makes faking the git email
>>  address fairly moot. If the commit says Fred but all the email says
>>  George, well, that's a question. If all we have is a PR, we can always
>>  demand some mailing list interaction. Eventually, a sufficiently
>>  energetic fraud will get away with it, and as an organization, we long
>>  ago decided that this was legally tolerable.
>> 
>> 
>> 
>>>> 
>>>>  LieGrue,
>>>>  strub
>>>> 
> 

Re: Writable github repos?

[Benson Margulies <bi...@gmail.com>]

On Fri, Jun 27, 2014 at 9:54 PM, Joe Schaefer
<jo...@yahoo.com.invalid> wrote:
> Two things Benson: first your ICLA is really about third-party contributions and your acceptance and incorporation thereof.  It doesn't spell out precisely your due-diligence requirements, but the gist of it is that you are confident you have the legal rights necessary to include the contribution.  If you aren't that confident, then we ask that you request an ICLA from the contributor.

Understood. If I have a point, it's that the quality of the execution
of these responsibility varies on a scale of something to Mark.

>
> Second, there is nothing stopping a well-funded "evil" organization from securing a PMC post on a project with a bogus ICLA, so the idea that we need to fear only third party contributions is nonsense.  There are a number of ways to game the system.  As you say it boils down to reasonable assurances based on the likelihood and potential impact of harm.
>
>
>
> On Friday, June 27, 2014 8:49 PM, Benson Margulies <bi...@gmail.com> wrote:
>
>
>
> On Fri, Jun 27, 2014 at 7:58 PM, Joseph Schaefer
> <jo...@yahoo.com.invalid> wrote:
>> I think that is the point of an icla for committers, because otherwise the apache license suffices.
>>
>> Sent from my iPhone
>>
>>> On Jun 27, 2014, at 5:25 PM, Mark Struberg <st...@yahoo.de> wrote:
>>>
>>>> On Friday, 27 June 2014, 23:17, Joseph Schaefer <jo...@yahoo.com.INVALID> wrote:
>>>> We might simply ask github to provide push records to us.
>>>
>>>
>>> This would at least solve the problem with who pushed what.
>>> Are you talking about pushes to an ASF project repo on github or to all github commits we pull in for a pull-request?
>>>
>>> And how to solve the problem that it's way too easy to pull foreign changes is still not clear to me.
>
> I think that there is a gap between theory and practice.
>
> First, many, perhaps most, commits are by committers. As an
> organization, we trust committers. Full stop. While there's a theory
> of PMC review, how many PMC members are pretending to be
> mechanical-turk Black Ducks carefully vetting commits?
>
> For non-committer patches, the safety comes from social interaction.
> Someone emails in a patch. We don't really know that it's their own
> work. When something looks really fishy, a committer might take
> notice. But mostly we trust. I think that Mark is exceptional. OK, a
> github commit can have a fake source. How often to we get JIRAs,
> patches, or pull requests that come with zero social interaction?
> Generally, if someone posts a JIRA, or a PR, or whatever, there's a
> trail of discussion. For one thing, this makes faking the git email
> address fairly moot. If the commit says Fred but all the email says
> George, well, that's a question. If all we have is a PR, we can always
> demand some mailing list interaction. Eventually, a sufficiently
> energetic fraud will get away with it, and as an organization, we long
> ago decided that this was legally tolerable.
>
>
>
>>>
>>> LieGrue,
>>> strub
>>>

Re: Writable github repos?

[Joe Schaefer <jo...@yahoo.com.INVALID>]

Two things Benson: first your ICLA is really about third-party contributions and your acceptance and incorporation thereof.  It doesn't spell out precisely your due-diligence requirements, but the gist of it is that you are confident you have the legal rights necessary to include the contribution.  If you aren't that confident, then we ask that you request an ICLA from the contributor.

Second, there is nothing stopping a well-funded "evil" organization from securing a PMC post on a project with a bogus ICLA, so the idea that we need to fear only third party contributions is nonsense.  There are a number of ways to game the system.  As you say it boils down to reasonable assurances based on the likelihood and potential impact of harm.



On Friday, June 27, 2014 8:49 PM, Benson Margulies <bi...@gmail.com> wrote:
 


On Fri, Jun 27, 2014 at 7:58 PM, Joseph Schaefer
<jo...@yahoo.com.invalid> wrote:
> I think that is the point of an icla for committers, because otherwise the apache license suffices.
>
> Sent from my iPhone
>
>> On Jun 27, 2014, at 5:25 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> On Friday, 27 June 2014, 23:17, Joseph Schaefer <jo...@yahoo.com.INVALID> wrote:
>>> We might simply ask github to provide push records to us.
>>
>>
>> This would at least solve the problem with who pushed what.
>> Are you talking about pushes to an ASF project repo on github or to all github commits we pull in for a pull-request?
>>
>> And how to solve the problem that it's way too easy to pull foreign changes is still not clear to me.

I think that there is a gap between theory and practice.

First, many, perhaps most, commits are by committers. As an
organization, we trust committers. Full stop. While there's a theory
of PMC review, how many PMC members are pretending to be
mechanical-turk Black Ducks carefully vetting commits?

For non-committer patches, the safety comes from social interaction.
Someone emails in a patch. We don't really know that it's their own
work. When something looks really fishy, a committer might take
notice. But mostly we trust. I think that Mark is exceptional. OK, a
github commit can have a fake source. How often to we get JIRAs,
patches, or pull requests that come with zero social interaction?
Generally, if someone posts a JIRA, or a PR, or whatever, there's a
trail of discussion. For one thing, this makes faking the git email
address fairly moot. If the commit says Fred but all the email says
George, well, that's a question. If all we have is a PR, we can always
demand some mailing list interaction. Eventually, a sufficiently
energetic fraud will get away with it, and as an organization, we long
ago decided that this was legally tolerable.



>>
>> LieGrue,
>> strub
>>

Re: Writable github repos?

[Benson Margulies <bi...@gmail.com>]

On Fri, Jun 27, 2014 at 7:58 PM, Joseph Schaefer
<jo...@yahoo.com.invalid> wrote:
> I think that is the point of an icla for committers, because otherwise the apache license suffices.
>
> Sent from my iPhone
>
>> On Jun 27, 2014, at 5:25 PM, Mark Struberg <st...@yahoo.de> wrote:
>>
>>> On Friday, 27 June 2014, 23:17, Joseph Schaefer <jo...@yahoo.com.INVALID> wrote:
>>> We might simply ask github to provide push records to us.
>>
>>
>> This would at least solve the problem with who pushed what.
>> Are you talking about pushes to an ASF project repo on github or to all github commits we pull in for a pull-request?
>>
>> And how to solve the problem that it's way too easy to pull foreign changes is still not clear to me.

I think that there is a gap between theory and practice.

First, many, perhaps most, commits are by committers. As an
organization, we trust committers. Full stop. While there's a theory
of PMC review, how many PMC members are pretending to be
mechanical-turk Black Ducks carefully vetting commits?

For non-committer patches, the safety comes from social interaction.
Someone emails in a patch. We don't really know that it's their own
work. When something looks really fishy, a committer might take
notice. But mostly we trust. I think that Mark is exceptional. OK, a
github commit can have a fake source. How often to we get JIRAs,
patches, or pull requests that come with zero social interaction?
Generally, if someone posts a JIRA, or a PR, or whatever, there's a
trail of discussion. For one thing, this makes faking the git email
address fairly moot. If the commit says Fred but all the email says
George, well, that's a question. If all we have is a PR, we can always
demand some mailing list interaction. Eventually, a sufficiently
energetic fraud will get away with it, and as an organization, we long
ago decided that this was legally tolerable.


>>
>> LieGrue,
>> strub
>>

Re: Writable github repos?

[Joseph Schaefer <jo...@yahoo.com.INVALID>]

I think that is the point of an icla for committers, because otherwise the apache license suffices.

Sent from my iPhone

> On Jun 27, 2014, at 5:25 PM, Mark Struberg <st...@yahoo.de> wrote:
> 
>> On Friday, 27 June 2014, 23:17, Joseph Schaefer <jo...@yahoo.com.INVALID> wrote:
>> We might simply ask github to provide push records to us.
> 
> 
> This would at least solve the problem with who pushed what.
> Are you talking about pushes to an ASF project repo on github or to all github commits we pull in for a pull-request?
> 
> And how to solve the problem that it's way too easy to pull foreign changes is still not clear to me.
> 
> LieGrue,
> strub
> 

Re: Writable github repos?

[Mark Struberg <st...@yahoo.de>]

On Friday, 27 June 2014, 23:17, Joseph Schaefer <jo...@yahoo.com.INVALID> wrote:
>We might simply ask github to provide push records to us.


This would at least solve the problem with who pushed what.
Are you talking about pushes to an ASF project repo on github or to all github commits we pull in for a pull-request?

And how to solve the problem that it's way too easy to pull foreign changes is still not clear to me.

LieGrue,
strub

Re: Writable github repos?

[Joseph Schaefer <jo...@yahoo.com.INVALID>]

We might simply ask github to provide push records to us.

Sent from my iPhone

> On Jun 27, 2014, at 5:11 PM, Mark Struberg <st...@yahoo.de> wrote:
> 
> The scenario you mentioned is not valid
> 
> a.) I for one do NOT accept pull requests from github! I only apply single requests where I also have a JIRA + diffs
> b.) each ASF committer must commit his changes HIMSELF. Committing for others is disregarded.
> 
> If you send patches in my name to the list then I will speak up and catch that. And no one will apply those patches, because of b.)
> If a patch is tracked by mail + JIRA, then we at least have the remote IP and tons of other stuff like the mx header logged.
> In case of any later problem this very commit can be identified very easily.
> The same for a pull request leaves no whatever way to even track which commits are in question once the original repo got deleted from github.
> 
> Don't get it wrong. I like GIT a lot. I even wrote the initial parts of the german translation for GIT (back in 2006 or so) and the first version of the maven-git-plugin back then. But while I love GIT, I don't think we can use GIT without the push verification we have atm. This is what makes all the difference between GIT projects hosted at the ASF and at somewhere else (not only github).
> 
> LieGrue,
> strub
>  
> 
> 
> On Friday, 27 June 2014, 23:04, David Nalley <da...@gnsa.us> wrote:
> 
> 
>> 
>> 
>>> On Fri, Jun 27, 2014 at 4:50 PM, Mark Struberg <st...@yahoo.de> wrote:
>>> as stated tons of times already.
>>> 
>>> There is imo one huge blocker: how to make sure that a pull request which subsequently contains e.g. a commit from ke4qqq@apache.org is REALLY from you?
>>> 
>>> EVERYONE can create such a commit on github! There is NO authorization required! just git-config the email and name. There is no GPG for commits in git, only for tags.
>>> 
>>> People pulling in changes will likely see 'oh a commit from David, fine' and will pull that in.
>>> 
>>> How to prevent that?
>>> 
>>> I asked this 4 years ago and there is still no good answer to it afaik. Without this solved we CANNOT SUFFICIENTLY TRACK OUR CODE PROVENANCE!
>>> 
>>> Or did I miss something?
>>> 
>>> 
>>> ... and sorry for yelling ;)
>> 
>> No need to be sorry.
>> I acknowledge that's a problem. It's also a problem we have today. We
>> accept pull requests from github already, have scores of projects
>> doing so today. It's also a problem with our normal patch submission
>> methods as well. I could send an email with a patch to any number of
>> lists as struberg@apache.org as well, and assuming I did my homework,
>> I could probably emulate the person relatively easily. Accepting
>> patches via email has no authentication either. At a minimum, we at
>> least see the github account that is associated with making the pull
>> request - perhaps we can even improve on the provenance situation by
>> requiring multi-factor authentication for folks with access to the
>> github writable repo, that would give us even better records of
>> provenance than email patch submission.
>> 
>> 
>> --David
>> 
>> 

Re: Writable github repos?

[Mark Struberg <st...@yahoo.de>]

The scenario you mentioned is not valid

a.) I for one do NOT accept pull requests from github! I only apply single requests where I also have a JIRA + diffs
b.) each ASF committer must commit his changes HIMSELF. Committing for others is disregarded.

If you send patches in my name to the list then I will speak up and catch that. And no one will apply those patches, because of b.)
If a patch is tracked by mail + JIRA, then we at least have the remote IP and tons of other stuff like the mx header logged.
In case of any later problem this very commit can be identified very easily.
The same for a pull request leaves no whatever way to even track which commits are in question once the original repo got deleted from github.

Don't get it wrong. I like GIT a lot. I even wrote the initial parts of the german translation for GIT (back in 2006 or so) and the first version of the maven-git-plugin back then. But while I love GIT, I don't think we can use GIT without the push verification we have atm. This is what makes all the difference between GIT projects hosted at the ASF and at somewhere else (not only github).

LieGrue,
strub
 


On Friday, 27 June 2014, 23:04, David Nalley <da...@gnsa.us> wrote:
 

>
>
>On Fri, Jun 27, 2014 at 4:50 PM, Mark Struberg <st...@yahoo.de> wrote:
>> as stated tons of times already.
>>
>> There is imo one huge blocker: how to make sure that a pull request which subsequently contains e.g. a commit from ke4qqq@apache.org is REALLY from you?
>>
>> EVERYONE can create such a commit on github! There is NO authorization required! just git-config the email and name. There is no GPG for commits in git, only for tags.
>>
>> People pulling in changes will likely see 'oh a commit from David, fine' and will pull that in.
>>
>> How to prevent that?
>>
>> I asked this 4 years ago and there is still no good answer to it afaik. Without this solved we CANNOT SUFFICIENTLY TRACK OUR CODE PROVENANCE!
>>
>> Or did I miss something?
>>
>>
>> ... and sorry for yelling ;)
>>
>>
>
>No need to be sorry.
>I acknowledge that's a problem. It's also a problem we have today. We
>accept pull requests from github already, have scores of projects
>doing so today. It's also a problem with our normal patch submission
>methods as well. I could send an email with a patch to any number of
>lists as struberg@apache.org as well, and assuming I did my homework,
>I could probably emulate the person relatively easily. Accepting
>patches via email has no authentication either. At a minimum, we at
>least see the github account that is associated with making the pull
>request - perhaps we can even improve on the provenance situation by
>requiring multi-factor authentication for folks with access to the
>github writable repo, that would give us even better records of
>provenance than email patch submission.
>
>
>--David
>
>
>

Re: Writable github repos?

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

On Fri, Jun 27, 2014 at 4:50 PM, Mark Struberg <st...@yahoo.de> wrote:
> as stated tons of times already.
>
> There is imo one huge blocker: how to make sure that a pull request which subsequently contains e.g. a commit from ke4qqq@apache.org is REALLY from you?
>
> EVERYONE can create such a commit on github! There is NO authorization required! just git-config the email and name. There is no GPG for commits in git, only for tags.
>
> People pulling in changes will likely see 'oh a commit from David, fine' and will pull that in.
>
> How to prevent that?
>
> I asked this 4 years ago and there is still no good answer to it afaik. Without this solved we CANNOT SUFFICIENTLY TRACK OUR CODE PROVENANCE!
>
> Or did I miss something?
>
>
> ... and sorry for yelling ;)
>
>

No need to be sorry.
I acknowledge that's a problem. It's also a problem we have today. We
accept pull requests from github already, have scores of projects
doing so today. It's also a problem with our normal patch submission
methods as well. I could send an email with a patch to any number of
lists as struberg@apache.org as well, and assuming I did my homework,
I could probably emulate the person relatively easily. Accepting
patches via email has no authentication either. At a minimum, we at
least see the github account that is associated with making the pull
request - perhaps we can even improve on the provenance situation by
requiring multi-factor authentication for folks with access to the
github writable repo, that would give us even better records of
provenance than email patch submission.

--David

Re: Writable github repos?

[Dave <sn...@gmail.com>]

On Fri, Jun 27, 2014 at 4:50 PM, Mark Struberg <st...@yahoo.de> wrote:

> as stated tons of times already.
>
> There is imo one huge blocker: how to make sure that a pull request which
> subsequently contains e.g. a commit from ke4qqq@apache.org is REALLY from
> you?
>
> EVERYONE can create such a commit on github! There is NO authorization
> required! just git-config the email and name. There is no GPG for commits
> in git, only for tags.
>
> People pulling in changes will likely see 'oh a commit from David, fine'
> and will pull that in.
>
> How to prevent that?
>
> I asked this 4 years ago and there is still no good answer to it afaik.
> Without this solved we CANNOT SUFFICIENTLY TRACK OUR CODE PROVENANCE!
>
> Or did I miss something?
>


I've got a couple of questions related to that concern:

- If that concern is a blocker then doesn't it mean we cannot accept ANY
code from GitHub at all?

- How does our current best practice for GitHub -> ASF Git integration
address that concern?

- If that concern is a blocker then how can other open source
organizations, who are just as sensitive to IP issues as we are, allow
GitHub hosting?

I don't think we can have a technical solution to the problem of vetting
incoming code. Some committer has to check the incoming changes as best
they can, commit-by-commit and line-by-line, no matter whether it comes
from GitHub or a DIFF patch. If there is some mis-representation (or other
form of evil) in the code, it's the accepting committers job to recognize
that and reject it. I don't see how GitHub is any worse than accepting DIFF
patches in that respect.

- Dave

Re: Writable github repos?

[Mark Struberg <st...@yahoo.de>]

as stated tons of times already.

There is imo one huge blocker: how to make sure that a pull request which subsequently contains e.g. a commit from ke4qqq@apache.org is REALLY from you?

EVERYONE can create such a commit on github! There is NO authorization required! just git-config the email and name. There is no GPG for commits in git, only for tags.

People pulling in changes will likely see 'oh a commit from David, fine' and will pull that in. 

How to prevent that?

I asked this 4 years ago and there is still no good answer to it afaik. Without this solved we CANNOT SUFFICIENTLY TRACK OUR CODE PROVENANCE! 

Or did I miss something?


... and sorry for yelling ;)


LieGrue,
strub



On Friday, 27 June 2014, 22:41, David Nalley <da...@gnsa.us> wrote:
 

>
>
>Hi folks,
>
>Do you have a cup of coffee/tea handy? If not you might want to go get
>one first, this will be a long email with lots of pondering which
>would likely be assisted by a warm beverage.
>
>I am pondering whether it's possible for projects at the ASF to use
>github writable repos.
>
>Let me set the stage for what we have today with github:
>
>* We mirror hundreds of repositories to github [1]
>* We have a comprehensive integration with github [2]
>* A majority of projects that use git as their VCS are using the
>integration and using github as the locus for contribution.
>
>In the github integration model we essentially sync all of the
>happenings from github back to the projects mailing list. (and vice
>versa for those folks who choose to use the mailing list.)
>
>My personal preference is that the ASF is the locus for development
>activity; but I also want to be pragmatic and not force my preferences
>on all of the individual projects. I also recognize that we are part
>way there; by accepting contributions at github and using that
>workflow, we've moved in that direction a bit.
>
>That led me to wondering - what's keeping us from using a writable git
>repo? It's not without problems and challenges.
>
>So that led me tossing together a straw-man proposal in my head for
>what we'd use as an experiment:
>
>Requirements:
>* No guarantee that this will ever emerge from a test, and may be
>discontinued at any time during the test.
>* 6 month term, with monthly reporting for the duration.
>* Test shall consist of a single, mature, healthy, TLP
>* github repo must reside within the Apache organization on github
>* Access would be managed by infra (e.g. projects would not get admin
>access to their repos.
>* Github integration must be enabled with activity flowing to lists.
>* Force rewrites disabled (this is something that must be performed
>out of band by GH staff at present)
>* Commit mails directed to commits@$foo.a.o
>* Github repo synced frequently somewhere on a.o - and backed up.
>
>I've also reached out to folks from Eclipse to discuss their
>experience. Their concerns were project continuity (should github pull
>a CodeSpaces[3]), and IP/Legal concerns. They require a CLA be signed
>for each contribution, so some of that is easily obviated because we
>have no need to audit the author of each pull request to confirm that
>they have a CLA signed. They also have admin access restricted to
>their infrastructure team.
>
>I am sure there are other concerns that I haven't thought about yet;
>so what are they?
>
>Thoughts, comments, flames?
>
>--David
>
>[1] https://github.com/apache
>[2] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
>[3] http://codespaces.com
>
>
>