You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Roman Shaposhnik <ro...@shaposhnik.org> on 2014/11/02 05:06:00 UTC

Re: Is bigtop based on a branch or tarball release?

On Wed, Oct 29, 2014 at 4:06 PM, Konstantin Boudnik <co...@apache.org> 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.

Re: Is bigtop based on a branch or tarball release?

Posted by jay vyas <ja...@gmail.com>.
---  +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 <co...@apache.org> 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 <co...@apache.org>
> 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

Re: Is bigtop based on a branch or tarball release?

Posted by Konstantin Boudnik <co...@apache.org>.
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 <co...@apache.org> 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.