On Tue, Mar 15, 2016 at 4:04 AM, Mattmann, Chris A (3980) < [email protected]> wrote:
> Good comments about Hadoop and comparisons there. The thing is all > projects are different in some sense, so comments to me like “Project > X did it this way, so Y” may not mean that Kudu must do it that way. > Yeah, totally agree. Seems like we should aim for what's best for the dual goals of growing the community and enabling effective and efficient workflows. When I talk about design, I am not necessarily talking about design > docs, but talking about the regular conversation and though process > / roadmap indicating where things are going on. For me, that’s > missing in Kudu Gotcha. Thanks for the perspective. We could post a roadmap to the web site with links to major work items (JIRAs, etc). That could help with discoverability of ongoing dev efforts. The last Kudu roadmap I saw was proposed by JD on the list [1] but it's not published elsewhere AFAIK. Just hopefully we can help users take a published roadmap with a grain of salt... I've seen people in other projects get irritated because their favorite feature that was on the roadmap didn't get implemented on the proposed project schedule (well, this is software after all, and open-source software at that). as a casual reader of the dev list, my *main* entry point into ASF projects > (and really > as someone who’s been around the ASF since 2004, what I really > consider the life-blood of the project), I would have and do not > have a clue as to what is going on. >From my point of view, the high-level vision of "where we're going" as a software project is ideally embodied in a (living) roadmap, while the tactical plan of "how we're going to get there" is embodied in the design docs (and comments about them) and patches (with associated code review comments). On the tactical side, soliciting design feedback on the mailing list (as mentioned previously, like Dan [2] and Adar [3] have recently done) as well as reducing the number of tool mails to the list sounds like a boon to visibility and discoverability. OTOH, I don't think every minor patch needs a dev@ thread -- that's what reviews@ should be for. Mike [1] http://mail-archives.apache.org/mod_mbox/kudu-dev/201602.mbox/%3ccagptdncmbwwx8p+ygkzhfl2xcmktscu-rhlcqfsns1uvsbr...@mail.gmail.com%3E [2] http://mail-archives.apache.org/mod_mbox/kudu-dev/201603.mbox/%3CCALo2W-UQOPBMmTq2ceRzZFtBk6756wiZSrwtQNPAw%3D-EzDpiRA%40mail.gmail.com%3E [3] http://mail-archives.apache.org/mod_mbox/kudu-dev/201603.mbox/%3CCAMcOB6NBcaBnigpQPBD5NrZrieB4qjv1uG0T6QZy-VTL6Ad4eQ%40mail.gmail.com%3E
