I agree that it's premature to pick an option here. For the record, my bias would be towards option (a) because my experience is that it's much more productive to start with something that works and extend it, than try to build a combination of different ideas. Especially if the latter tends towards a design-by-committee, as it usually does!
But I'd like to see a serious investigation of the options -- feature set, maturity, maintainer availability, etc -- before making a decision. This will take some time, but this is a place where "measure twice, cut once" seems like the right approach. On Wed, Sep 12, 2018 at 3:36 PM Jonathan Haddad <j...@jonhaddad.com> wrote: > This voting process feels a bit rushed and frankly not well thought out. > In addition to Sylvain's valid points, which you (Sankalp) didn't address > at all, the discussion in the other threads seemed to be ongoing. The last > email you wrote on one of them was asking for additional feedback, that > indicates the discussion is still open. > > Out of principal I vote for none of the options (inaction). You're > deliberately trying to ram *something* through, and that's not how this is > supposed to work. > > For those of you unfamiliar with the process - please read > https://www.apache.org/foundation/voting.html. > > I'd like to ask those of you that are +1'ing, are you willing to contribute > or are you just voting we start an admin tool from scratch because you > think it'll somehow produce a perfect codebase? > > > > > > On Wed, Sep 12, 2018 at 12:50 PM sankalp kohli <kohlisank...@gmail.com> > wrote: > > > Hi Sylvain, > > I would appreciate if we can give feedback on the > > discussion threads and not wait for vote threads. I made it clear in the > > discussion thread that we will start a vote!! > > Thanks, > > Sankalp > > > > On Wed, Sep 12, 2018 at 12:47 PM Jeff Jirsa <jji...@gmail.com> wrote: > > > > > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <lebre...@gmail.com> > > > wrote: > > > > > > > That's probably a stupid question, and excuse me if it is, but what > > does > > > > those votes on the dev mailing list even mean? > > > > > > > > How do you count votes at the end? Just by counting all votes cast, > > > > irregardless of whomever cast it? Or are we intending to only count > PMC > > > > members, or maybe committers votes? > > > > > > > > > > I believe the intent is to try to see if there exists consensus. > > > Ultimately, PMC is going to matter more than random email addresses > from > > > people nobody recognizes. This should be in public, though, not > private, > > so > > > seeing what feedback is beyond the PMC is useful (primarily because it > > will > > > matter when it comes time to extend and maintain it - if people > strongly > > > prefer one or the other, then maintenance is going to be a problem). > > > > > > If there's 100 random non-contributor votes for one option and 20 pmc > > votes > > > for another options, I think the real answer will be "we don't have > > > consensus, and either we don't do it, or we do it the way the PMC > thinks > > is > > > best", for all of the reasons you describe in the paragraphs below. > > > > > > > > > > If the former, that is a bit weird to me because we simply don't know > > who > > > > votes. And I don't mean to be rude towards anyone, but 1) someone > could > > > > easily create 10 email addresses to vote 10 times (and sure, you > could > > > > invoke trust, and I'm not entirely against trust in general, but it's > > the > > > > internet...) and 2) this kind of decision will have non-trivial > > > > consequences for the project, particularly on those that maintain it, > > so > > > I > > > > admit I'm not entirely comfortable with "anyone's voice has the same > > > > weight". > > > > If the latter, then this makes more sense to me (why are we even > > > bothering > > > > voting PMC members in if it's not to handle these kinds of decisions, > > > which > > > > are very "project management" related), but we should be very clear > > about > > > > this from the get go (we could still use the dev list for > transparency > > > > sake, that I don't mind)? We should probably also have some deadline > to > > > the > > > > vote, one that isn't too short. > > > > > > > > > > Like releases, I think PMC votes count > > > > > > > > > > > > > > Anyway, fwiw, my opinion on this vote is not far from the one on the > > > golang > > > > driver acceptance vote (for which my remark above also apply btw): no > > yet > > > > 100% convinced adding more pieces and scope to the project is what > the > > > > project needs just right now, but not strongly opposed if people > really > > > > wants this (and this one makes more sense to me than the golang > driver > > > > actually). But if I'm to pick between a) and b), I'm leaning b). > > > > > > > > > > FWIW, two of the main reasons I'm in favor is as a way to lower barrier > > to > > > entry to both using the software AND contributing to the project, so I > > > think your points are valid (both on gocql thread and on this note > > above), > > > but I think that's also part of why we should be encouraging both. > > > > > > - Jeff > > > > > > > > -- > Jon Haddad > http://www.rustyrazorblade.com > twitter: rustyrazorblade > -- Jonathan Ellis co-founder, http://www.datastax.com @spyced
