The Apache Software Foundation is *not* a democracy, it is a meritocracy. This
means that only those appointed to the ASF board/PMC, actually have any right
to vote or have a say in anything. People are added to the PMC/Board based on
their perceived knowledge/merit/performance. Mr. Mattmann is just a
representative of the governing body.
On 8/15/16, 2:37 PM, "San Luoji" <sanlu...@gmail.com> wrote:
> That’s not optional. If you are an ASF project, mailing lists are the
source of truth. Period.
Since when dictatorship becomes part of the culture in Apache Cassandra
community?
dic·ta·tor·ship
dikˈtādərˌSHip,ˈdiktādərˌSHip/
*noun*
1. government by a dictator.
"forty years of dictatorship"
synonyms: absolute rule, undemocratic rule, despotism
<https://www.google.ca/search?q=define+despotism&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIHzAA>
, tyranny
<https://www.google.ca/search?q=define+tyranny&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIIDAA>
, autocracy
<https://www.google.ca/search?q=define+autocracy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIITAA>
, autarchy
<https://www.google.ca/search?q=define+autarchy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIIjAA>
,authoritarianism, totalitarianism, fascism
<https://www.google.ca/search?q=define+fascism&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIIzAA>
; More
<https://www.google.ca/search?q=define+oppression&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIJTAA>
<https://www.google.ca/search?q=define+repression&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIJjAA>
<https://www.google.ca/search?q=define+democracy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIJzAA>
- a country governed by a dictator.
plural noun: *dictatorships*
synonyms: absolute rule, undemocratic rule, despotism
<https://www.google.ca/search?q=define+despotism&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIKTAA>
, tyranny
<https://www.google.ca/search?q=define+tyranny&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIKjAA>
, autocracy
<https://www.google.ca/search?q=define+autocracy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIKzAA>
, autarchy
<https://www.google.ca/search?q=define+autarchy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoILDAA>
,authoritarianism, totalitarianism, fascism
<https://www.google.ca/search?q=define+fascism&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoILTAA>
; More
<https://www.google.ca/search?q=define+oppression&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoILzAA>
<https://www.google.ca/search?q=define+repression&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIMDAA>
<https://www.google.ca/search?q=define+democracy&sa=X&ved=0ahUKEwj1nJ33hsTOAhUL72MKHbv7DdAQ_SoIMTAA>
- absolute authority in any sphere.
On Mon, Aug 15, 2016 at 12:03 PM, Chris Mattmann <mattm...@apache.org>
wrote:
> I’m sorry but you are massively confused if you believe that the ASF
> mailing lists
> aren’t the source of truth. They are. That’s not optional. If you are an
> ASF project,
> mailing lists are the source of truth. Period.
>
> On 8/15/16, 11:01 AM, "Michael Kjellman" <mkjell...@internalcircle.com>
> wrote:
>
> I'm a big fan of mailing lists, but google makes issues very findable
> for new people to the project as JIRA gets indexed. They won't be able to
> find the same thing on an email they didn't get -- because they weren't in
> the project in the first place.
>
> Mailing lists are good for broad discussion or bringing specific
> issues to the attention of the broader community. It should never be the
> source of truth.
>
> best,
> kjellman
>
> Sent from my iPhone
>
> On Aug 15, 2016, at 2:57 PM, Chris Mattmann <mattm...@apache.org
> <mailto:mattm...@apache.org>> wrote:
>
> Realize it’s not just about committers and PMC members that are
> *already*
> on the PMC or that are developing the project. It’s about how to
> engage the
> *entire* community including those that are not yet on the committer
or
> PMC roster. That is the future (and current) lifeblood of the project.
> The mailing
> list aren’t just an unfortunate necessity of being an Apache project.
> They *are*
> the lifeblood of the Apache project.
>
>
>
> On 8/15/16, 10:44 AM, "Brandon Williams" <dri...@gmail.com<mailto:
> dri...@gmail.com>> wrote:
>
> I too, use this method quite a bit, almost every single day.
>
> On Mon, Aug 15, 2016 at 12:43 PM, Yuki Morishita <
> mor.y...@gmail.com<mailto:mor.y...@gmail.com>> wrote:
>
> As an active committer, the most important thing for me is to be able
> to *look up* design discussion and decision easily later.
>
> I often look up the git history or CHANGES.txt for changes that I'm
> interested in, then look up JIRA by following JIRA ticket number
> written to the comment or text.
> If we move to dev mailing list, I would request to post permalink to
> that thread posted to JIRA, which I think is just one extra step that
> isn't necessary if we simply use JIRA.
>
> So, I'm +1 to just post JIRA link to dev list.
>
>
> On Mon, Aug 15, 2016 at 12:35 PM, Chris Mattmann <mattm...@apache.org
> <mailto:mattm...@apache.org>>
> wrote:
> This is a good outward flow of info to the dev list. However, there
> needs to be
> inward flow too – having the convo on the dev list will be a good
start
> to that.
> I hope to see more inclusivity here.
>
>
>
> On 8/15/16, 10:26 AM, "Aleksey Yeschenko" <alek...@apache.org<mailto:
> alek...@apache.org>> wrote:
>
> Well, if you read carefully what Jeremiah and I have just proposed,
> it wouldn’t be an issue.
>
> The notable major changes would start off on dev@ (think, a
> summary, a link to the JIRA, and maybe an attached spec doc).
>
> No need to follow the JIRA feed. Watch dev@ for those announcements
> and start watching the invidual JIRA tickets if interested.
>
> This creates the least amount of noise: you miss nothing important,
> and at the same time you won’t be receiving mail from
> dev@ for each individual comment - including those on proposals you
> don’t care about.
>
> We aren’t doing it currently, but we could, and probably should.
>
> --
> AY
>
> On 15 August 2016 at 18:22:36, Chris Mattmann (mattm...@apache.org
> <mailto:mattm...@apache.org>)
> wrote:
>
> Discussion belongs on the dev list. Putting discussion in JIRA, is
> fine, but realize,
> there is a lot of noise in that signal and people may or may not be
> watching
> the JIRA list. In fact, I don’t see JIRA sent to the dev list at
all
> so you are basically
> forking the conversation to a high noise list by putting it all in
> JIRA.
>
>
>
>
>
> On 8/15/16, 10:11 AM, "Aleksey Yeschenko" <alek...@apache.org
> <mailto:alek...@apache.org>>
> wrote:
>
> I too feel like it would be sufficient to announce those major
JIRAs
> on the dev@ list, but keep all discussion itself to JIRA, where it
> belongs.
>
> You don’t need to follow every ticket this way, just subscribe to
> dev@ and then start watching the select major JIRAs you care about.
>
> --
> AY
>
> On 15 August 2016 at 18:08:20, Jeremiah D Jordan (
> jeremiah.jor...@gmail.com<mailto:jeremiah.jor...@gmail.com>) wrote:
>
> I like keeping things in JIRA because then everything is in one
> place, and it is easy to refer someone to it in the future.
> But I agree that JIRA tickets with a bunch of design discussion and
> POC’s and such in them can get pretty long and convoluted.
>
> I don’t really like the idea of moving all of that discussion to
> email which makes it has harder to point someone to it. Maybe a better
> idea
> would be to have a “design/POC” JIRA and an “implementation” JIRA.
> That way
> we could still keep things in JIRA, but the final decision would be
> kept
> “clean”.
>
> Though it would be nice if people would send an email to the dev
> list when proposing “design” JIRA’s, as not everyone has time to
follow
> every JIRA ever made to see that a new design JIRA was created that
> they
> might be interested in participating on.
>
> My 2c.
>
> -Jeremiah
>
>
> On Aug 15, 2016, at 9:22 AM, Jonathan Ellis <jbel...@gmail.com<mailto:
> jbel...@gmail.com>>
> wrote:
>
> A long time ago, I was a proponent of keeping most development
> discussions
> on Jira, where tickets can be self contained and the threadless
> nature
> helps keep discussions from getting sidetracked.
>
> But Cassandra was a lot smaller then, and as we've grown it has
> become
> necessary to separate out the signal (discussions of new features
> and major
> changes) from the noise of routine bug reports.
>
> I propose that we take advantage of the dev list to perform that
> separation. Major new features and architectural improvements
> should be
> discussed first here, then when consensus on design is achieved,
> moved to
> Jira for implementation and review.
>
> I think this will also help with the problem when the initial idea
> proves
> to be unworkable and gets revised substantially later after much
> discussion. It can be difficult to figure out what the conclusion
> was, as
> review comments start to pile up afterwards. Having that
> discussion on the
> list, and summarizing on Jira, would mitigate this.
>
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder, http://www.datastax.com
> @spyced
>
>
>
>
>
>
>
>
>
>
> --
> Yuki Morishita
> t:yukim (http://twitter.com/yukim)
>
>
>
>
>
>
>
>
