--- +1 to patching where we need to , --- but also lets be explicit about what projects we have the resources to maintain patches for ? plz update https://docs.google.com/spreadsheets/d/1ohjbkbLLP7NzOoZEyfhOkCmBSjUcOo8hmuFpkwbE4KM/ if you are commited to maintaining a particular feature in bigtop .
On Sun, Nov 2, 2014 at 12:42 AM, Konstantin Boudnik <[email protected]> wrote: > I think we need to go with the package-specific patching: seems most > natural. > > Cos > > On Sat, Nov 01, 2014 at 09:06PM, Roman Shaposhnik wrote: > > On Wed, Oct 29, 2014 at 4:06 PM, Konstantin Boudnik <[email protected]> > wrote: > > > What Jay said: bigtop doesn't really approve of patching source code > releases > > > from the Apache. However, make build system has a way to do this. And > the > > > question ultimately is "Shall we support patching in gradle build?" > and if yes > > > then "Shall it be better than the one we have in the make?" > > > > > > We just had this chat at the hackathon and I think we should go ahead > and > > > simply drop make build (as has been voted before). And if we need to > have a > > > patching in the gradle build - we'll add it later. > > > > Three points: > > * the current make way of doing things is a total hack and I don't > > think it should live > > * it is true that Bigtop itself doesn't patch, but all the > > commercial vendors using it > > do patch somehow. Now, I know that most of the time patches > > coming from them > > reside in a dedicated branch and are not scattered around as > > .patch files, so perhaps > > we don't need patching that much. > > * both DEB and RPM have native ways of adding patches to the source > packages, > > perhaps the best way is to hook into that? > > > > What do y'all think? > > > > Thanks, > > Roman. > -- jay vyas
