2017-10-06 11:30 GMT+02:00 Ivan Kelly <iv...@apache.org>: > > I think that the best we can do it to always split a commit to minimal > > components, but actually we are working this way > > > > I am struggling with the BP-14 feature because I am trying to split the > > work but without a good result, the patch impacts: > > - client side API > > - zk metadata > > - wire protocol > > - journal > > - LAC protocol > A lot of these pieces can be done independently though. You can put > the metadata stuff a commit, and just have nothing use the new fields. > You can implement the last add synced, without having the different > sync types in the bookie or client. You can implement the sync types > in the bookie, without supporting it in the client. You can do the > client without changing the benchs. > > Obviously you'll probably to touching all over the code when you're > developing the feature, but once it's ready to go, you can build up > your commits. I usually commit a WIP commit at this point, reset back > to master, and use "git add -p". After each commit, stash the > uncommitted, make sure the branch compiles (and tests pass if there's > something dodgy in the patch), rinse and repeat. >
Yes It is like I am trying to do with this (full patch) https://github.com/apache/bookkeeper/pull/529 and this (first part) https://github.com/apache/bookkeeper/pull/531 The problem will arise when I need to address comments in the first patches or I need to rebase to master Thank you for your suggestions Apart from this "huge" new features I think that we are working well with smal bugfixes Enrico > > -Ivan >
