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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 < > > [email protected]> > > > 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 <[email protected] > > > > > > 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 < > > > [email protected] > > > > > > > > > > wrote: > > > > > > > > > > > On Fri, Jul 11, 2014 at 6:01 PM, Konstantin Boudnik < > > [email protected]> > > > > > > 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) >
