Hmm, I totally get that, but we if we have incubator-brooklyn r/w, then the others should be r/o, otherwise it'll be a mess. To be honest, I didn't expect infra@ to be this instantaneous myself.

Your proposal sounds great to me. If we could do it really fast, I'd personally prefer to just execute and stay with the r/o incubator-brooklyn. If we think it'll take long, I'll try to work with infra to see what would work. It depends on how much bandwidth do folks have to help with the transition.

I'll be on the road for 1.5hrs or so, but will check later and see if I could find somebody in infra@. Normally this is just a simple rename operation of the git repo.

Cheers,
Hadrian

On 12/01/2015 05:18 PM, Alex Heneveld wrote:

Hadrian-

Excellent.  That was fast.

 > 4. The incubator-brooklyn repo is now read-only (or should be, didn't
try to push). We can deal with the 13 remaining PRs later.

Can that be left RW until we are ready to move?  I think there is a fair
amount of prep work we want to do, and warning we want to give people
who may have WIP.  (That was the expectation I set out in the vote
proposal.)

I suggest that we start with someone preparing two scripts, to do the
following:

1) rearrange everything in the incubator repo so that it has the
structure of a parent dir containing all new projects (e.g.
/brooklyn-server/core/ will be in incubator-brooklyn and core/ will no
longer be)

2) git copy with corrected history to the new repo structure


We can review these and make sure we're happy, and we are then in a
position where we can cut over to the new repo at any point.  So we
agree a date when we will do this, then:

3) run the scripts above and commit both (including incubator w new
structure)

4) make a final commit to the incubator project to have a README saying
that it has migrated to a top-level and removing contents (it's all
still in the history but if someone stumbles across it it's better if
they don't see something that looks like an active dev branch; I
appreciate that it won't be mirrored at github however so this isn't
that important)

BTW the reason for doing the file structure changes in situ in incubator
is so that the move to the multiple repos is easier to follow, both for
people and for automation (e.g. git merge, it won't be super simple but
it shouldn't be too tough if all the metadata of renames and moves is in
git).


Best
Alex



On 01/12/2015 21:53, Hadrian Zbarcea wrote:
Hi,

The ASF infra@ was super fast, as usual (or as expected :), dunno) and
most of the work is done on their side. The new git repos are create
and we are entrusted to do the migration ourselves.

Please note that:

1. The new brooklyn* repos are created and visible on the asf site [1]
2. The https://github.com/apache/brooklyn* mirrors are not yet
available, but they are expected to be online sometime after 0700 UTC.
3. We won't be able to rewrite history (force push), but since the new
git repos are empty there is no history, i.e. we have one shot at it!
I would suggest to plan and review the changes before the first push.
Not sure how we could organize this, but please be aware of it. The
goal is to 'rewrite history' and remove the old binaries from the repo.
4. The incubator-brooklyn repo is now read-only (or should be, didn't
try to push). We can deal with the 13 remaining PRs later.
5. Once we confirm everything being in order and properly advertised
we can remove the github mirror for incubator-brooklyn (which will
remain as r/o in the ASF history).

I volunteered us to take ownership of the Jenkins jobs [2], we can fix
those once the new repos are up.

The mailing lists have been migrated too to @brooklyn.apache.org (i.e.
no 'incubator' and all the subscriptions were preserved. You may want
to adjust your mail filters as necessary. We will also need to adjust
the site content in the coming days, all obvious and expected things,
so I'll stop rambling.

Hopefully we will be able to iron out all the kinks in the coming days
and keep the unavoidable disruption to a minimum. If you need
immediate help from me, you should also have my cell phone number.
Please feel free to use it.

Hadrian


[1] https://git.apache.org/
[2] https://issues.apache.org/jira/browse/INFRA-10811

Reply via email to