I rebased this morning, but maybe i goofed. I will try again this afternoon. Thanks, Paul
On Sep 23, 2016, at 2:30 PM, Ry Jones <[email protected]> wrote: > Why not rebase o top of his changes? Everyone get changes in without > shenanigans > > On Friday, September 23, 2016, Paul Sigurdson <[email protected]> wrote: > I verified that our changes to BusAttachment.java don’t intersect. An > auto-merge should be successful i would assume. > However, in BusAttachmentTest.java our changes have intersection… as we are > both adding new tests to the end of the file and adding import statements at > the top. > I propose that I drop BusAttachmentTest.jar from my commits that have this > file, and then add this file back in later to my most recent commit (after > Sec2.0 is merged to master). > > Thoughts? > > > On Sep 23, 2016, at 1:42 PM, Paul Sigurdson <[email protected]> wrote: > >> That is 3217. Kristian has reviewed patch-set 7, 8, and 10 of that commit >> and had given +1 on patch-set 8 and 10. So it has been looked at several >> times. >> I pushed a recent patch-set 11 to 3217 that he hasn’t reviewed yet. It is >> simply a change to the BusObjectInfo class to refactor several getter >> methods but where each of the new getter methods is quite similar. >> Maybe 100 lines of simple code affected. >> >> The BusAttachement class that conflicts with Sec2.0 is in a different two >> commits. My changes to BusAttachment were pretty limited (just changed the >> constructor and added a new method and import statement). >> That should most likely not conflict with George’s changes, but I will take >> a look at his changes. >> >> The BusAttachmentTest file might be more likely to have merge issue. >> I could remove the BusAttachmentTest file from my commits, and add it back >> later after Sec2.0 has merged into master??? >> >> -Paul >> >> On Sep 23, 2016, at 1:15 PM, Lioy, Marcello <[email protected]> wrote: >> >>> I have merged a couple of Jorge’s ObjC changes, but others either have -1 >>> or merge conflicts/dependencies. I also noticed that a whole lot of the >>> java changes are now failing Jenkins. Does anyone have any insight into >>> what is going on there? >>> >>> Another specific concern I have is that two of Paul’s changes (8905 and >>> 8871) for dynamic interfaces conflict with three changes related to >>> Secuirty 2.0: >>> >>> <image001.gif>ASACORE-3156 Sec2.0 GetPermissionConfigurator >>> <image001.gif>ASACORE-3156 Sec2 ApplicationStateListener >>> <image001.gif>ASACORE-3156 Sec2 PermissionConfigurationListener >>> >>> Given where we are in the release process I am wondering if we want to skip >>> adding that feature (given the conflicts and that it is easily 3K of new >>> code), I have -1 those two plus the others I saw in this feature set (8903, >>> 8873, 8905, and 8797). >>> >>> Thoughts? >>> _______________________________________________ >>> Allseen-core mailing list >>> [email protected] >>> https://lists.allseenalliance.org/mailman/listinfo/allseen-core >> >
_______________________________________________ Allseen-core mailing list [email protected] https://lists.allseenalliance.org/mailman/listinfo/allseen-core
