committer rights for readme.io

[Dmitriy Setrakyan <ds...@apache.org>]

Hi,

We need to setup readme.io to automatically commit to our GIT repo when
documentation is changed. Do we have a GIT user we could reuse for this
purpose or should we setup a new user through INFRA?

D.

Re: committer rights for readme.io

[Konstantin Boudnik <co...@apache.org>]

On Tue, Jun 02, 2015 at 05:41PM, Dmitriy Setrakyan wrote:
> On Tue, Jun 2, 2015 at 4:09 AM, Konstantin Boudnik <co...@apache.org> wrote:
> 
> > On Tue, Jun 02, 2015 at 11:59AM, Branko Čibej wrote:
> > > On 01.06.2015 20:55, Dmitriy Setrakyan wrote:
> > > > Hi,
> > > >
> > > > We need to setup readme.io to automatically commit to our GIT repo
> > when
> > > > documentation is changed. Do we have a GIT user we could reuse for this
> > > > purpose or should we setup a new user through INFRA?
> > >
> > > Definitely a new user with very specific access rights. But have you
> > > considered the security aspects involved here? Who controls the
> > > credentials for this user? How do you guarantee that someone who hacks
> > > readme.io won't suddenly have commit access to ASF repositories?
> > >
> > > IMO, it's better to create a separate repository for the readme.io user
> > > to commit to (doesn't even have to be hosted by the ASF), then someone
> > > from this community can carefully review each change and merge it into
> > > the ASF master repo.
> >
> > Very strong +1 on _not_ having an account in ASF git for a non-committer
> > entity: it potentially might have a number of funny implications, legal and
> > otherwise.
> >
> > Can we have a github fork that will be sending PRs for documentation
> > changes?
> > This will clearly satisfy what Brane has suggested about the reviews, etc.
> >
> 
> Until we figure out the right approach, I have setup a separate GIT
> repository for Ignite documentation and provided readme.io team with
> credentials:
> 
> https://github.com/apacheignite/documentation
> 
> We can mirror this repository to Ignite going forward.

Agree conceptually. But I have a bit of hard time on the implementation side
of it: how would you go about mirroring a git repo elsewhere? The only way I
know is to run a script that will pull in all the references from the remote,
which might be hard to do, considering that INFRA won't be happy about 3rd
party scripts running on their git server. But there might be a trick that I
am just unaware of... surely we'll find out how to do this one way or another.

Cos

Re: committer rights for readme.io

[Dmitriy Setrakyan <ds...@apache.org>]

On Tue, Jun 2, 2015 at 4:09 AM, Konstantin Boudnik <co...@apache.org> wrote:

> On Tue, Jun 02, 2015 at 11:59AM, Branko Čibej wrote:
> > On 01.06.2015 20:55, Dmitriy Setrakyan wrote:
> > > Hi,
> > >
> > > We need to setup readme.io to automatically commit to our GIT repo
> when
> > > documentation is changed. Do we have a GIT user we could reuse for this
> > > purpose or should we setup a new user through INFRA?
> >
> > Definitely a new user with very specific access rights. But have you
> > considered the security aspects involved here? Who controls the
> > credentials for this user? How do you guarantee that someone who hacks
> > readme.io won't suddenly have commit access to ASF repositories?
> >
> > IMO, it's better to create a separate repository for the readme.io user
> > to commit to (doesn't even have to be hosted by the ASF), then someone
> > from this community can carefully review each change and merge it into
> > the ASF master repo.
>
> Very strong +1 on _not_ having an account in ASF git for a non-committer
> entity: it potentially might have a number of funny implications, legal and
> otherwise.
>
> Can we have a github fork that will be sending PRs for documentation
> changes?
> This will clearly satisfy what Brane has suggested about the reviews, etc.
>

Until we figure out the right approach, I have setup a separate GIT
repository for Ignite documentation and provided readme.io team with
credentials:

https://github.com/apacheignite/documentation

We can mirror this repository to Ignite going forward.


> Cos
>

Re: committer rights for readme.io

[Konstantin Boudnik <co...@apache.org>]

On Tue, Jun 02, 2015 at 11:59AM, Branko Čibej wrote:
> On 01.06.2015 20:55, Dmitriy Setrakyan wrote:
> > Hi,
> >
> > We need to setup readme.io to automatically commit to our GIT repo when
> > documentation is changed. Do we have a GIT user we could reuse for this
> > purpose or should we setup a new user through INFRA?
> 
> Definitely a new user with very specific access rights. But have you
> considered the security aspects involved here? Who controls the
> credentials for this user? How do you guarantee that someone who hacks
> readme.io won't suddenly have commit access to ASF repositories?
> 
> IMO, it's better to create a separate repository for the readme.io user
> to commit to (doesn't even have to be hosted by the ASF), then someone
> from this community can carefully review each change and merge it into
> the ASF master repo.

Very strong +1 on _not_ having an account in ASF git for a non-committer
entity: it potentially might have a number of funny implications, legal and
otherwise.

Can we have a github fork that will be sending PRs for documentation changes?
This will clearly satisfy what Brane has suggested about the reviews, etc.

Cos

Re: committer rights for readme.io

[Branko Čibej <br...@apache.org>]

On 01.06.2015 20:55, Dmitriy Setrakyan wrote:
> Hi,
>
> We need to setup readme.io to automatically commit to our GIT repo when
> documentation is changed. Do we have a GIT user we could reuse for this
> purpose or should we setup a new user through INFRA?

Definitely a new user with very specific access rights. But have you
considered the security aspects involved here? Who controls the
credentials for this user? How do you guarantee that someone who hacks
readme.io won't suddenly have commit access to ASF repositories?

IMO, it's better to create a separate repository for the readme.io user
to commit to (doesn't even have to be hosted by the ASF), then someone
from this community can carefully review each change and merge it into
the ASF master repo.

-- Brane