brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Downer <rich...@apache.org>
Subject Re: [HEADS-UP] Brooklyn graduation
Date Wed, 18 Nov 2015 20:22:58 GMT
+1 - that sounds like a good idea. I'd suggest that - at least
initially - the docs go into this repository.

I'm still not convinced about the versioning - BUT that is a separate
issue and won't block consensus for splitting the repositories.

Hadrian, any thoughts on the feasibility of editing the history to
remove the large binary objects? That seems to have to got lost in
this thread.

Richard.



On 18 November 2015 at 19:02, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
> Do you see apache/brooklyn as being the distro project? If that's the case
> +1 from me.
>
> Hadrian
>
>
> On 11/18/2015 01:59 PM, Alex Heneveld wrote:
>>
>> For external relations purposes and as an umbrella should we also have
>> apache/brooklyn ?
>>
>> I tend to think yes.
>>
>> Best
>> Alex
>> On 18 Nov 2015 17:55, "Hadrian Zbarcea" <hzbarcea@gmail.com> wrote:
>>
>>> So I see a lot of consensus on Alex's proposal with the following
>>> amendment (s/brooklyn/brooklyn-core/):
>>> * apache/brooklyn-core
>>> * apache/brooklyn-ui
>>> * apache/brooklyn-library
>>>
>>> If we can get a consensus on this I don't think we need to go to a vote.
>>> I
>>> will address the other comments as direct replies, because I don't see
>>> them
>>> as contradictory to this proposal.
>>>
>>> WDYT?
>>> Hadrian
>>>
>>> On 11/17/2015 12:44 PM, Alex Heneveld wrote:
>>>
>>>>
>>>> +1 to removing the large artifacts; it's just stupid having them there.
>>>>
>>>> Personally I would like to see the apache/incubator-brooklyn carved up
>>>> as follows:
>>>>
>>>> * apache/brooklyn
>>>> * apache/brooklyn-ui
>>>> * apache/brooklyn-library
>>>>
>>>> The third one contains all the concrete items, like jboss and tomcat and
>>>> cassandra etc.  The UI is the jsgui.
>>>>
>>>> The first one is the main one, with everything else, including CLI and
>>>> REST API, vanilla software process, and jclouds locations and osgi.
>>>>
>>>>
>>>> The only other thing I'm wondering is whether brooklyn-api should be
>>>> separate, and very rarely changing.  This would allow us potentially to
>>>> run different versions of brooklyn-* in the same system, using the magic
>>>> of OSGi.
>>>>
>>>>
>>>> WDYT?
>>>>
>>>> Best
>>>> Alex
>>>>
>>>>
>>>> On 17/11/2015 17:03, Richard Downer wrote:
>>>>
>>>>> Hi Hadrian,
>>>>>
>>>>> I don't think there's any need to split the repository (although I've
>>>>> no strong opinions on this, if someone else has an idea).
>>>>>
>>>>> However there has been a long-standing issue with our repository's
>>>>> history - in the dim and distant past, binary artifacts of Tomcat etc.
>>>>> used for testing were committed to the repository. These are long
>>>>> gone, but they still exist in the git history, and everybody is forced
>>>>> to clone these large artifacts.
>>>>>
>>>>> Could we use the graduation migration as an opportunity to rewrite the
>>>>> git history to permanently remove these large artifacts? It'd result
>>>>> in a much quicker clone of the repo for new contributors to Brooklyn.
>>>>>
>>>>> Richard.
>>>>>
>>>>>
>>>>> On 17 November 2015 at 00:58, Hadrian Zbarcea <hzbarcea@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello Brooklyners,
>>>>>>
>>>>>> The Brooklyn graduation resolution is again on the board agenda.
This
>>>>>> time I
>>>>>> paid paranoid attention to details and I hope the stars to be better
>>>>>> aligned.
>>>>>>
>>>>>> Assuming all goes well, there will be a few tasks to take care post
>>>>>> graduation, mostly related to dropping the "incubating" suffix. Part
>>>>>> of that
>>>>>> process it is possible to split the git repository into multiple
>>>>>> smaller
>>>>>> ones. It is possible to do it later, but doing it now would be easier
>>>>>> and
>>>>>> more natural, I think.
>>>>>>
>>>>>> Therefore, if anybody has any idea or proposal related to that, speak
>>>>>> up
>>>>>> now. In the absence of consensus the status quo will be maintained.
I
>>>>>> will
>>>>>> work with infra and try to make the process as smooth as possible
for
>>>>>> the
>>>>>> community regardless of which way we decide to go.
>>>>>>
>>>>>> Cheers,
>>>>>> Hadrian
>>>>>>
>>>>>
>>>>
>>
>

Mime
View raw message