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.