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/07/12 07:54:52 UTC
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I am temporarily putting the [VOTE] thread to halt and instead starting
> [DISCUSS]. Per Jay's:
>
> BIGTOP-1314 highlights the fact that we now have 2 build systems: Makefile
> and build.gradle. And the fact that the Makefile approach is now
> deprecated.
>
> As per Mark's suggestion in that JIRA, the future of Makefile should be
> decided on the mailing list before the next JIRA comes out to further
> distance from Make and embrace gradle.
>
> Should we continue to support the Makefile builder?
I'd be more than happy to get rid of it right after we release Bigtop 0.8.0
Thanks,
Roman.
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Mark Grover <ma...@apache.org>.
I agree with the general sentiment here on the thread.
Since Sean proposed a meetup next week, perhaps, we can kill two birds with
one stone and do some sort of Gradle walk through then? Cos/Roman: would
you be available at that time?
Mark
On Mon, Jul 14, 2014 at 1:46 PM, Andrew Purtell <ap...@apache.org> wrote:
> I don't think we need to assume the dysfunctions of other communities are
> operative here. I trust this community to summarize a hangout discussion
> sufficient for me to follow along if I can't make it, no problem.
>
> My point of view is pretty close to Sean's. I can see that Gradle is
> preferred by many, and looks like a plausible way forward. It's taken me
> some effort to make progress with the almost inscrutable makefiles before.
> That said I think we should have a release (0.8 looks like) where both
> build systems are available and one can do the same set of build and test
> actions with either. Then we can drop one in 0.9. Totally fine with a
> consensus decision on which one.
>
>
> On Mon, Jul 14, 2014 at 8:59 AM, Sean Mackrory <ma...@gmail.com>
> wrote:
>
> > I personally like that idea, and it would probably be beneficial even if
> it
> > wasn't the mechanism by which we made the decision, but the whole reason
> > we're having this discussion is because of concern raised about the
> > decision not being made on the mailing list. I know of one project where
> a
> > design document was posted for discussion, a call was scheduled on the
> > mailing list with international toll-free numbers and a recording, and
> > plenty of time for discussion after the call before a decision was made,
> > and this was still considered too closed of a decision. I suspect a
> hangout
> > might also violate the same criteria :)
> >
> > Perhaps if someone very familiar with the gradle code were to post a
> > screencast of them walking through the code and demonstrating the build,
> > that would allow all decision making to be on the list and help to
> resolve
> > the concerns already discussed?
> >
> >
> > On Mon, Jul 14, 2014 at 9:06 AM, jay vyas <ja...@gmail.com>
> > wrote:
> >
> > > I agree wiith mark that we need to make it easy and individuals in the
> > > community need to be comfortable with the transition. I propose a
> > solution
> > > at the end o this email.
> > >
> > > Heres where we are at:
> > >
> > > - Realistically, the debate on which is "better" is not going to be
> very
> > > fruitful.... We all know the high-level pros and cons of both Makefile
> > and
> > > build.gradle .
> > >
> > > - Neither is perfect,but > 50% of community parties agree gradle is a
> > step
> > > forward.
> > >
> > > jay +.1 (im netural with a slight lean to gradle)
> > > cos, roman, sean, +3 (all are ready to move forward)
> > > mark effectively might say is a -1
> > >
> > > ************* - But we don't want to leave anyone behind!
> > > **********************
> > >
> > > But we also need to move fast ! We dont want a schizophrenic or forked
> > > community.
> > >
> > > SO HERE IS MY SUGGESTION:
> > >
> > > 1) we schedule a meetup, or a screencast - specifically to go through
> the
> > > gradle code - from A to Z -
> > > 2) We validate and build all of bigtop, using gradle, during the
> > > screencast. NO EXCEPTIONS. That way we are all 100% sure that it
> > works,
> > > and we see it in action.
> > > 3) After that screen cast, we ensure that we have a unified community
> > which
> > > can self-sufficiently administer the gradle based build - as soon as
> > > possible.
> > > 4) If all parties to (1) agree that they are now ready , we delete the
> > > Makefile forever, in a patch which updates the README file with
> excellent
> > > explanation of how the build.gradle works.
> > >
> > > This is the most rapid way to move the entire community forward in
> unison
> > > and prevent code rot of maintaining duplicate features .
> > >
> > > Mark, and others, how do you feel about this idea?
> > >
> > >
> > >
> > > On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <
> > grover.markgrover@gmail.com>
> > > wrote:
> > >
> > > > Thanks for starting this thread, Jay and Cos.
> > > >
> > > > Here are my thoughts:
> > > > Gradle may actually be a better choice for Bigtop. However, in my
> > > opinion,
> > > > Make should be kept around for a little while to make the transition
> > easy
> > > > for the community.
> > > >
> > > > I would go as far as saying that we shouldn't be deprecating Make
> right
> > > > now. In my opinion, it's best to have a transition period where we
> all
> > > > support both Gradle and Make. During this time, contributors and
> > > committers
> > > > work (albeit, with a little extra pain) with both and develop their
> > own
> > > > opinion on which tool is the best for the project. Some of us may
> > already
> > > > have developed such experience by using various tools in the past
> while
> > > > others may have not. The idea is to give all members of the community
> > an
> > > > opportunity to make such a decision for themselves and share them
> with
> > > the
> > > > community.
> > > > And, consequently, the official decision to deprecate a tool from the
> > > > project shouldn't happen before this transition period, but after.
> > > >
> > > > Hope that makes sense.
> > > > Mark
> > > >
> > > >
> > > >
> > > > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <mackrorysd@gmail.com
> >
> > > > wrote:
> > > >
> > > > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > > > >
> > > > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much
> > > prefer
> > > > > debugging a more modern language, and as Cos points out, it's
> > intended
> > > > for
> > > > > a JVM ecosystem but can do other things when needed.
> > > > > - I'd prefer we leave Make around for perhaps one more release just
> > to
> > > > > really solidify the Gradle system a bit more. However if we keep it
> > > > > deprecated, I see no point in "maintaining" both, meaning that if
> > > people
> > > > > want to add new features to the build (several JIRAs going on for
> > that
> > > > > right now) - there's no need to keep adding that to the Makefile,
> > let's
> > > > > just keep the versions and metadata for new projects up to date. I
> > > don't
> > > > > believe we routinely run into bugs, so I doubt much work will have
> to
> > > be
> > > > > put in outside of bigtop.mk.
> > > > >
> > > > >
> > > > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <
> > > roman@shaposhnik.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <
> > cos@apache.org>
> > > > > > wrote:
> > > > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > > > starting
> > > > > > > [DISCUSS]. Per Jay's:
> > > > > > >
> > > > > > > BIGTOP-1314 highlights the fact that we now have 2 build
> systems:
> > > > > > Makefile
> > > > > > > and build.gradle. And the fact that the Makefile approach is
> now
> > > > > > > deprecated.
> > > > > > >
> > > > > > > As per Mark's suggestion in that JIRA, the future of Makefile
> > > should
> > > > be
> > > > > > > decided on the mailing list before the next JIRA comes out to
> > > further
> > > > > > > distance from Make and embrace gradle.
> > > > > > >
> > > > > > > Should we continue to support the Makefile builder?
> > > > > >
> > > > > > I'd be more than happy to get rid of it right after we release
> > Bigtop
> > > > > 0.8.0
> > > > > >
> > > > > > Thanks,
> > > > > > Roman.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > jay vyas
> > >
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Andrew Purtell <ap...@apache.org>.
I don't think we need to assume the dysfunctions of other communities are
operative here. I trust this community to summarize a hangout discussion
sufficient for me to follow along if I can't make it, no problem.
My point of view is pretty close to Sean's. I can see that Gradle is
preferred by many, and looks like a plausible way forward. It's taken me
some effort to make progress with the almost inscrutable makefiles before.
That said I think we should have a release (0.8 looks like) where both
build systems are available and one can do the same set of build and test
actions with either. Then we can drop one in 0.9. Totally fine with a
consensus decision on which one.
On Mon, Jul 14, 2014 at 8:59 AM, Sean Mackrory <ma...@gmail.com> wrote:
> I personally like that idea, and it would probably be beneficial even if it
> wasn't the mechanism by which we made the decision, but the whole reason
> we're having this discussion is because of concern raised about the
> decision not being made on the mailing list. I know of one project where a
> design document was posted for discussion, a call was scheduled on the
> mailing list with international toll-free numbers and a recording, and
> plenty of time for discussion after the call before a decision was made,
> and this was still considered too closed of a decision. I suspect a hangout
> might also violate the same criteria :)
>
> Perhaps if someone very familiar with the gradle code were to post a
> screencast of them walking through the code and demonstrating the build,
> that would allow all decision making to be on the list and help to resolve
> the concerns already discussed?
>
>
> On Mon, Jul 14, 2014 at 9:06 AM, jay vyas <ja...@gmail.com>
> wrote:
>
> > I agree wiith mark that we need to make it easy and individuals in the
> > community need to be comfortable with the transition. I propose a
> solution
> > at the end o this email.
> >
> > Heres where we are at:
> >
> > - Realistically, the debate on which is "better" is not going to be very
> > fruitful.... We all know the high-level pros and cons of both Makefile
> and
> > build.gradle .
> >
> > - Neither is perfect,but > 50% of community parties agree gradle is a
> step
> > forward.
> >
> > jay +.1 (im netural with a slight lean to gradle)
> > cos, roman, sean, +3 (all are ready to move forward)
> > mark effectively might say is a -1
> >
> > ************* - But we don't want to leave anyone behind!
> > **********************
> >
> > But we also need to move fast ! We dont want a schizophrenic or forked
> > community.
> >
> > SO HERE IS MY SUGGESTION:
> >
> > 1) we schedule a meetup, or a screencast - specifically to go through the
> > gradle code - from A to Z -
> > 2) We validate and build all of bigtop, using gradle, during the
> > screencast. NO EXCEPTIONS. That way we are all 100% sure that it
> works,
> > and we see it in action.
> > 3) After that screen cast, we ensure that we have a unified community
> which
> > can self-sufficiently administer the gradle based build - as soon as
> > possible.
> > 4) If all parties to (1) agree that they are now ready , we delete the
> > Makefile forever, in a patch which updates the README file with excellent
> > explanation of how the build.gradle works.
> >
> > This is the most rapid way to move the entire community forward in unison
> > and prevent code rot of maintaining duplicate features .
> >
> > Mark, and others, how do you feel about this idea?
> >
> >
> >
> > On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <
> grover.markgrover@gmail.com>
> > wrote:
> >
> > > Thanks for starting this thread, Jay and Cos.
> > >
> > > Here are my thoughts:
> > > Gradle may actually be a better choice for Bigtop. However, in my
> > opinion,
> > > Make should be kept around for a little while to make the transition
> easy
> > > for the community.
> > >
> > > I would go as far as saying that we shouldn't be deprecating Make right
> > > now. In my opinion, it's best to have a transition period where we all
> > > support both Gradle and Make. During this time, contributors and
> > committers
> > > work (albeit, with a little extra pain) with both and develop their
> own
> > > opinion on which tool is the best for the project. Some of us may
> already
> > > have developed such experience by using various tools in the past while
> > > others may have not. The idea is to give all members of the community
> an
> > > opportunity to make such a decision for themselves and share them with
> > the
> > > community.
> > > And, consequently, the official decision to deprecate a tool from the
> > > project shouldn't happen before this transition period, but after.
> > >
> > > Hope that makes sense.
> > > Mark
> > >
> > >
> > >
> > > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > > wrote:
> > >
> > > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > > >
> > > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much
> > prefer
> > > > debugging a more modern language, and as Cos points out, it's
> intended
> > > for
> > > > a JVM ecosystem but can do other things when needed.
> > > > - I'd prefer we leave Make around for perhaps one more release just
> to
> > > > really solidify the Gradle system a bit more. However if we keep it
> > > > deprecated, I see no point in "maintaining" both, meaning that if
> > people
> > > > want to add new features to the build (several JIRAs going on for
> that
> > > > right now) - there's no need to keep adding that to the Makefile,
> let's
> > > > just keep the versions and metadata for new projects up to date. I
> > don't
> > > > believe we routinely run into bugs, so I doubt much work will have to
> > be
> > > > put in outside of bigtop.mk.
> > > >
> > > >
> > > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <
> > roman@shaposhnik.org
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <
> cos@apache.org>
> > > > > wrote:
> > > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > > starting
> > > > > > [DISCUSS]. Per Jay's:
> > > > > >
> > > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > > Makefile
> > > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > > deprecated.
> > > > > >
> > > > > > As per Mark's suggestion in that JIRA, the future of Makefile
> > should
> > > be
> > > > > > decided on the mailing list before the next JIRA comes out to
> > further
> > > > > > distance from Make and embrace gradle.
> > > > > >
> > > > > > Should we continue to support the Makefile builder?
> > > > >
> > > > > I'd be more than happy to get rid of it right after we release
> Bigtop
> > > > 0.8.0
> > > > >
> > > > > Thanks,
> > > > > Roman.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > jay vyas
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Sean Mackrory <ma...@gmail.com>.
I personally like that idea, and it would probably be beneficial even if it
wasn't the mechanism by which we made the decision, but the whole reason
we're having this discussion is because of concern raised about the
decision not being made on the mailing list. I know of one project where a
design document was posted for discussion, a call was scheduled on the
mailing list with international toll-free numbers and a recording, and
plenty of time for discussion after the call before a decision was made,
and this was still considered too closed of a decision. I suspect a hangout
might also violate the same criteria :)
Perhaps if someone very familiar with the gradle code were to post a
screencast of them walking through the code and demonstrating the build,
that would allow all decision making to be on the list and help to resolve
the concerns already discussed?
On Mon, Jul 14, 2014 at 9:06 AM, jay vyas <ja...@gmail.com>
wrote:
> I agree wiith mark that we need to make it easy and individuals in the
> community need to be comfortable with the transition. I propose a solution
> at the end o this email.
>
> Heres where we are at:
>
> - Realistically, the debate on which is "better" is not going to be very
> fruitful.... We all know the high-level pros and cons of both Makefile and
> build.gradle .
>
> - Neither is perfect,but > 50% of community parties agree gradle is a step
> forward.
>
> jay +.1 (im netural with a slight lean to gradle)
> cos, roman, sean, +3 (all are ready to move forward)
> mark effectively might say is a -1
>
> ************* - But we don't want to leave anyone behind!
> **********************
>
> But we also need to move fast ! We dont want a schizophrenic or forked
> community.
>
> SO HERE IS MY SUGGESTION:
>
> 1) we schedule a meetup, or a screencast - specifically to go through the
> gradle code - from A to Z -
> 2) We validate and build all of bigtop, using gradle, during the
> screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
> and we see it in action.
> 3) After that screen cast, we ensure that we have a unified community which
> can self-sufficiently administer the gradle based build - as soon as
> possible.
> 4) If all parties to (1) agree that they are now ready , we delete the
> Makefile forever, in a patch which updates the README file with excellent
> explanation of how the build.gradle works.
>
> This is the most rapid way to move the entire community forward in unison
> and prevent code rot of maintaining duplicate features .
>
> Mark, and others, how do you feel about this idea?
>
>
>
> On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
> wrote:
>
> > Thanks for starting this thread, Jay and Cos.
> >
> > Here are my thoughts:
> > Gradle may actually be a better choice for Bigtop. However, in my
> opinion,
> > Make should be kept around for a little while to make the transition easy
> > for the community.
> >
> > I would go as far as saying that we shouldn't be deprecating Make right
> > now. In my opinion, it's best to have a transition period where we all
> > support both Gradle and Make. During this time, contributors and
> committers
> > work (albeit, with a little extra pain) with both and develop their own
> > opinion on which tool is the best for the project. Some of us may already
> > have developed such experience by using various tools in the past while
> > others may have not. The idea is to give all members of the community an
> > opportunity to make such a decision for themselves and share them with
> the
> > community.
> > And, consequently, the official decision to deprecate a tool from the
> > project shouldn't happen before this transition period, but after.
> >
> > Hope that makes sense.
> > Mark
> >
> >
> >
> > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > wrote:
> >
> > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > >
> > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much
> prefer
> > > debugging a more modern language, and as Cos points out, it's intended
> > for
> > > a JVM ecosystem but can do other things when needed.
> > > - I'd prefer we leave Make around for perhaps one more release just to
> > > really solidify the Gradle system a bit more. However if we keep it
> > > deprecated, I see no point in "maintaining" both, meaning that if
> people
> > > want to add new features to the build (several JIRAs going on for that
> > > right now) - there's no need to keep adding that to the Makefile, let's
> > > just keep the versions and metadata for new projects up to date. I
> don't
> > > believe we routinely run into bugs, so I doubt much work will have to
> be
> > > put in outside of bigtop.mk.
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <
> roman@shaposhnik.org
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > wrote:
> > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > starting
> > > > > [DISCUSS]. Per Jay's:
> > > > >
> > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > Makefile
> > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > deprecated.
> > > > >
> > > > > As per Mark's suggestion in that JIRA, the future of Makefile
> should
> > be
> > > > > decided on the mailing list before the next JIRA comes out to
> further
> > > > > distance from Make and embrace gradle.
> > > > >
> > > > > Should we continue to support the Makefile builder?
> > > >
> > > > I'd be more than happy to get rid of it right after we release Bigtop
> > > 0.8.0
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> >
>
>
>
> --
> jay vyas
>
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Andre Arcilla <ar...@apache.org>.
Hi Jay,
It sounds great and very comprehensive. As an added bonus, if we capture
the screencast, we can post on Yourtube our own video instructions on how
to build Bigtop, which is helpful for new members.
On Mon, Jul 14, 2014 at 8:06 AM, jay vyas <ja...@gmail.com>
wrote:
> I agree wiith mark that we need to make it easy and individuals in the
> community need to be comfortable with the transition. I propose a solution
> at the end o this email.
>
> Heres where we are at:
>
> - Realistically, the debate on which is "better" is not going to be very
> fruitful.... We all know the high-level pros and cons of both Makefile and
> build.gradle .
>
> - Neither is perfect,but > 50% of community parties agree gradle is a step
> forward.
>
> jay +.1 (im netural with a slight lean to gradle)
> cos, roman, sean, +3 (all are ready to move forward)
> mark effectively might say is a -1
>
> ************* - But we don't want to leave anyone behind!
> **********************
>
> But we also need to move fast ! We dont want a schizophrenic or forked
> community.
>
> SO HERE IS MY SUGGESTION:
>
> 1) we schedule a meetup, or a screencast - specifically to go through the
> gradle code - from A to Z -
> 2) We validate and build all of bigtop, using gradle, during the
> screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
> and we see it in action.
> 3) After that screen cast, we ensure that we have a unified community which
> can self-sufficiently administer the gradle based build - as soon as
> possible.
> 4) If all parties to (1) agree that they are now ready , we delete the
> Makefile forever, in a patch which updates the README file with excellent
> explanation of how the build.gradle works.
>
> This is the most rapid way to move the entire community forward in unison
> and prevent code rot of maintaining duplicate features .
>
> Mark, and others, how do you feel about this idea?
>
>
>
> On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
> wrote:
>
> > Thanks for starting this thread, Jay and Cos.
> >
> > Here are my thoughts:
> > Gradle may actually be a better choice for Bigtop. However, in my
> opinion,
> > Make should be kept around for a little while to make the transition easy
> > for the community.
> >
> > I would go as far as saying that we shouldn't be deprecating Make right
> > now. In my opinion, it's best to have a transition period where we all
> > support both Gradle and Make. During this time, contributors and
> committers
> > work (albeit, with a little extra pain) with both and develop their own
> > opinion on which tool is the best for the project. Some of us may already
> > have developed such experience by using various tools in the past while
> > others may have not. The idea is to give all members of the community an
> > opportunity to make such a decision for themselves and share them with
> the
> > community.
> > And, consequently, the official decision to deprecate a tool from the
> > project shouldn't happen before this transition period, but after.
> >
> > Hope that makes sense.
> > Mark
> >
> >
> >
> > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > wrote:
> >
> > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > >
> > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much
> prefer
> > > debugging a more modern language, and as Cos points out, it's intended
> > for
> > > a JVM ecosystem but can do other things when needed.
> > > - I'd prefer we leave Make around for perhaps one more release just to
> > > really solidify the Gradle system a bit more. However if we keep it
> > > deprecated, I see no point in "maintaining" both, meaning that if
> people
> > > want to add new features to the build (several JIRAs going on for that
> > > right now) - there's no need to keep adding that to the Makefile, let's
> > > just keep the versions and metadata for new projects up to date. I
> don't
> > > believe we routinely run into bugs, so I doubt much work will have to
> be
> > > put in outside of bigtop.mk.
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <
> roman@shaposhnik.org
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > wrote:
> > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > starting
> > > > > [DISCUSS]. Per Jay's:
> > > > >
> > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > Makefile
> > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > deprecated.
> > > > >
> > > > > As per Mark's suggestion in that JIRA, the future of Makefile
> should
> > be
> > > > > decided on the mailing list before the next JIRA comes out to
> further
> > > > > distance from Make and embrace gradle.
> > > > >
> > > > > Should we continue to support the Makefile builder?
> > > >
> > > > I'd be more than happy to get rid of it right after we release Bigtop
> > > 0.8.0
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> >
>
>
>
> --
> jay vyas
>
Re: [VOTE]
Posted by Gordon Wang <gw...@pivotal.io>.
+1
On Fri, Aug 1, 2014 at 8:59 AM, Jay Vyas <ja...@gmail.com>
wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
>
--
Regards
Gordon Wang
Re: [VOTE]
Posted by Andrew Purtell <ap...@apache.org>.
+1
On Thu, Jul 31, 2014 at 5:59 PM, Jay Vyas <ja...@gmail.com>
wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [VOTE]
Posted by Mark Grover <ma...@apache.org>.
I am on vacation but sounds good!
On Mon, Aug 4, 2014 at 4:35 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Just to clarify: the composition of the 5 +1s is [3 binding; 2 non-binding]
>
> (assuming that mine and Anatoly's votes came too late and weren't counted.)
>
> Thanks everyone for your vote. I will open a ticket to follow through on
> this
> task.
>
> Cos
>
> On Mon, Aug 04, 2014 at 03:17PM, jay vyas wrote:
> > okay folks: The VOTE to retire the support of the make build system after
> > the 0.8.0 release, has now passed.
> >
> > 5 +1
> > 0 0
> > 0 -1
> >
> >
> >
> > On Mon, Aug 4, 2014 at 1:36 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> > wrote:
> >
> > > On Sat, Aug 2, 2014 at 10:38 AM, Sean Mackrory <ma...@gmail.com>
> > > wrote:
> > > > +1
> > > >
> > > > I was going to be funny and use the Make syntax for incrementing a
> > > variable
> > > > to cast my vote, but then I remembered why I was voting +1 in the
> first
> > > > place.
> > >
> > > Best! +1! Ever! ;-)
> > >
> > > And a belated +1 from me as well.
> > >
> > > Thanks,
> > > Roman.
> > >
> >
> >
> >
> > --
> > jay vyas
>
Re: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
Just to clarify: the composition of the 5 +1s is [3 binding; 2 non-binding]
(assuming that mine and Anatoly's votes came too late and weren't counted.)
Thanks everyone for your vote. I will open a ticket to follow through on this
task.
Cos
On Mon, Aug 04, 2014 at 03:17PM, jay vyas wrote:
> okay folks: The VOTE to retire the support of the make build system after
> the 0.8.0 release, has now passed.
>
> 5 +1
> 0 0
> 0 -1
>
>
>
> On Mon, Aug 4, 2014 at 1:36 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Sat, Aug 2, 2014 at 10:38 AM, Sean Mackrory <ma...@gmail.com>
> > wrote:
> > > +1
> > >
> > > I was going to be funny and use the Make syntax for incrementing a
> > variable
> > > to cast my vote, but then I remembered why I was voting +1 in the first
> > > place.
> >
> > Best! +1! Ever! ;-)
> >
> > And a belated +1 from me as well.
> >
> > Thanks,
> > Roman.
> >
>
>
>
> --
> jay vyas
Re: [VOTE]
Posted by jay vyas <ja...@gmail.com>.
okay folks: The VOTE to retire the support of the make build system after
the 0.8.0 release, has now passed.
5 +1
0 0
0 -1
On Mon, Aug 4, 2014 at 1:36 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Sat, Aug 2, 2014 at 10:38 AM, Sean Mackrory <ma...@gmail.com>
> wrote:
> > +1
> >
> > I was going to be funny and use the Make syntax for incrementing a
> variable
> > to cast my vote, but then I remembered why I was voting +1 in the first
> > place.
>
> Best! +1! Ever! ;-)
>
> And a belated +1 from me as well.
>
> Thanks,
> Roman.
>
--
jay vyas
Re: [VOTE]
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Aug 2, 2014 at 10:38 AM, Sean Mackrory <ma...@gmail.com> wrote:
> +1
>
> I was going to be funny and use the Make syntax for incrementing a variable
> to cast my vote, but then I remembered why I was voting +1 in the first
> place.
Best! +1! Ever! ;-)
And a belated +1 from me as well.
Thanks,
Roman.
Re: [VOTE]
Posted by Sean Mackrory <ma...@gmail.com>.
+1
I was going to be funny and use the Make syntax for incrementing a variable
to cast my vote, but then I remembered why I was voting +1 in the first
place.
On Jul 31, 2014 6:59 PM, "Jay Vyas" <ja...@gmail.com> wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
>
Re: [VOTE]
Posted by Julien Eid <ju...@cloudera.com>.
+1
On Thursday, July 31, 2014, Jay Vyas <ja...@gmail.com> wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
>
Re: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
A small procedural point: the vote will run for at least 72 hours and be
wrapped on Aug 3, 2014 at 21:00 PDT
On Thu, Jul 31, 2014 at 08:59PM, Jay Vyas wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
Re: [VOTE]
Posted by Anatoli Fomenko <af...@yahoo.com.INVALID>.
Sorry for the late response, been OOO.
+1 from me.
Anatoli
On Monday, August 4, 2014 12:12 PM, Konstantin Boudnik <co...@apache.org> wrote:
+1
Sorry for a very late reply - was out yesterday. Hopefully, the tally isn't
closed yet.
Cos
On Thu, Jul 31, 2014 at 08:59PM, Jay Vyas wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
Re: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
+1
Sorry for a very late reply - was out yesterday. Hopefully, the tally isn't
closed yet.
Cos
On Thu, Jul 31, 2014 at 08:59PM, Jay Vyas wrote:
> Hi bigtop....Time to vote on the great gradle vs makefile debate.
>
> Vote:
>
> +1 to remove makefile support after 0.8.0 release,
>
> -1 If you want to keep make file post 0.8.0.
>
>
[VOTE]
Posted by Jay Vyas <ja...@gmail.com>.
Hi bigtop....Time to vote on the great gradle vs makefile debate.
Vote:
+1 to remove makefile support after 0.8.0 release,
-1 If you want to keep make file post 0.8.0.
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
Indeed, seems like we are out of opinions ;)
Jay, do you mind re-starting the [VOTE]?
Thanks,
Cos
On Sun, Jul 27, 2014 at 01:53PM, Konstantin Boudnik wrote:
> I want to wrap up this thread as it slowed down quit a bit.
>
> Have everyone expressed their views, so we can restart the [VOTE] if needed?
> Cos
>
> On Mon, Jul 14, 2014 at 08:53PM, Konstantin Boudnik wrote:
> > Honestly, I think the proposed plan is an overkill. This is a no-brainer
> > transition from one build system into another. It's not like we are going to
> > throw away make system in the next 11 hours or so. It can stand around as long
> > as people here are comfortable with. We can keep it around for 0.9.0 timeframe
> > and just let people adjust (and perhaps fix some bugs if found). The first
> > step after 0.8.0 would be to switch our CI system to it, where we'd be able to
> > take advantage of concurrent abilities of the new system and all that.
> >
> > Just for the record: new build follows precisely the same interface as the old
> > one. Everything you need to do is run 'gradle' and see what tasks are there.
> > So, literally, there's nothing new to learn about how the build works.
> > You do 'gradle rpm' and got yourself a full stack built as RPM, etc.
> >
> > "Leaving anyone behind" is an over-dramatization, IMO :) But... if people
> > want to have a session around gradle - why not?!
> > Oh yeah - +1 on what Andrew said: other dysfunctional communities shouldn't
> > set a precedent here :)
> >
> > Hope it makes sense
> > Cos
> >
> > On Mon, Jul 14, 2014 at 11:06AM, jay vyas wrote:
> > > I agree wiith mark that we need to make it easy and individuals in the
> > > community need to be comfortable with the transition. I propose a solution
> > > at the end o this email.
> > >
> > > Heres where we are at:
> > >
> > > - Realistically, the debate on which is "better" is not going to be very
> > > fruitful.... We all know the high-level pros and cons of both Makefile and
> > > build.gradle .
> > >
> > > - Neither is perfect,but > 50% of community parties agree gradle is a step
> > > forward.
> > >
> > > jay +.1 (im netural with a slight lean to gradle)
> > > cos, roman, sean, +3 (all are ready to move forward)
> > > mark effectively might say is a -1
> > >
> > > ************* - But we don't want to leave anyone behind!
> > > **********************
> > >
> > > But we also need to move fast ! We dont want a schizophrenic or forked
> > > community.
> > >
> > > SO HERE IS MY SUGGESTION:
> > >
> > > 1) we schedule a meetup, or a screencast - specifically to go through the
> > > gradle code - from A to Z -
> > > 2) We validate and build all of bigtop, using gradle, during the
> > > screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
> > > and we see it in action.
> > > 3) After that screen cast, we ensure that we have a unified community which
> > > can self-sufficiently administer the gradle based build - as soon as
> > > possible.
> > > 4) If all parties to (1) agree that they are now ready , we delete the
> > > Makefile forever, in a patch which updates the README file with excellent
> > > explanation of how the build.gradle works.
> > >
> > > This is the most rapid way to move the entire community forward in unison
> > > and prevent code rot of maintaining duplicate features .
> > >
> > > Mark, and others, how do you feel about this idea?
> > >
> > >
> > >
> > > On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
> > > wrote:
> > >
> > > > Thanks for starting this thread, Jay and Cos.
> > > >
> > > > Here are my thoughts:
> > > > Gradle may actually be a better choice for Bigtop. However, in my opinion,
> > > > Make should be kept around for a little while to make the transition easy
> > > > for the community.
> > > >
> > > > I would go as far as saying that we shouldn't be deprecating Make right
> > > > now. In my opinion, it's best to have a transition period where we all
> > > > support both Gradle and Make. During this time, contributors and committers
> > > > work (albeit, with a little extra pain) with both and develop their own
> > > > opinion on which tool is the best for the project. Some of us may already
> > > > have developed such experience by using various tools in the past while
> > > > others may have not. The idea is to give all members of the community an
> > > > opportunity to make such a decision for themselves and share them with the
> > > > community.
> > > > And, consequently, the official decision to deprecate a tool from the
> > > > project shouldn't happen before this transition period, but after.
> > > >
> > > > Hope that makes sense.
> > > > Mark
> > > >
> > > >
> > > >
> > > > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > > > wrote:
> > > >
> > > > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > > > >
> > > > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
> > > > > debugging a more modern language, and as Cos points out, it's intended
> > > > for
> > > > > a JVM ecosystem but can do other things when needed.
> > > > > - I'd prefer we leave Make around for perhaps one more release just to
> > > > > really solidify the Gradle system a bit more. However if we keep it
> > > > > deprecated, I see no point in "maintaining" both, meaning that if people
> > > > > want to add new features to the build (several JIRAs going on for that
> > > > > right now) - there's no need to keep adding that to the Makefile, let's
> > > > > just keep the versions and metadata for new projects up to date. I don't
> > > > > believe we routinely run into bugs, so I doubt much work will have to be
> > > > > put in outside of bigtop.mk.
> > > > >
> > > > >
> > > > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <roman@shaposhnik.org
> > > > >
> > > > > wrote:
> > > > >
> > > > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > > > wrote:
> > > > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > > > starting
> > > > > > > [DISCUSS]. Per Jay's:
> > > > > > >
> > > > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > > > Makefile
> > > > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > > > deprecated.
> > > > > > >
> > > > > > > As per Mark's suggestion in that JIRA, the future of Makefile should
> > > > be
> > > > > > > decided on the mailing list before the next JIRA comes out to further
> > > > > > > distance from Make and embrace gradle.
> > > > > > >
> > > > > > > Should we continue to support the Makefile builder?
> > > > > >
> > > > > > I'd be more than happy to get rid of it right after we release Bigtop
> > > > > 0.8.0
> > > > > >
> > > > > > Thanks,
> > > > > > Roman.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > jay vyas
>
>
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
I want to wrap up this thread as it slowed down quit a bit.
Have everyone expressed their views, so we can restart the [VOTE] if needed?
Cos
On Mon, Jul 14, 2014 at 08:53PM, Konstantin Boudnik wrote:
> Honestly, I think the proposed plan is an overkill. This is a no-brainer
> transition from one build system into another. It's not like we are going to
> throw away make system in the next 11 hours or so. It can stand around as long
> as people here are comfortable with. We can keep it around for 0.9.0 timeframe
> and just let people adjust (and perhaps fix some bugs if found). The first
> step after 0.8.0 would be to switch our CI system to it, where we'd be able to
> take advantage of concurrent abilities of the new system and all that.
>
> Just for the record: new build follows precisely the same interface as the old
> one. Everything you need to do is run 'gradle' and see what tasks are there.
> So, literally, there's nothing new to learn about how the build works.
> You do 'gradle rpm' and got yourself a full stack built as RPM, etc.
>
> "Leaving anyone behind" is an over-dramatization, IMO :) But... if people
> want to have a session around gradle - why not?!
> Oh yeah - +1 on what Andrew said: other dysfunctional communities shouldn't
> set a precedent here :)
>
> Hope it makes sense
> Cos
>
> On Mon, Jul 14, 2014 at 11:06AM, jay vyas wrote:
> > I agree wiith mark that we need to make it easy and individuals in the
> > community need to be comfortable with the transition. I propose a solution
> > at the end o this email.
> >
> > Heres where we are at:
> >
> > - Realistically, the debate on which is "better" is not going to be very
> > fruitful.... We all know the high-level pros and cons of both Makefile and
> > build.gradle .
> >
> > - Neither is perfect,but > 50% of community parties agree gradle is a step
> > forward.
> >
> > jay +.1 (im netural with a slight lean to gradle)
> > cos, roman, sean, +3 (all are ready to move forward)
> > mark effectively might say is a -1
> >
> > ************* - But we don't want to leave anyone behind!
> > **********************
> >
> > But we also need to move fast ! We dont want a schizophrenic or forked
> > community.
> >
> > SO HERE IS MY SUGGESTION:
> >
> > 1) we schedule a meetup, or a screencast - specifically to go through the
> > gradle code - from A to Z -
> > 2) We validate and build all of bigtop, using gradle, during the
> > screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
> > and we see it in action.
> > 3) After that screen cast, we ensure that we have a unified community which
> > can self-sufficiently administer the gradle based build - as soon as
> > possible.
> > 4) If all parties to (1) agree that they are now ready , we delete the
> > Makefile forever, in a patch which updates the README file with excellent
> > explanation of how the build.gradle works.
> >
> > This is the most rapid way to move the entire community forward in unison
> > and prevent code rot of maintaining duplicate features .
> >
> > Mark, and others, how do you feel about this idea?
> >
> >
> >
> > On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
> > wrote:
> >
> > > Thanks for starting this thread, Jay and Cos.
> > >
> > > Here are my thoughts:
> > > Gradle may actually be a better choice for Bigtop. However, in my opinion,
> > > Make should be kept around for a little while to make the transition easy
> > > for the community.
> > >
> > > I would go as far as saying that we shouldn't be deprecating Make right
> > > now. In my opinion, it's best to have a transition period where we all
> > > support both Gradle and Make. During this time, contributors and committers
> > > work (albeit, with a little extra pain) with both and develop their own
> > > opinion on which tool is the best for the project. Some of us may already
> > > have developed such experience by using various tools in the past while
> > > others may have not. The idea is to give all members of the community an
> > > opportunity to make such a decision for themselves and share them with the
> > > community.
> > > And, consequently, the official decision to deprecate a tool from the
> > > project shouldn't happen before this transition period, but after.
> > >
> > > Hope that makes sense.
> > > Mark
> > >
> > >
> > >
> > > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > > wrote:
> > >
> > > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > > >
> > > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
> > > > debugging a more modern language, and as Cos points out, it's intended
> > > for
> > > > a JVM ecosystem but can do other things when needed.
> > > > - I'd prefer we leave Make around for perhaps one more release just to
> > > > really solidify the Gradle system a bit more. However if we keep it
> > > > deprecated, I see no point in "maintaining" both, meaning that if people
> > > > want to add new features to the build (several JIRAs going on for that
> > > > right now) - there's no need to keep adding that to the Makefile, let's
> > > > just keep the versions and metadata for new projects up to date. I don't
> > > > believe we routinely run into bugs, so I doubt much work will have to be
> > > > put in outside of bigtop.mk.
> > > >
> > > >
> > > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <roman@shaposhnik.org
> > > >
> > > > wrote:
> > > >
> > > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > > wrote:
> > > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > > starting
> > > > > > [DISCUSS]. Per Jay's:
> > > > > >
> > > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > > Makefile
> > > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > > deprecated.
> > > > > >
> > > > > > As per Mark's suggestion in that JIRA, the future of Makefile should
> > > be
> > > > > > decided on the mailing list before the next JIRA comes out to further
> > > > > > distance from Make and embrace gradle.
> > > > > >
> > > > > > Should we continue to support the Makefile builder?
> > > > >
> > > > > I'd be more than happy to get rid of it right after we release Bigtop
> > > > 0.8.0
> > > > >
> > > > > Thanks,
> > > > > Roman.
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > jay vyas
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Konstantin Boudnik <co...@apache.org>.
Honestly, I think the proposed plan is an overkill. This is a no-brainer
transition from one build system into another. It's not like we are going to
throw away make system in the next 11 hours or so. It can stand around as long
as people here are comfortable with. We can keep it around for 0.9.0 timeframe
and just let people adjust (and perhaps fix some bugs if found). The first
step after 0.8.0 would be to switch our CI system to it, where we'd be able to
take advantage of concurrent abilities of the new system and all that.
Just for the record: new build follows precisely the same interface as the old
one. Everything you need to do is run 'gradle' and see what tasks are there.
So, literally, there's nothing new to learn about how the build works.
You do 'gradle rpm' and got yourself a full stack built as RPM, etc.
"Leaving anyone behind" is an over-dramatization, IMO :) But... if people
want to have a session around gradle - why not?!
Oh yeah - +1 on what Andrew said: other dysfunctional communities shouldn't
set a precedent here :)
Hope it makes sense
Cos
On Mon, Jul 14, 2014 at 11:06AM, jay vyas wrote:
> I agree wiith mark that we need to make it easy and individuals in the
> community need to be comfortable with the transition. I propose a solution
> at the end o this email.
>
> Heres where we are at:
>
> - Realistically, the debate on which is "better" is not going to be very
> fruitful.... We all know the high-level pros and cons of both Makefile and
> build.gradle .
>
> - Neither is perfect,but > 50% of community parties agree gradle is a step
> forward.
>
> jay +.1 (im netural with a slight lean to gradle)
> cos, roman, sean, +3 (all are ready to move forward)
> mark effectively might say is a -1
>
> ************* - But we don't want to leave anyone behind!
> **********************
>
> But we also need to move fast ! We dont want a schizophrenic or forked
> community.
>
> SO HERE IS MY SUGGESTION:
>
> 1) we schedule a meetup, or a screencast - specifically to go through the
> gradle code - from A to Z -
> 2) We validate and build all of bigtop, using gradle, during the
> screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
> and we see it in action.
> 3) After that screen cast, we ensure that we have a unified community which
> can self-sufficiently administer the gradle based build - as soon as
> possible.
> 4) If all parties to (1) agree that they are now ready , we delete the
> Makefile forever, in a patch which updates the README file with excellent
> explanation of how the build.gradle works.
>
> This is the most rapid way to move the entire community forward in unison
> and prevent code rot of maintaining duplicate features .
>
> Mark, and others, how do you feel about this idea?
>
>
>
> On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
> wrote:
>
> > Thanks for starting this thread, Jay and Cos.
> >
> > Here are my thoughts:
> > Gradle may actually be a better choice for Bigtop. However, in my opinion,
> > Make should be kept around for a little while to make the transition easy
> > for the community.
> >
> > I would go as far as saying that we shouldn't be deprecating Make right
> > now. In my opinion, it's best to have a transition period where we all
> > support both Gradle and Make. During this time, contributors and committers
> > work (albeit, with a little extra pain) with both and develop their own
> > opinion on which tool is the best for the project. Some of us may already
> > have developed such experience by using various tools in the past while
> > others may have not. The idea is to give all members of the community an
> > opportunity to make such a decision for themselves and share them with the
> > community.
> > And, consequently, the official decision to deprecate a tool from the
> > project shouldn't happen before this transition period, but after.
> >
> > Hope that makes sense.
> > Mark
> >
> >
> >
> > On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> > wrote:
> >
> > > I'm not super familiar with Gradle yet, but here are my thoughts:
> > >
> > > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
> > > debugging a more modern language, and as Cos points out, it's intended
> > for
> > > a JVM ecosystem but can do other things when needed.
> > > - I'd prefer we leave Make around for perhaps one more release just to
> > > really solidify the Gradle system a bit more. However if we keep it
> > > deprecated, I see no point in "maintaining" both, meaning that if people
> > > want to add new features to the build (several JIRAs going on for that
> > > right now) - there's no need to keep adding that to the Makefile, let's
> > > just keep the versions and metadata for new projects up to date. I don't
> > > believe we routinely run into bugs, so I doubt much work will have to be
> > > put in outside of bigtop.mk.
> > >
> > >
> > > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <roman@shaposhnik.org
> > >
> > > wrote:
> > >
> > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > > wrote:
> > > > > I am temporarily putting the [VOTE] thread to halt and instead
> > starting
> > > > > [DISCUSS]. Per Jay's:
> > > > >
> > > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > > Makefile
> > > > > and build.gradle. And the fact that the Makefile approach is now
> > > > > deprecated.
> > > > >
> > > > > As per Mark's suggestion in that JIRA, the future of Makefile should
> > be
> > > > > decided on the mailing list before the next JIRA comes out to further
> > > > > distance from Make and embrace gradle.
> > > > >
> > > > > Should we continue to support the Makefile builder?
> > > >
> > > > I'd be more than happy to get rid of it right after we release Bigtop
> > > 0.8.0
> > > >
> > > > Thanks,
> > > > Roman.
> > > >
> > >
> >
>
>
>
> --
> jay vyas
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by jay vyas <ja...@gmail.com>.
I agree wiith mark that we need to make it easy and individuals in the
community need to be comfortable with the transition. I propose a solution
at the end o this email.
Heres where we are at:
- Realistically, the debate on which is "better" is not going to be very
fruitful.... We all know the high-level pros and cons of both Makefile and
build.gradle .
- Neither is perfect,but > 50% of community parties agree gradle is a step
forward.
jay +.1 (im netural with a slight lean to gradle)
cos, roman, sean, +3 (all are ready to move forward)
mark effectively might say is a -1
************* - But we don't want to leave anyone behind!
**********************
But we also need to move fast ! We dont want a schizophrenic or forked
community.
SO HERE IS MY SUGGESTION:
1) we schedule a meetup, or a screencast - specifically to go through the
gradle code - from A to Z -
2) We validate and build all of bigtop, using gradle, during the
screencast. NO EXCEPTIONS. That way we are all 100% sure that it works,
and we see it in action.
3) After that screen cast, we ensure that we have a unified community which
can self-sufficiently administer the gradle based build - as soon as
possible.
4) If all parties to (1) agree that they are now ready , we delete the
Makefile forever, in a patch which updates the README file with excellent
explanation of how the build.gradle works.
This is the most rapid way to move the entire community forward in unison
and prevent code rot of maintaining duplicate features .
Mark, and others, how do you feel about this idea?
On Sun, Jul 13, 2014 at 2:16 PM, Mark Grover <gr...@gmail.com>
wrote:
> Thanks for starting this thread, Jay and Cos.
>
> Here are my thoughts:
> Gradle may actually be a better choice for Bigtop. However, in my opinion,
> Make should be kept around for a little while to make the transition easy
> for the community.
>
> I would go as far as saying that we shouldn't be deprecating Make right
> now. In my opinion, it's best to have a transition period where we all
> support both Gradle and Make. During this time, contributors and committers
> work (albeit, with a little extra pain) with both and develop their own
> opinion on which tool is the best for the project. Some of us may already
> have developed such experience by using various tools in the past while
> others may have not. The idea is to give all members of the community an
> opportunity to make such a decision for themselves and share them with the
> community.
> And, consequently, the official decision to deprecate a tool from the
> project shouldn't happen before this transition period, but after.
>
> Hope that makes sense.
> Mark
>
>
>
> On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com>
> wrote:
>
> > I'm not super familiar with Gradle yet, but here are my thoughts:
> >
> > - It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
> > debugging a more modern language, and as Cos points out, it's intended
> for
> > a JVM ecosystem but can do other things when needed.
> > - I'd prefer we leave Make around for perhaps one more release just to
> > really solidify the Gradle system a bit more. However if we keep it
> > deprecated, I see no point in "maintaining" both, meaning that if people
> > want to add new features to the build (several JIRAs going on for that
> > right now) - there's no need to keep adding that to the Makefile, let's
> > just keep the versions and metadata for new projects up to date. I don't
> > believe we routinely run into bugs, so I doubt much work will have to be
> > put in outside of bigtop.mk.
> >
> >
> > On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <roman@shaposhnik.org
> >
> > wrote:
> >
> > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > > I am temporarily putting the [VOTE] thread to halt and instead
> starting
> > > > [DISCUSS]. Per Jay's:
> > > >
> > > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > > Makefile
> > > > and build.gradle. And the fact that the Makefile approach is now
> > > > deprecated.
> > > >
> > > > As per Mark's suggestion in that JIRA, the future of Makefile should
> be
> > > > decided on the mailing list before the next JIRA comes out to further
> > > > distance from Make and embrace gradle.
> > > >
> > > > Should we continue to support the Makefile builder?
> > >
> > > I'd be more than happy to get rid of it right after we release Bigtop
> > 0.8.0
> > >
> > > Thanks,
> > > Roman.
> > >
> >
>
--
jay vyas
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Mark Grover <gr...@gmail.com>.
Thanks for starting this thread, Jay and Cos.
Here are my thoughts:
Gradle may actually be a better choice for Bigtop. However, in my opinion,
Make should be kept around for a little while to make the transition easy
for the community.
I would go as far as saying that we shouldn't be deprecating Make right
now. In my opinion, it's best to have a transition period where we all
support both Gradle and Make. During this time, contributors and committers
work (albeit, with a little extra pain) with both and develop their own
opinion on which tool is the best for the project. Some of us may already
have developed such experience by using various tools in the past while
others may have not. The idea is to give all members of the community an
opportunity to make such a decision for themselves and share them with the
community.
And, consequently, the official decision to deprecate a tool from the
project shouldn't happen before this transition period, but after.
Hope that makes sense.
Mark
On Sat, Jul 12, 2014 at 6:34 AM, Sean Mackrory <ma...@gmail.com> wrote:
> I'm not super familiar with Gradle yet, but here are my thoughts:
>
> - It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
> debugging a more modern language, and as Cos points out, it's intended for
> a JVM ecosystem but can do other things when needed.
> - I'd prefer we leave Make around for perhaps one more release just to
> really solidify the Gradle system a bit more. However if we keep it
> deprecated, I see no point in "maintaining" both, meaning that if people
> want to add new features to the build (several JIRAs going on for that
> right now) - there's no need to keep adding that to the Makefile, let's
> just keep the versions and metadata for new projects up to date. I don't
> believe we routinely run into bugs, so I doubt much work will have to be
> put in outside of bigtop.mk.
>
>
> On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
> > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > I am temporarily putting the [VOTE] thread to halt and instead starting
> > > [DISCUSS]. Per Jay's:
> > >
> > > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> > Makefile
> > > and build.gradle. And the fact that the Makefile approach is now
> > > deprecated.
> > >
> > > As per Mark's suggestion in that JIRA, the future of Makefile should be
> > > decided on the mailing list before the next JIRA comes out to further
> > > distance from Make and embrace gradle.
> > >
> > > Should we continue to support the Makefile builder?
> >
> > I'd be more than happy to get rid of it right after we release Bigtop
> 0.8.0
> >
> > Thanks,
> > Roman.
> >
>
Re: [DISCUSS] Removing support for Makefile? Was: [VOTE]
Posted by Sean Mackrory <ma...@gmail.com>.
I'm not super familiar with Gradle yet, but here are my thoughts:
- It can't be any worse than make. I mean, $$($(1)-deb). I'd much prefer
debugging a more modern language, and as Cos points out, it's intended for
a JVM ecosystem but can do other things when needed.
- I'd prefer we leave Make around for perhaps one more release just to
really solidify the Gradle system a bit more. However if we keep it
deprecated, I see no point in "maintaining" both, meaning that if people
want to add new features to the build (several JIRAs going on for that
right now) - there's no need to keep adding that to the Makefile, let's
just keep the versions and metadata for new projects up to date. I don't
believe we routinely run into bugs, so I doubt much work will have to be
put in outside of bigtop.mk.
On Fri, Jul 11, 2014 at 11:54 PM, Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > I am temporarily putting the [VOTE] thread to halt and instead starting
> > [DISCUSS]. Per Jay's:
> >
> > BIGTOP-1314 highlights the fact that we now have 2 build systems:
> Makefile
> > and build.gradle. And the fact that the Makefile approach is now
> > deprecated.
> >
> > As per Mark's suggestion in that JIRA, the future of Makefile should be
> > decided on the mailing list before the next JIRA comes out to further
> > distance from Make and embrace gradle.
> >
> > Should we continue to support the Makefile builder?
>
> I'd be more than happy to get rid of it right after we release Bigtop 0.8.0
>
> Thanks,
> Roman.
>