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