Three or four small patches is equivalent to three or four branches, one for each version of Hadoop. That seems like a pretty big hassle over the long term.
On Thu, May 31, 2012 at 11:28 AM, Paolo Castagna <castagna.li...@googlemail.com> wrote: > Jakob Homan wrote: >>> While I see no problem in replacing the Hadoop RPC with the Netty >>> implementation >>> Avery contributed, I am not 100% sure about the implications in relation to >>> secure vs. non-secure versions of Hadoop. >> Those running netty in a secure cluster need to know we're totally >> secure. Agreed that we need a better story in this situation. >> >> >>> If changes to support different versions of Hadoop cannot be factored out, >>> another option (IMHO better than the current situation) would be to >>> maintain two >>> or three small patches that people who want to use Giraph with a different >>> version of Hadoop can eventually apply. >> Munging needs to go, the sooner the better; shimming may be in the >> future, although that's not ideal either. One option would be to not >> support older versions aggressively, particularly with cross-version >> rpc compatibility coming soon. But I'd like to avoid a roll-your-own >> approach; we need to officially support and have versions for >> different Hadoops. >> >> -jg > > Jakob, given the fact that the changes to support multiple version of Hadoop > in > Giraph are minimal, do you think it would be possible to maintain three or > four > small patch files in the Giraph trunk and use those instead of munging and/or > shimming? > > We can configure Jenkins to apply each patch and test at each commit. > > This is unusual and I would not propose it if the patches weren't very small > and > not willing to change much. > > Paolo >
