+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
