We can archive the repositories, similar to what we did for
legacy-jclouds:
https://github.com/jclouds/legacy-jclouds
On Wed, Oct 31, 2018 at 01:58:55PM +0100, Andrea Turli wrote:
> Thanks Ignasi for bringing this up.
>
> I think I'd prefer to go with the "recommended" ASF way using the tools
>
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 n
LGTM Ignasi,
When you say "We can continue doing our stuff as-usual" but also "We'll be
able to use GitHub features directly (merge PRs, etc)", do you mean the
merge/commit process will change to use Github or we'll keep both ways? I
guess we should just move to GH features, to keep it simple.
It
Hi Ignasi,
Who would be getting the access for GitBox? Do new users would also get
access? And if possible, can you please share the reference to request
access?
Please share if there any other reference documents for same.
Thanks
Nishant
On Wed, Oct 31, 2018 at 7:07 AM Ignasi Barrera wrote:
>
Thanks Ignasi for bringing this up.
I think I'd prefer to go with the "recommended" ASF way using the tools
offered by them
I'm not familiar with GitBox and maybe others are in my same position so I
think it could be useful to have docs to evaluate the GitBox option (how
much overhead is required
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 singl