OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VOTE] Development Approach for Apache Cassandra Management process


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 <kohlisankalp@xxxxxxxxx>
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 <jjirsa@xxxxxxxxx> wrote:
>
> > On Wed, Sep 12, 2018 at 12:41 PM Sylvain Lebresne <lebresne@xxxxxxxxx>
> > 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