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
