You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@brooklyn.apache.org by Hadrian Zbarcea <hz...@gmail.com> on 2015/07/23 03:16:36 UTC
[PROPOSAL] Update the package names to org.apache.brooklyn
Hi,
It looks like it's a bit controversial if the package names update is
required or required for graduation. Rob Vesse says that in Jena they
didn't do it for graduation, but they still did it when moved to the
next major release.
Since we are before the 1.0.0 release, unless we want to keep the
brooklyn.* packages for ever, I would suggest doing the package update
to org.apache.brooklyn.* sooner vs than later and plan to release 0.8.0
shortly after.
It looks like it's not easy to shorten the PR queue, so I would favour a
piecemeal approach, even if it would require redoing some of the PRs. I
suspect that with the right granularity, we could avoid conflicts most
of the time.
Thoughts?
Hadrian
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
I've retested the commits in https://github.com/apache/incubator-brooklyn/pull/755 and discarded those that had conflicts.
I've also started https://github.com/apache/incubator-brooklyn/pull/788, which
starts renames from the top projects instead of the leaf projects (following
Hadrian's suggestion).
Please review and merge as soon as possible, so I can continue further. Both
PRs pass maven test target.
On Tuesday 04 August 2015 11:51:10 Aled Sage wrote:
> Hi Hadrian,
>
> Sounds great. Let's do the refactoring asap, as you suggest.
>
> Agree with speed - ensuring that unit tests continually pass. We should
> *not* worry about docs being briefly out-of-date, or lack of a well
> documented upgrade process for backwards compatibility etc, or live
> tests, or manually QA'ing. We can address that in subsequent PRs before
> the next GA release.
>
> Aled
>
> On 01/08/2015 03:55, Hadrian Zbarcea wrote:
> > Now that the PR list is at an all time low, is it a good time to focus
> > next week on refactoring the whole code base? Should we choose to err
> > on the side of speed, or try to keep the code base stable at all times
> > although it may take longer?
> >
> > 3 day notice,
> > Hadrian
> >
> > On 07/24/2015 07:35 AM, Alex Heneveld wrote:
> >> +1 -- let's work on the PR queue then do this. it shouldn't be hard for
> >> folks to update PR's, even if it's a little bit boring.
> >>
> >> worth giving a 3 day heads up maybe?
> >>
> >> best
> >> alex
> >>
> >> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
> >>> Hi,
> >>>
> >>> It looks like it's a bit controversial if the package names update is
> >>> required or required for graduation. Rob Vesse says that in Jena they
> >>> didn't do it for graduation, but they still did it when moved to the
> >>> next major release.
> >>>
> >>> Since we are before the 1.0.0 release, unless we want to keep the
> >>> brooklyn.* packages for ever, I would suggest doing the package update
> >>> to org.apache.brooklyn.* sooner vs than later and plan to release
> >>> 0.8.0 shortly after.
> >>>
> >>> It looks like it's not easy to shorten the PR queue, so I would favour
> >>> a piecemeal approach, even if it would require redoing some of the
> >>> PRs. I suspect that with the right granularity, we could avoid
> >>> conflicts most of the time.
> >>>
> >>> Thoughts?
> >>> Hadrian
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Aled Sage <al...@gmail.com>.
+1 to merging these refactors as soon as asfbot confirms that the tests
pass.
Aled
On 05/08/2015 02:02, Hadrian Zbarcea wrote:
> Quick question, since these are changes that should not impact the
> logic in any way, should we stick to the RTC process or would it be
> preferred to commit a PR as soon as asfbot confirms that the tests pass?
>
> Hadrian
>
> On 08/04/2015 09:01 PM, Hadrian Zbarcea wrote:
>> I created an issue [1] to track this effort. There are couple of PRs
>> already committed. I started on the ./api module, which seems to be the
>> one with the largest impact, the rest is more isolated.
>>
>> I will echo what Aled mentioned below, let's make sure the unit tests
>> pass, otherwise it'll be harder and will take longer to stabilize the
>> code again.
>>
>> Cheers,
>> Hadrian
>>
>> [1] https://issues.apache.org/jira/browse/BROOKLYN-162
>>
>>
>> On 08/04/2015 06:51 AM, Aled Sage wrote:
>>> Hi Hadrian,
>>>
>>> Sounds great. Let's do the refactoring asap, as you suggest.
>>>
>>> Agree with speed - ensuring that unit tests continually pass. We should
>>> *not* worry about docs being briefly out-of-date, or lack of a well
>>> documented upgrade process for backwards compatibility etc, or live
>>> tests, or manually QA'ing. We can address that in subsequent PRs before
>>> the next GA release.
>>>
>>> Aled
>>>
>>>
>>> On 01/08/2015 03:55, Hadrian Zbarcea wrote:
>>>> Now that the PR list is at an all time low, is it a good time to focus
>>>> next week on refactoring the whole code base? Should we choose to err
>>>> on the side of speed, or try to keep the code base stable at all times
>>>> although it may take longer?
>>>>
>>>> 3 day notice,
>>>> Hadrian
>>>>
>>>> On 07/24/2015 07:35 AM, Alex Heneveld wrote:
>>>>>
>>>>> +1 -- let's work on the PR queue then do this. it shouldn't be hard
>>>>> for
>>>>> folks to update PR's, even if it's a little bit boring.
>>>>>
>>>>> worth giving a 3 day heads up maybe?
>>>>>
>>>>> best
>>>>> alex
>>>>>
>>>>>
>>>>> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
>>>>>> Hi,
>>>>>>
>>>>>> It looks like it's a bit controversial if the package names
>>>>>> update is
>>>>>> required or required for graduation. Rob Vesse says that in Jena
>>>>>> they
>>>>>> didn't do it for graduation, but they still did it when moved to the
>>>>>> next major release.
>>>>>>
>>>>>> Since we are before the 1.0.0 release, unless we want to keep the
>>>>>> brooklyn.* packages for ever, I would suggest doing the package
>>>>>> update
>>>>>> to org.apache.brooklyn.* sooner vs than later and plan to release
>>>>>> 0.8.0 shortly after.
>>>>>>
>>>>>> It looks like it's not easy to shorten the PR queue, so I would
>>>>>> favour
>>>>>> a piecemeal approach, even if it would require redoing some of the
>>>>>> PRs. I suspect that with the right granularity, we could avoid
>>>>>> conflicts most of the time.
>>>>>>
>>>>>> Thoughts?
>>>>>> Hadrian
>>>>>
>>>>>
>>>
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Quick question, since these are changes that should not impact the logic
in any way, should we stick to the RTC process or would it be preferred
to commit a PR as soon as asfbot confirms that the tests pass?
Hadrian
On 08/04/2015 09:01 PM, Hadrian Zbarcea wrote:
> I created an issue [1] to track this effort. There are couple of PRs
> already committed. I started on the ./api module, which seems to be the
> one with the largest impact, the rest is more isolated.
>
> I will echo what Aled mentioned below, let's make sure the unit tests
> pass, otherwise it'll be harder and will take longer to stabilize the
> code again.
>
> Cheers,
> Hadrian
>
> [1] https://issues.apache.org/jira/browse/BROOKLYN-162
>
>
> On 08/04/2015 06:51 AM, Aled Sage wrote:
>> Hi Hadrian,
>>
>> Sounds great. Let's do the refactoring asap, as you suggest.
>>
>> Agree with speed - ensuring that unit tests continually pass. We should
>> *not* worry about docs being briefly out-of-date, or lack of a well
>> documented upgrade process for backwards compatibility etc, or live
>> tests, or manually QA'ing. We can address that in subsequent PRs before
>> the next GA release.
>>
>> Aled
>>
>>
>> On 01/08/2015 03:55, Hadrian Zbarcea wrote:
>>> Now that the PR list is at an all time low, is it a good time to focus
>>> next week on refactoring the whole code base? Should we choose to err
>>> on the side of speed, or try to keep the code base stable at all times
>>> although it may take longer?
>>>
>>> 3 day notice,
>>> Hadrian
>>>
>>> On 07/24/2015 07:35 AM, Alex Heneveld wrote:
>>>>
>>>> +1 -- let's work on the PR queue then do this. it shouldn't be hard
>>>> for
>>>> folks to update PR's, even if it's a little bit boring.
>>>>
>>>> worth giving a 3 day heads up maybe?
>>>>
>>>> best
>>>> alex
>>>>
>>>>
>>>> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
>>>>> Hi,
>>>>>
>>>>> It looks like it's a bit controversial if the package names update is
>>>>> required or required for graduation. Rob Vesse says that in Jena they
>>>>> didn't do it for graduation, but they still did it when moved to the
>>>>> next major release.
>>>>>
>>>>> Since we are before the 1.0.0 release, unless we want to keep the
>>>>> brooklyn.* packages for ever, I would suggest doing the package update
>>>>> to org.apache.brooklyn.* sooner vs than later and plan to release
>>>>> 0.8.0 shortly after.
>>>>>
>>>>> It looks like it's not easy to shorten the PR queue, so I would favour
>>>>> a piecemeal approach, even if it would require redoing some of the
>>>>> PRs. I suspect that with the right granularity, we could avoid
>>>>> conflicts most of the time.
>>>>>
>>>>> Thoughts?
>>>>> Hadrian
>>>>
>>>>
>>
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Hadrian Zbarcea <hz...@gmail.com>.
I created an issue [1] to track this effort. There are couple of PRs
already committed. I started on the ./api module, which seems to be the
one with the largest impact, the rest is more isolated.
I will echo what Aled mentioned below, let's make sure the unit tests
pass, otherwise it'll be harder and will take longer to stabilize the
code again.
Cheers,
Hadrian
[1] https://issues.apache.org/jira/browse/BROOKLYN-162
On 08/04/2015 06:51 AM, Aled Sage wrote:
> Hi Hadrian,
>
> Sounds great. Let's do the refactoring asap, as you suggest.
>
> Agree with speed - ensuring that unit tests continually pass. We should
> *not* worry about docs being briefly out-of-date, or lack of a well
> documented upgrade process for backwards compatibility etc, or live
> tests, or manually QA'ing. We can address that in subsequent PRs before
> the next GA release.
>
> Aled
>
>
> On 01/08/2015 03:55, Hadrian Zbarcea wrote:
>> Now that the PR list is at an all time low, is it a good time to focus
>> next week on refactoring the whole code base? Should we choose to err
>> on the side of speed, or try to keep the code base stable at all times
>> although it may take longer?
>>
>> 3 day notice,
>> Hadrian
>>
>> On 07/24/2015 07:35 AM, Alex Heneveld wrote:
>>>
>>> +1 -- let's work on the PR queue then do this. it shouldn't be hard for
>>> folks to update PR's, even if it's a little bit boring.
>>>
>>> worth giving a 3 day heads up maybe?
>>>
>>> best
>>> alex
>>>
>>>
>>> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
>>>> Hi,
>>>>
>>>> It looks like it's a bit controversial if the package names update is
>>>> required or required for graduation. Rob Vesse says that in Jena they
>>>> didn't do it for graduation, but they still did it when moved to the
>>>> next major release.
>>>>
>>>> Since we are before the 1.0.0 release, unless we want to keep the
>>>> brooklyn.* packages for ever, I would suggest doing the package update
>>>> to org.apache.brooklyn.* sooner vs than later and plan to release
>>>> 0.8.0 shortly after.
>>>>
>>>> It looks like it's not easy to shorten the PR queue, so I would favour
>>>> a piecemeal approach, even if it would require redoing some of the
>>>> PRs. I suspect that with the right granularity, we could avoid
>>>> conflicts most of the time.
>>>>
>>>> Thoughts?
>>>> Hadrian
>>>
>>>
>
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Aled Sage <al...@gmail.com>.
Hi Hadrian,
Sounds great. Let's do the refactoring asap, as you suggest.
Agree with speed - ensuring that unit tests continually pass. We should
*not* worry about docs being briefly out-of-date, or lack of a well
documented upgrade process for backwards compatibility etc, or live
tests, or manually QA'ing. We can address that in subsequent PRs before
the next GA release.
Aled
On 01/08/2015 03:55, Hadrian Zbarcea wrote:
> Now that the PR list is at an all time low, is it a good time to focus
> next week on refactoring the whole code base? Should we choose to err
> on the side of speed, or try to keep the code base stable at all times
> although it may take longer?
>
> 3 day notice,
> Hadrian
>
> On 07/24/2015 07:35 AM, Alex Heneveld wrote:
>>
>> +1 -- let's work on the PR queue then do this. it shouldn't be hard for
>> folks to update PR's, even if it's a little bit boring.
>>
>> worth giving a 3 day heads up maybe?
>>
>> best
>> alex
>>
>>
>> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
>>> Hi,
>>>
>>> It looks like it's a bit controversial if the package names update is
>>> required or required for graduation. Rob Vesse says that in Jena they
>>> didn't do it for graduation, but they still did it when moved to the
>>> next major release.
>>>
>>> Since we are before the 1.0.0 release, unless we want to keep the
>>> brooklyn.* packages for ever, I would suggest doing the package update
>>> to org.apache.brooklyn.* sooner vs than later and plan to release
>>> 0.8.0 shortly after.
>>>
>>> It looks like it's not easy to shorten the PR queue, so I would favour
>>> a piecemeal approach, even if it would require redoing some of the
>>> PRs. I suspect that with the right granularity, we could avoid
>>> conflicts most of the time.
>>>
>>> Thoughts?
>>> Hadrian
>>
>>
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Hadrian Zbarcea <hz...@gmail.com>.
Now that the PR list is at an all time low, is it a good time to focus
next week on refactoring the whole code base? Should we choose to err on
the side of speed, or try to keep the code base stable at all times
although it may take longer?
3 day notice,
Hadrian
On 07/24/2015 07:35 AM, Alex Heneveld wrote:
>
> +1 -- let's work on the PR queue then do this. it shouldn't be hard for
> folks to update PR's, even if it's a little bit boring.
>
> worth giving a 3 day heads up maybe?
>
> best
> alex
>
>
> On 23/07/2015 02:16, Hadrian Zbarcea wrote:
>> Hi,
>>
>> It looks like it's a bit controversial if the package names update is
>> required or required for graduation. Rob Vesse says that in Jena they
>> didn't do it for graduation, but they still did it when moved to the
>> next major release.
>>
>> Since we are before the 1.0.0 release, unless we want to keep the
>> brooklyn.* packages for ever, I would suggest doing the package update
>> to org.apache.brooklyn.* sooner vs than later and plan to release
>> 0.8.0 shortly after.
>>
>> It looks like it's not easy to shorten the PR queue, so I would favour
>> a piecemeal approach, even if it would require redoing some of the
>> PRs. I suspect that with the right granularity, we could avoid
>> conflicts most of the time.
>>
>> Thoughts?
>> Hadrian
>
>
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Alex Heneveld <al...@cloudsoftcorp.com>.
+1 -- let's work on the PR queue then do this. it shouldn't be hard for
folks to update PR's, even if it's a little bit boring.
worth giving a 3 day heads up maybe?
best
alex
On 23/07/2015 02:16, Hadrian Zbarcea wrote:
> Hi,
>
> It looks like it's a bit controversial if the package names update is
> required or required for graduation. Rob Vesse says that in Jena they
> didn't do it for graduation, but they still did it when moved to the
> next major release.
>
> Since we are before the 1.0.0 release, unless we want to keep the
> brooklyn.* packages for ever, I would suggest doing the package update
> to org.apache.brooklyn.* sooner vs than later and plan to release
> 0.8.0 shortly after.
>
> It looks like it's not easy to shorten the PR queue, so I would favour
> a piecemeal approach, even if it would require redoing some of the
> PRs. I suspect that with the right granularity, we could avoid
> conflicts most of the time.
>
> Thoughts?
> Hadrian
--
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
This e-mail message is confidential and for use by the addressee only. If
the message is received by anyone other than the addressee, please return
the message to the sender by replying to it and then delete the message
from your computer. Internet e-mails are not necessarily secure. Cloudsoft
Corporation Limited does not accept responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Cloudsoft Corporation Limited in this regard and the recipient
should carry out such virus and other checks as it considers appropriate.
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
I just found that the latest PRs accepted into master broke my rename PR.
Since you've scheduled some work in this field for the beginning of next week
I'll rebase my branch and fix the PR.
On Wednesday 22 July 2015 23:50:35 Aled Sage wrote:
> +1 to renaming the packages.
>
> Whether the next release is then 0.8.0 or 1.0.0 is up for debate.
>
> With a concerted effort, I'm sure we can significantly reduce the PR
> queue. I suggest we do the package renames early next week - giving us a
> few days for merging PRs. Focused/localised changes like renaming
> packages in the REST api could be done before then.
>
> Aled
>
> On 22/07/2015 18:16, Hadrian Zbarcea wrote:
> > Hi,
> >
> > It looks like it's a bit controversial if the package names update is
> > required or required for graduation. Rob Vesse says that in Jena they
> > didn't do it for graduation, but they still did it when moved to the
> > next major release.
> >
> > Since we are before the 1.0.0 release, unless we want to keep the
> > brooklyn.* packages for ever, I would suggest doing the package update
> > to org.apache.brooklyn.* sooner vs than later and plan to release
> > 0.8.0 shortly after.
> >
> > It looks like it's not easy to shorten the PR queue, so I would favour
> > a piecemeal approach, even if it would require redoing some of the
> > PRs. I suspect that with the right granularity, we could avoid
> > conflicts most of the time.
> >
> > Thoughts?
> > Hadrian
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Ciprian Ciubotariu <ch...@gmx.net>.
Take a look at PR 755 at https://github.com/apache/incubator-brooklyn/pull/755.
Each commit performs the appropriate rename on a single project, and their
dependent projects. As I am approaching the core packages, the list of PRs
should be cleared first, but I believe all of my commits there won't encounter
conflicts.
I will continue with the CAMP-related projects for today, which seem to not be
affected by pull requests.
Ciprian
On Wednesday 22 July 2015 23:50:35 Aled Sage wrote:
> +1 to renaming the packages.
>
> Whether the next release is then 0.8.0 or 1.0.0 is up for debate.
>
> With a concerted effort, I'm sure we can significantly reduce the PR
> queue. I suggest we do the package renames early next week - giving us a
> few days for merging PRs. Focused/localised changes like renaming
> packages in the REST api could be done before then.
>
> Aled
>
> On 22/07/2015 18:16, Hadrian Zbarcea wrote:
> > Hi,
> >
> > It looks like it's a bit controversial if the package names update is
> > required or required for graduation. Rob Vesse says that in Jena they
> > didn't do it for graduation, but they still did it when moved to the
> > next major release.
> >
> > Since we are before the 1.0.0 release, unless we want to keep the
> > brooklyn.* packages for ever, I would suggest doing the package update
> > to org.apache.brooklyn.* sooner vs than later and plan to release
> > 0.8.0 shortly after.
> >
> > It looks like it's not easy to shorten the PR queue, so I would favour
> > a piecemeal approach, even if it would require redoing some of the
> > PRs. I suspect that with the right granularity, we could avoid
> > conflicts most of the time.
> >
> > Thoughts?
> > Hadrian
Re: [PROPOSAL] Update the package names to org.apache.brooklyn
Posted by Aled Sage <al...@gmail.com>.
+1 to renaming the packages.
Whether the next release is then 0.8.0 or 1.0.0 is up for debate.
With a concerted effort, I'm sure we can significantly reduce the PR
queue. I suggest we do the package renames early next week - giving us a
few days for merging PRs. Focused/localised changes like renaming
packages in the REST api could be done before then.
Aled
On 22/07/2015 18:16, Hadrian Zbarcea wrote:
> Hi,
>
> It looks like it's a bit controversial if the package names update is
> required or required for graduation. Rob Vesse says that in Jena they
> didn't do it for graduation, but they still did it when moved to the
> next major release.
>
> Since we are before the 1.0.0 release, unless we want to keep the
> brooklyn.* packages for ever, I would suggest doing the package update
> to org.apache.brooklyn.* sooner vs than later and plan to release
> 0.8.0 shortly after.
>
> It looks like it's not easy to shorten the PR queue, so I would favour
> a piecemeal approach, even if it would require redoing some of the
> PRs. I suspect that with the right granularity, we could avoid
> conflicts most of the time.
>
> Thoughts?
> Hadrian