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. >>> >
