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



Reply via email to