jclouds-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ignasi Barrera <n...@apache.org>
Subject Re: Moving to the ASF github organization
Date Thu, 01 Nov 2018 12:06:08 GMT
Write access will not change. PMC members and committers will be the ones
to have write access to the repos.

Regarding permissions to manage PR, etc, we will be able to do all that.
BigTop can't do that because it is in the old "git-wip", not GitBox. GitBox
is the new Git service from the ASF that is fully integrated with GitHub.
Using GitBox you can merge PRs, etc, and have a normal GitHub workflow.
If we want to keep pushing directly to the ASF remote we can do that, but
we'll be able to just push to GitHub. Unlike the old git-wip, code is
mirrored both ways.

So, there are no changes to our process if we don't want to, but we'll also
be able to just use GitHub normally. Up to each one to pick their preferred
way of merging stuff :)


Regarding archiving, yeah, that sounds like the way to go.



On Thu, 1 Nov 2018 at 10:01, Olaf Flebbe <of@oflebbe.de> wrote:

> Hi,
>
> In Apache Bigtop the creator of the github pull request has to close it as
> well, so nothing special I suppose.
> Committers and PMC have no special permission to resolve pull requests.
>
> Regards,
> Olaf
>
> > Am 01.11.2018 um 06:38 schrieb Andrew Gaul <gaul@apache.org>:
> >
> > Following standard Apache processes should be a goal.  However, we need
> > to fix our apache/jclouds permissions to even match the existing
> > jclouds/jclouds workflow.  I could not close a pull request here:
> >
> > https://github.com/apache/jclouds/pull/3
> >
> > Could we move incrementally, experimenting with the new workflow with
> > the most active committers and contributors, before cutting the cord on
> > the old workflow?
> >
> > On Wed, Oct 31, 2018 at 01:06:47PM +0100, Ignasi Barrera wrote:
> >> Hi!
> >>
> >> There was a recent issue [1] with the repo sync that brought up to the
> >> table our particular use of GitHub. During our incubation period, the
> ASF
> >> was still studying how the GitHub integration would be, and by then we
> were
> >> allowed to graduate and keep using our GitHub org, as long as every
> single
> >> GitHub interaction reached a project mailing list, and we used the ASF
> Git
> >> remote as the canonical repo.
> >>
> >> That is fine, but I'd like to propose to move to the ASF organization.
> The
> >> ASF provides GitBox now, which allows to directly write on GitHub repos.
> >> Moving to the ASF org would mean:
> >>
> >> * We can continue doing our stuff as-usual.
> >> * We'll be able to use GitHub features directly (merge PRs, etc).
> >> * We won't need our custom sync jobs to get our org in sync.
> >>
> >> * We'll have to "deprecate" the old organization and move users to the
> new
> >> one. We can take as much time as we need for this. My suggested approach
> >> would be to:
> >>  - For any incoming new pull request, ask the contributor to open it
> >> against the Apache org.
> >>  - Review existing PRs and push them to the gitbox remote.
> >>  - Close old and stale pull requests and ask the contributor to reopen
> >> against the Apache org.
> >>  - Cleanup the repo contents and leave just a README with a link to the
> >> new repos.
> >>
> >> I see this as part of migrating existing legacy stuff to its proper home
> >> (we are also transitioning our CI to the ASF Jenkins), which I think is
> a
> >> positive thing.
> >>
> >>
> >> What do you think about this move? Worth doing?
> >>
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/INFRA-16889
> >
> > --
> > Andrew Gaul
> > http://gaul.org/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message