Hi Xiang, On 2018/7/30 10:32, Gao Xiang wrote: > Hi Chao, > > On 2018/7/30 10:07, Chao Yu wrote: >> On 2018/7/29 13:34, Gao Xiang via Linux-erofs wrote: >>> This patch fixes incorrect code snippets due to spilt code >>> into small patches by mistake. >>> >>> Link: https://lists.01.org/pipermail/kbuild-all/2018-July/050747.html >>> Link: https://lists.01.org/pipermail/kbuild-all/2018-July/050750.html >>> Reported-by: kbuild test robot <lkp@xxxxxxxxx> >>> Signed-off-by: Gao Xiang <gaoxiang25@xxxxxxxxxx> >>> --- >>> I test several Kconfig option combinations and all these >>> combinations are successfully compiled. >>> >>> Hi Chao, >>> Could you please review this two patches first before merging >>> into staging-next tree? >> Hi Xiang, >> >> For this compiler issue, I think we only need to cover erofs_shrink_workstation >> with marco CONFIG_EROFS_FS_ZIP, other modification like symbol name change or >> relocate erofs_shrink_workstation are with other reason, so how about separate >> them into different patches? >> >> Thanks, >> > > It seems that Greg merged this patch to staging-next yesterday, since it is a urgent fix > (otherwise erofs cannot be compiled properly without CONFIG_EROFS_FS_ZIP, that is my fault). > > I wrote in a patch yesterday becuase all the modifications have the same root cause ---- > fix incorrect code snippets due to spilt code into small patches by mistake. > > But you are right, it is more proper to spilt into two patches, let me resend these patches later > (I don't know whether Greg will apply them... :-( sorry... ) > > I think in order to reduce Greg's patchwork burden, we could quickly review patches internally in linux-erofs first, > tidy up in a patchset set and send to Greg in a series periodically (if patches are not urgent). > > How do you think about it? I agree with you, as we discussed offline, let's send patch to erofs mailing list for review first, and keep all developing patches in erofs-dev branch as long as possible, then periodically, submitting patches to Greg in batch, it can reduce unneeded modification in staging-next tree. For urgent fix, we can speed up the progress. :) Thanks, > > Thanks, > Gao Xiang > > . > _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
