brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [IMPORTANT][PLEASE-READ] Graduation tasks and git repo changes
Date Wed, 02 Dec 2015 18:20:17 GMT
Hi,

Given all the tasks and constraints looks like it's better to prepare 
the repo split in the existing incubator-brooklyn.

For that reason, the incubator-brooklyn repo was made read/write again 
by infra@. The new brooklyn* repos are also r/w, but please, please 
don't push anything there until we are really ready.

This give us some time to move artifacts in the repo to match the new 
structure (in dirs). We won't be able to (and we should not) alter the 
history of incubator-brooklyn, i.e. remove the old, unused, large 
binaries, it should be done in the new repos just before the first push. 
I hope the migration will be tested by a few committers locally. We are 
all PMC members, so any of us could do the first push. I would suggest 
planning and coordinating this to avoid confusion or mistakes.

Thoughts?
Hadrian


On 12/02/2015 06:58 AM, Richard Downer wrote:
> +1 to sticking with incubator-brooklyn for the short term.
>
> The migration we want to do has many steps and it would be best to
> practice it a few times first. Being forced to rush it could be
> counterproductive.
> It would also give us time to clear the PR queue and other
> housekeeping activities.
>
> IIRC infra were also very efficient at activating our Git repositories
> when we first entered the incubator - it caught us off-guard as our
> old GitHub-hosted repository was still in active development. It
> forced us into moving quicker than we were prepared for (we could have
> sorted out the large binary problem at that time, for example). So
> let's not repeat that drama :-)
>
> Cheers
> Richard.
>
>
> On 1 December 2015 at 22:39, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
>> 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
>>>
>>>
>>

Mime
View raw message