No, we haven’t decided a date. Jacques, which of the dates I mentioned below would work for you?
Julian On Aug 14, 2014, at 9:33 AM, andrew <[email protected]> wrote: > Hi, > > I’ve been hacking on Otiq for a few months and would love to attend a > hackathon. I can’t make the 9th or 10th. Have you decided on a date yet? > > Andrew > > On Aug 4, 2014, at 12:13 PM, Julian Hyde <[email protected]> wrote: > >> Let’s go for a date early in September. That will give us time to get 0.9.0 >> out, and will also enable some Hive developers to participate. >> >> I have an offsite on September 9th, but plenty of other days would work — >> say 2nd, 3rd, 4th, 10th, 11th. Do any of those work for you? >> >> Julian >> >> On Jul 30, 2014, at 10:22 PM, Jacques Nadeau <[email protected]> wrote: >> >>> Oops... sorry about the wrong list. What do you think about doing a >>> hackathon August 12th? If that won't work with your release goals, how >>> about on September 9th? >>> >>> >>> On Wed, Jul 30, 2014 at 3:27 PM, Julian Hyde <[email protected]> wrote: >>> >>>> (Replying to dev@apache, bcc [email protected]. I’m fairly sure >>>> Jacques intended to post to dev@apache.) >>>> >>>> Great ideas. They all help clarify what we are building and how we are >>>> building it. I am +1 on each. >>>> >>>> Regarding 4. Given that the first release will be 0.9.0-incubating, not >>>> 1.0, and I'd like to get an RC to a vote within 2 weeks, do you think that >>>> the hackathon will deliver what we need? If not, I'd be excited to do a >>>> hackathon shortly after 0.9.0, working towards 1.0 goals. >>>> >>>> Julian >>>> >>>> On Jul 26, 2014 9:11 PM, "Jacques Nadeau" <[email protected]> wrote: >>>> I started with a tl;dr but I decided to simplify. I have a few >>>> suggestions that I think would be good (and am willing to back them up with >>>> developer effort). >>>> >>>> 1. Let's come up with an agreed set of processes around feature design >>>> docs, commits and changes to interfaces. Trying to maintain a large >>>> codebase against another codebase that is constantly in flux makes things >>>> very difficult. >>>> >>>> 2. Let's separate the optimizer from execution entirely and remove all >>>> code generation from the optimizer module. With modularization, teams that >>>> use only subcomponents (like the Drill team) will be able to better provide >>>> test cases as they can build test cases against the interfaces they are >>>> using as opposed to much higher (unknown) levels. >>>> >>>> 3. Let's commit to test cases for all feature patches and bug fixes. If >>>> something is a shared feature, let's maintain a separate feature branch >>>> until the feature is complete and test cases are provided and then pick the >>>> right version to merge. >>>> >>>> 4. Let's do a hackathon focused on getting our first Apache release out. >>>> I'll get it set up if people are in support of it. >>>> >>>> As I said, I'm willing to put mine and my team's effort against these >>>> goals if others are on board. >>>> >>>> thanks, >>>> Jacques >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "optiq-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >> >
