Re: A proposal to move away from Jira-centric development

[Dave Lester]

For all Apache projects, mailing lists are the source of truth. See: "If it 
didn't happen on a mailing list, it didn't happen." 
https://community.apache.org/newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects
 


In response to Jason’s question, here are two things I’ve seen work well in the 
Apache Mesos community:

1. I’d suggest setting up an iss...@cassandra.apache.org mailing list which 
posts all changes to JIRA tickets (comments, issue reassignments, status 
changes). This could be subscribed to like any other mailing list, and while 
this list would be high volume it increases transparency of what’s happening 
across the project.

For Apache Mesos, we have a issues@mesos list: 
https://lists.apache.org/list.html?iss...@mesos.apache.org 
 for this purpose. 
It can be hugely valuable for keeping tabs on what’s happening in the project. 
If there’s interest in creating this for Cassandra, here’s a link to the 
original INFRA ticket as a reference: 
https://issues.apache.org/jira/browse/INFRA-7971 


2. Apache Mesos has formalized process of design documents / feature 
development, to encourage community discussion prior to being committed — this 
discussion takes place on the mailing list and often has less to do with the 
merits of a particular patch as much as it does on an overall design, its 
relationship to dependencies, its usage, or larger issues about the direction 
of a feature. These discussions belong on the mailing list.

To keep these discussions / design documents connected to JIRA we attach links 
to JIRA issues. For example: 
https://cwiki.apache.org/confluence/display/MESOS/Design+docs+--+Shared+Links 
.
 The design doc approach is more of a formalization of what Jonathan originally 
proposed.

Dave

> On Aug 15, 2016, at 11:34 AM, Jason Brown  wrote:
> 
> Chris,
> 
> Can you give a few examples of other healthy Apache projects which you feel
> would be good example? Note: I'm not trying to bait the conversation, but
> am genuinely interested in what other successful projects do.
> 
> Thanks
> 
> Jason
> 
> On Monday, August 15, 2016, Chris Mattmann  wrote:
> 
>> s/dev list followers//
>> 
>> That’s (one of) the disconnect(s). It’s not *you the emboldened, powerful
>> PMC*
>> and then everyone else.
>> 
>> 
>> On 8/15/16, 11:25 AM, "Jeremy Hanna" > > wrote:
>> 
>>Regarding high level linking, if I’m in irc or slack or hipchat or a
>> mailing list thread, it’s easy to reference a Jira ID and chat programs can
>> link to it and bots can bring up various details.  I don’t think a hash id
>> for a mailing list is as simple or memorable.
>> 
>>A feature of a mailing list thread is that it can go in different
>> directions easily.  The burden is that it will be harder to follow in the
>> future if you’re trying to sort out implementation details.  So for high
>> level discussion, the mailing list is great.  When getting down to the
>> actual work and discussion about that focused work, that’s where a tool
>> like Jira comes in.  Then it is reference-able in the changes.txt and other
>> things.
>> 
>>I think the approach proposed by Jonathan is a nice way to keep dev
>> list followers informed but keeping ticket details focused.
>> 
>>> On Aug 15, 2016, at 1:12 PM, Chris Mattmann > > wrote:
>>> 
>>> How is it harder to point someone to mail?
>>> 
>>> Have you seen lists.apache.org?
>>> 
>>> Specifically:
>>> https://lists.apache.org/list.html?dev@cassandra.apache.org
>>> 
>>> 
>>> 
>>> On 8/15/16, 10:08 AM, "Jeremiah D Jordan" > > 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 > > 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

Re: A proposal to move away from Jira-centric development

[Dave Lester]

Interesting, thanks for pointing out this distinction.

Perhaps breaking out issues from the commits list would help make it easier for 
folks to subscribe in the future? At least within the Apache Mesos and Apache 
Aurora projects, we’ve seen more people subscribe to issues@ lists than 
commits@ lists.

FWIW, the Cassandra commits@ list does have a heathy following already — a 
subscriber number greater than those that contributed code to Apache Cassandra. 
For those with Apache ids, mailing list subscriber metrics are browsable using 
the Reporter tool: https://reporter.apache.org/ <https://reporter.apache.org/>

Dave

> On Aug 15, 2016, at 12:14 PM, Benedict Elliott Smith  
> wrote:
> 
> By this definition the Cassandra project is already compliant? There's a
> commits@ mailing list that behaves just as you describe.
> 
> I'd personally like to see some reform with how these things work, but
> mostly because commits@ is rarely going to be subscribed to by anybody who
> isn't working full time on the project, as it's painfully noisy. I would
> hate for dev@ to become similarly noisy though.
> 
> On Monday, 15 August 2016, Dave Lester  <mailto:dave_les...@apple.com>> wrote:
> 
>> For all Apache projects, mailing lists are the source of truth. See: "If
>> it didn't happen on a mailing list, it didn't happen."
>> https://community.apache.org/newbiefaq.html#is-there-a- 
>> <https://community.apache.org/newbiefaq.html#is-there-a->
>> code-of-conduct-for-apache-projects <https://community.apache.org/ 
>> <https://community.apache.org/>
>> newbiefaq.html#is-there-a-code-of-conduct-for-apache-projects>
>> 
>> In response to Jason’s question, here are two things I’ve seen work well
>> in the Apache Mesos community:
>> 
>> 1. I’d suggest setting up an iss...@cassandra.apache.org 
>> <mailto:iss...@cassandra.apache.org> 
>> mailing list which posts all changes to JIRA tickets (comments, issue
>> reassignments, status changes). This could be subscribed to like any other
>> mailing list, and while this list would be high volume it increases
>> transparency of what’s happening across the project.
>> 
>> For Apache Mesos, we have a issues@mesos list:
>> https://lists.apache.org/list.html?iss...@mesos.apache.org 
>> <https://lists.apache.org/list.html?iss...@mesos.apache.org> <
>> https://lists.apache.org/list.html?iss...@mesos.apache.org 
>> <https://lists.apache.org/list.html?iss...@mesos.apache.org>> for this
>> purpose. It can be hugely valuable for keeping tabs on what’s happening in
>> the project. If there’s interest in creating this for Cassandra, here’s a
>> link to the original INFRA ticket as a reference:
>> https://issues.apache.org/jira/browse/INFRA-7971 
>> <https://issues.apache.org/jira/browse/INFRA-7971> <
>> https://issues.apache.org/jira/browse/INFRA-7971 
>> <https://issues.apache.org/jira/browse/INFRA-7971>>
>> 
>> 2. Apache Mesos has formalized process of design documents / feature
>> development, to encourage community discussion prior to being committed —
>> this discussion takes place on the mailing list and often has less to do
>> with the merits of a particular patch as much as it does on an overall
>> design, its relationship to dependencies, its usage, or larger issues about
>> the direction of a feature. These discussions belong on the mailing list.
>> 
>> To keep these discussions / design documents connected to JIRA we attach
>> links to JIRA issues. For example: https://cwiki.apache.org/ 
>> <https://cwiki.apache.org/>
>> confluence/display/MESOS/Design+docs+--+Shared+Links <
>> https://cwiki.apache.org/confluence/display/MESOS/
>> Design+docs+--+Shared+Links>. The design doc approach is more of a
>> formalization of what Jonathan originally proposed.
>> 
>> Dave
>> 
>>> On Aug 15, 2016, at 11:34 AM, Jason Brown > > wrote:
>>> 
>>> Chris,
>>> 
>>> Can you give a few examples of other healthy Apache projects which you
>> feel
>>> would be good example? Note: I'm not trying to bait the conversation, but
>>> am genuinely interested in what other successful projects do.
>>> 
>>> Thanks
>>> 
>>> Jason
>>> 
>>> On Monday, August 15, 2016, Chris Mattmann > > wrote:
>>> 
>>>> s/dev list followers//
>>>> 
>>>> That’s (one of) the disconnect(s). It’s not *you the emboldened,
>> powerful
>>>> PMC*
>>>> and then everyone else.
>>>

Re: #cassandra-dev IRC logging

[Dave Lester]

+1. Check out ASFBot for logging IRC, along with other integrations.[1]

ASFBot can also be used for record keeping for IRC meetings (example [3]) which 
can automatically be sent to the appropriate apache mailing list. All other 
logs are archived online. [4] It’d easy enough to link to those archived logs 
via the website, etc.

[1] http://wilderness.apache.org/manual.html 

[3] http://wilderness.apache.org/#meetings 

[4] http://wilderness.apache.org/channels/#logs-#aurora 


> On Aug 26, 2016, at 11:17 AM, Jason Brown  wrote:
> 
> +1. How/where will this run? Is there any apache infra that we can make use
> of?
> 
> On Fri, Aug 26, 2016 at 10:48 AM, Jake Luciani  wrote:
> 
>> +1 so long as it filters out the join/leave stuff :)
>> 
>> On Fri, Aug 26, 2016 at 1:42 PM, Jeff Jirsa 
>> wrote:
>> 
>>> There exists a #cassandra-dev IRC channel that’s historically been used
>> by
>>> developers discussing the project – while it’s public, it’s not archived,
>>> and it’s not a mailing list. The ASF encourages all discussion to be
>>> archived, and ideally, archived on a public mailing list.
>>> 
>>> 
>>> 
>>> Jake suggested, and I want to propose on the list, that we copy a log of
>>> that channel (minus join/part activity) to dev@ either daily or weekly.
>>> We’ll need to make sure we comply with Freenode’s IRC logging policy, but
>>> the project / developers receives the best of both worlds – fast, real
>> time
>>> chat but also public archives/visibility for people who aren’t online at
>> a
>>> given moment. The volume may be a bit higher than most of us have come
>>> expect from the list, but it brings the project closer to doing things in
>>> The Apache Way, and we can give it an easily-filtered subject for folks
>> who
>>> don’t want that noise.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> --
>> http://twitter.com/tjake
>> 

Re: #cassandra-dev IRC logging

[Dave Lester]

Thanks, Jake!

Earlier today I submitted a patch to the website to link to the IRC archives 
https://issues.apache.org/jira/browse/CASSANDRA-12602 
<https://issues.apache.org/jira/browse/CASSANDRA-12602>

> On Aug 30, 2016, at 11:11 PM, Jake Farrell  wrote:
> 
> ASFBot is now active and logging in #cassandra-dev to
> http://wilderness.apache.org/channels/#logs-#cassandra-dev
> 
> -Jake
> 
> On Tue, Aug 30, 2016 at 4:21 PM, Jake Farrell  wrote:
> 
>> just #cassandra-dev
>> 
>> On Tue, Aug 30, 2016 at 4:17 PM, Jeremiah D Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>> 
>>> Also just to make sure, this is logging for #cassandra-dev not #cassandra
>>> right?
>>> 
>>> -Jeremiah
>>> 
>>> On Aug 30, 2016, at 3:11 PM, Jeff Jirsa 
>>> wrote:
>>> 
>>> http://wilderness.apache.org/channels/
>>> 
>>> 
>>> On 8/30/16, 1:04 PM, "Jonathan Ellis"  wrote:
>>> 
>>> What is the process to access asfbot logs?
>>> 
>>> On Tue, Aug 30, 2016 at 3:03 PM, Jake Farrell 
>>> wrote:
>>> 
>>> If there are no objections then, I am going to enable ASFBot and logging
>>> in
>>> #cassandra on freenode
>>> 
>>> -Jake
>>> 
>>> On Fri, Aug 26, 2016 at 6:59 PM, Dave Brosius 
>>> wrote:
>>> 
>>> If you wish to unsubscribe, send an email to
>>> 
>>> mailto://dev-unsubscr...@cassandra.apache.org
>>> 
>>> 
>>> 
>>> On 08/26/2016 04:49 PM, Gvb Subrahmanyam wrote:
>>> 
>>> Please remove me from - dev@cassandra.apache.org
>>> 
>>> -Original Message-
>>> From: Jake Farrell [mailto:jfarr...@apache.org]
>>> Sent: Friday, August 26, 2016 4:36 PM
>>> To: dev@cassandra.apache.org
>>> Subject: Re: #cassandra-dev IRC logging
>>> 
>>> asfbot can log to wilderness for backup, but it does not send out
>>> 
>>> digests.
>>> 
>>> I've seen a couple of projects starting to test out and use
>>> 
>>> slack/hipchat
>>> 
>>> and then use sameroom to connect irc so conversations are not separated
>>> 
>>> and
>>> 
>>> people can use their favorite client of choice
>>> 
>>> -Jake
>>> 
>>> On Fri, Aug 26, 2016 at 4:20 PM, Edward Capriolo >> 
>>> 
>>> wrote:
>>> 
>>> Yes. I did. My bad.
>>> 
>>> 
>>> On Fri, Aug 26, 2016 at 4:07 PM, Jason Brown 
>>> wrote:
>>> 
>>> Ed, did you mean this to post this to the other active thread today,
>>> 
>>> the one about github pull requests? (just want to make sure I'm
>>> understanding correctly :) )
>>> 
>>> On Fri, Aug 26, 2016 at 12:28 PM, Edward Capriolo
>>> >> 
>>> wrote:
>>> 
>>> One thing to watch out for. The way apache-gossip is setup the
>>> 
>>> PR's get sent to the dev list. However the address is not part of
>>> the list so
>>> 
>>> the
>>> 
>>> 
>>> project owners get an email asking to approve/reject every PR and
>>> 
>>> 
>>> comment
>>> 
>>> 
>>> on the PR.
>>> 
>>> 
>>> This is ok because we have a small quite group but you probably do
>>> not
>>> 
>>> want
>>> 
>>> that with the number of SCM changes in the cassandra project.
>>> 
>>> On Fri, Aug 26, 2016 at 3:05 PM, Jeff Jirsa <
>>> 
>>> jeff.ji...@crowdstrike.com>
>>> 
>>> 
>>> wrote:
>>> 
>>> 
>>> +1 to both as well
>>> 
>>> 
>>> On 8/26/16, 11:59 AM, "Tyler Hobbs"  wrote:
>>> 
>>> +1 on doing this and using ASFBot in particular.
>>> 
>>> 
>>> On Fri, Aug 26, 2016 at 1:40 PM, Jason Brown
>>> 
>>> 
>>> wrote:
>>> 
>>> @Dave ASFBot looks like a winner. If others are on board with
>>> 
>>> 
>>> this,
>>> 
>>> 
>>> I
>>> 
>>> can
>>> 
>>> 
>>> work on getting it up and going.
>>> 
>>> 
>>> On Fri, Aug 26, 2016 at 11:27 AM, Dave Lester <
>>> 
>>> dave_les...@apple.com>
>>> 
>>> 
>>> wrote:
>>> 
>>> 
>>> +1. Check out ASFBot for loggin

Re: Cassandra ASF Jenkins Compute Resources

[Dave Lester]

Could you link to the INFRA ticket so folks could follow?

Thanks,
Dave

> On Sep 9, 2016, at 12:27 PM, Michael Shuler  wrote:
> 
> I have an ongoing INFRA ticket with the testing issues we've seen when
> utilizing the ASF's Jenkins infrastructure. Basically, the results are
> erratic, due to other project (and Cassandra) concurrent test runs. Our
> testing on CassCI is pretty stable, since we do not run any concurrent
> tests. Cassandra tests open network sockets and hammer servers pretty
> hard, so running alongside other jobs on the same server have resulted
> in random network errors and timeouts.
> 
> INFRA indicated that some other projects have dedicated test slaves, and
> that they could evaluate this, based on need and available resources.
> They have indicated in the latest comment that the Cassandra project
> could provide servers, and INFRA could set them up in Jenkins as
> dedicated project slaves.
> 
> Is anyone interested in helping provide some stable testing slaves that
> we can use in ASF's Jenkins? If so, I'd be happy to get extra details
> and facilitate the setup with INFRA. Thanks!
> 
> -- 
> Kind regards,
> Michael

Re: Proposal - 3.5.1

[Dave Lester]

How would cutting a 3.5.1 release possibly confuse users of the software? It 
would be easy to document the change and to send release notes.

Given the bug’s critical nature and that it's a minor fix, I’m +1 (non-binding) 
to a new release.

Dave

> On Sep 15, 2016, at 7:18 AM, Jeremiah D Jordan  
> wrote:
> 
> I’m with Jeff on this, 3.7 (bug fixes on 3.6) has already been released with 
> the fix.  Since the fix applies cleanly anyone is free to put it on top of 
> 3.5 on their own if they like, but I see no reason to put out a 3.5.1 right 
> now and confuse people further.
> 
> -Jeremiah
> 
> 
>> On Sep 15, 2016, at 9:07 AM, Jonathan Haddad  wrote:
>> 
>> As I follow up, I suppose I'm only advocating for a fix to the odd
>> releases.  Sadly, Tick Tock versioning is misleading.
>> 
>> If tick tock were to continue (and I'm very much against how it currently
>> works) the whole even-features odd-fixes thing needs to stop ASAP, all it
>> does it confuse people.
>> 
>> The follow up to 3.4 (3.5) should have been 3.4.1, following semver, so
>> people know it's bug fixes only to 3.4.
>> 
>> Jon
>> 
>> On Wed, Sep 14, 2016 at 10:37 PM Jonathan Haddad  wrote:
>> 
>>> In this particular case, I'd say adding a bug fix release for every
>>> version that's affected would be the right thing.  The issue is so easily
>>> reproducible and will likely result in massive data loss for anyone on 3.X
>>> WHERE X < 6 and uses the "date" type.
>>> 
>>> This is how easy it is to reproduce:
>>> 
>>> 1. Start Cassandra 3.5
>>> 2. create KEYSPACE test WITH replication = {'class': 'SimpleStrategy',
>>> 'replication_factor': 1};
>>> 3. use test;
>>> 4. create table fail (id int primary key, d date);
>>> 5. delete d from fail where id = 1;
>>> 6. Stop Cassandra
>>> 7. Start Cassandra
>>> 
>>> You will get this, and startup will fail:
>>> 
>>> ERROR 05:32:09 Exiting due to error while processing commit log during
>>> initialization.
>>> org.apache.cassandra.db.commitlog.CommitLogReplayer$CommitLogReplayException:
>>> Unexpected error deserializing mutation; saved to
>>> /var/folders/0l/g2p6cnyd5kx_1wkl83nd3y4rgn/T/mutation6313332720566971713dat.
>>> This may be caused by replaying a mutation against a table with the same
>>> name but incompatible schema.  Exception follows:
>>> org.apache.cassandra.serializers.MarshalException: Expected 4 byte long for
>>> date (0)
>>> 
>>> I mean.. come on.  It's an easy fix.  It cleanly merges against 3.5 (and
>>> probably the other releases) and requires very little investment from
>>> anyone.
>>> 
>>> 
>>> On Wed, Sep 14, 2016 at 9:40 PM Jeff Jirsa 
>>> wrote:
>>> 
 We did 3.1.1 and 3.2.1, so there’s SOME precedent for emergency fixes,
 but we certainly didn’t/won’t go back and cut new releases from every
 branch for every critical bug in future releases, so I think we need to
 draw the line somewhere. If it’s fixed in 3.7 and 3.0.x (x >= 6), it seems
 like you’ve got options (either stay on the tick and go up to 3.7, or bail
 down to 3.0.x)
 
 Perhaps, though, this highlights the fact that tick/tock may not be the
 best option long term. We’ve tried it for a year, perhaps we should instead
 discuss whether or not it should continue, or if there’s another process
 that gives us a better way to get useful patches into versions people are
 willing to run in production.
 
 
 
 On 9/14/16, 8:55 PM, "Jonathan Haddad"  wrote:
 
> Common sense is what prevents someone from upgrading to yet another
> completely unknown version with new features which have probably broken
> even more stuff that nobody is aware of.  The folks I'm helping right
> deployed 3.5 when they got started because
 https://urldefense.proofpoint.com/v2/url?u=http-3A__cassandra.apache.org&d=DQIBaQ&c=08AGY6txKsvMOP6lYkHQpPMRA1U6kqhAwGa8-0QCg3M&r=yfYEBHVkX6l0zImlOIBID0gmhluYPD5Jje-3CtaT3ow&m=MZ9nLcNNhQZkuXyH0NBbP1kSEE2M-SYgyVqZ88IJcXY&s=pLP3udocOcAG6k_sAb9p8tcAhtOhpFm6JB7owGhPQEs&e=
 suggests
> it's acceptable for production.  It turns out using 4 of the built in
> datatypes of the database result in the server being unable to restart
> without clearing out the commit logs and running a repair.  That screams
> critical to me.  You shouldn't even be able to install 3.5 without the
> patch I've supplied - that bug is a ticking time bomb for anyone that
> installs it.
> 
> On Wed, Sep 14, 2016 at 8:12 PM Michael Shuler 
> wrote:
> 
>> What's preventing the use of the 3.6 or 3.7 releases where this bug is
>> already fixed? This is also fixed in the 3.0.6/7/8 releases.
>> 
>> Michael
>> 
>> On 09/14/2016 08:30 PM, Jonathan Haddad wrote:
>>> Unfortunately CASSANDRA-11618 was fixed in 3.6 but was not back
 ported to
>>> 3.5 as well, and it makes Cassandra effectively unusable if someone
 is
>>> using any of the 4 types affected in any of their schema.
>>> 
>>

Re: Guidelines for test coverage

[Dave Lester]

A related question:

I noticed that dtest is not part of the Apache project: 
https://github.com/riptano/cassandra-dtest. Are there plans to contribute this 
to the ASF?

Dave

> On Sep 21, 2016, at 3:17 PM, Nate McCall  wrote:
> 
> We have these already written down in from both the reviewing and
> development perspective:
> http://cassandra.apache.org/doc/latest/development/how_to_review.html
> http://cassandra.apache.org/doc/latest/development/testing.html
> 
> My takeaway from recent in-person discussions the other week about this
> topic, is that it's really just a matter of making this less of a
> chore/sharing the burden of reviews when the whole dtest suite has to be
> run.
> 
> Thanks for bringing this up, though.
> 
> On Tue, Sep 20, 2016 at 6:42 AM, sankalp kohli 
> wrote:
> 
>> Hi,
>>I wanted to know if there are any guidelines for contributors to give
>> out unit and integration tests along with the patches. If not, we should
>> discuss and have them in place.
>> 
>> I know we are making good progress with test coverage but we should add
>> guidelines around adding unit and integration tests with every patch.
>> Thoughts on this?
>> 
>> Thanks,
>> Sankalp
>> 
> 
> 
> 
> -- 
> -
> Nate McCall
> Wellington, NZ
> @zznate
> 
> CTO
> Apache Cassandra Consulting
> http://www.thelastpickle.com

Re: Broader community involvement in 4.0 (WAS Re: Rough roadmap for 4.0)

[Dave Lester]

Hi Ben,

A few ideas to add to your suggestions [inline]:

On 2016-11-06 13:51 (-0800), Ben Slater  wrote: 
> Hi All,
> 
> I thought I would add a couple of observations and suggestions as someone
> who has both personally made my first contributions to the project in the
> last few months and someone in a leadership role in an organisation
> (Instaclustr) that is feeling it’s way through increasing our contributions
> as an organisation.
> 
> Firstly - an observation on contribution experience and what I think is
> likely to make people want to contribute again:
> 1) The worst thing that can happen is for your contribution to be
> completely ignored.
> 2) The second worst thing is for it to be rejected without a good
> explanation (that you can learn from) or with hostility.
> 3) Having it rejected with a good reason is not a bad thing (you learn)
> 4) Having it accepted is, of course, the best!
> 
> With this as a background I would suggest a couple of thing that help make
> sure (3) and (4) are always more common that (1) and (2) (good outcomes are
> probably more common than bad at the moment but we’ve experienced all four
> scenarios in the last few months):
> 1) I think some process of assigning a committer of a “sponsor” of a 
> change
> (which would probably mean committers volunteering) before it commences
> would be useful. You can kind of do this at the moment by creating a JIRA
> and asking for comment but I think the process is a bit unclear and a bit
> intimidating for people starting off and it would be nice to know who was
> your primary reviewer for a piece of work. (Or maybe this process does
> exist and I don’t know about.)

I've seen this approach before and it that can reduce ambiguity on the state of 
contributions; the Apache Mesos project has a shepherding system similar to 
this. I would shy away from the term "sponsor" since it could infer a 
non-voluntary relationship between contributors and volunteer committers.

>From the Mesos docs: "Find a shepherd to collaborate on your patch. A shepherd 
>is a Mesos committer that will work with you to give you feedback on your 
>proposed design, and to eventually commit your change into the Mesos source 
>tree." More info on how they approach this is in both their newbie guide: 
>http://mesos.apache.org/documentation/newbie-guide/, and submitting a patch 
>guide: http://mesos.apache.org/documentation/latest/submitting-a-patch/.

In practice, there are some limitations and risks to this model. For one, a 
shepherding process is not a substitute for the Apache Way, and it's critical 
that design decisions and reviews are still done in the open. Additionally, in 
projects where a single organization has disproportionate representation at the 
committer level it can create bottlenecks if features are a lower priority for 
those orgs (while not malicious, it may mean that certain patches are 
shepherded while others are ignored). It's possible to work within these 
limitations, especially in cases where the community is having healthy 
conversations about the direction and roadmap for the project (similar to the 
original thread).

If this is something the project would like to push forward, I'd suggest a 
committer vote to ensure there's sufficient buy-in.

> 2) I think the “how to contribute” docs could emphasise activities other
> than creating new features as a great place to start.It seems that review,
> testing and doco could all do with more hands (as on just about any
> project). So, encouraging this as a way to start on the project might help
> to get some more bandwidth in this area rather than people creating patches
> that the committers don’t have bandwidth to review. I would be happy to
> draft an update to the docs including some of this if people think it’s a
> good idea.

This would be great. If you make changes here and create a JIRA ticket 
associated with it, please add me to the ticket and I'll happily provide 
feedback.

Dave

> 
> Cheers
> Ben
> 
> On Sun, 6 Nov 2016 at 06:40 Michael Shuler  wrote:
> 
> > On 11/04/2016 06:43 PM, Jeff Beck wrote:
> > > I run the local Cassandra User Group and I would love to help get the
> > > community more involved.  I would propose holding a night to add patches
> > to
> > > Cassandra some will be simple things like making sure some asserts have
> > > proper messages with them etc, but some may be slightly larger. The goal
> > > being to just get people used to the process, to help make this a success
> > > it would be great if we could have support on getting the patches we
> > submit
> > > at least looked at briefly in 1 month. That timeframe allows us to talk
> > > about it at the next meetup and show people their contributions even
> > small
> > > ones are valued.
> >
> > This is a great idea and I have a suggestion that would benefit the
> > project as a whole, as well as help new people get used to the
> > development process:
> >
> >   Document the process.
> >

Re: [VOTE] Close client-...@cassandra.apache.org mailing list

[Dave Lester]

+1 (non-binding)

On 2016-11-07 12:52 (-0800), sankalp kohli  wrote: 
> +1
> 
> On Mon, Nov 7, 2016 at 10:19 AM, Brandon Williams  wrote:
> 
> > As the moderator of this list, +1.  It was more helpful in the thrift days
> > (where I built a client, and thus became the moderator) but is practically
> > useless in the cql world.
> >
> > On Sun, Nov 6, 2016 at 11:11 PM, Jeff Jirsa  wrote:
> >
> > > There exists a nearly unused mailing list, client-dev@cassandra.apache.
> > org
> > > [0].
> > >
> > > This is a summary of the email threads over the past 12 months on that
> > > list:
> > >
> > > 1) ApacheCon Seville CFP Close notice
> > > 2) Datastax .NET driver question
> > > 3) Datastax Java driver question
> > > 4) FOSDEM announce
> > > 5) ApacheCon NA CFP Open noticed
> > >
> > > In order to avoid confusion, and given the lack of relevant and
> > > appropriate traffic, I propose we close the client-dev@ list entirely.
> > > Any traffic appropriate for the client-dev@ list would likely be better
> > > served if it were directed at dev@, which is more active.
> > >
> > > This vote will remain open for 72 hours.
> > >
> > > 0: https://lists.apache.org/list.html?client-...@cassandra.apache.org
> > >
> > >
> > >
> >
> 

Status of dtest donation?

[Dave Lester]

I may have missed further email discussion or updates, but since the October 
3rd email accepting dtest to the project has there been any movement?

Nate, is this something you're driving?

Best,
Dave

Re: [VOTE] self-assignment of jira tickets

[Dave Lester]

Non-binding +1

On 2017-03-29 08:42 (-0700), Sankalp Kohli  wrote: 
> +1
> 
> > On Mar 29, 2017, at 07:50, Sylvain Lebresne  wrote:
> > 
> > +1
> > 
> > On Wed, Mar 29, 2017 at 4:42 PM, Benjamin Lerer  >> wrote:
> > 
> >> Non binding +1
> >> 
> >> On Wed, Mar 29, 2017 at 4:24 PM, Jonathan Haddad 
> >> wrote:
> >> 
> >>> Non binding +1
>  On Wed, Mar 29, 2017 at 7:22 AM Jeff Jirsa  wrote:
>  
>  +1
>  
>  --
>  Jeff Jirsa
>  
>  
> > On Mar 29, 2017, at 6:21 AM, Jason Brown 
> >> wrote:
> > 
> > Hey all,
> > 
> > Following up my thread from a week or two ago (
> > 
>  https://lists.apache.org/thread.html/0665f40c7213654e99817141972c00
> >>> 3a2131aba7a1c63d6765db75c5@%3Cdev.cassandra.apache.org%3E
>  ),
> > I'd like to propose a vote to change to allow any potential
> >> contributor
>  to
> > assign a jira to themselves without needing to be added to the
>  contributors
> > group first.
> > 
> > https://issues.apache.org/jira/browse/INFRA-11950 is an example of
> >> how
>  to
> > get this done with INFRA.
> > 
> > Vote will be open for 72 hours.
> > 
> > Thanks,
> > 
> > -Jason Brown
>  
> >>> 
> >> 
> 

Re: Way to unsubscribe from mailing lists

[Dave Lester]

If there's community consensus that this would help, mailing list footers can 
be added via an INFRA request. Here are some example requests from Hadoop and 
Spark:

https://issues.apache.org/jira/browse/INFRA-10725
https://issues.apache.org/jira/browse/INFRA-8051

Dave

On 2017-04-25 08:11 (-0700), Michael Shuler  wrote: 
> On 04/25/2017 09:56 AM, Eric Evans wrote:
> > On Tue, Apr 25, 2017 at 2:56 AM, Alain RODRIGUEZ  wrote:
> >> Should / could we have INFRA automatically unsubscribing people sending
> >> those messages? I believe this would be the best solution, as more people
> >> mentioned a year ago. I would like at least those messages to be filtered,
> >> even that is a bit more selfish as it would not end the subscription for
> >> the person sending the message, it would at least reduce the noise.
> > 
> > I'd be in favor of filtering them from the list, with an
> > auto-responder that explained *why* it wasn't delivered, and what they
> > need to do to unsubscribe (and maybe setting the reply-to to
> > {list}-unsubscribe@cassandra.a.o).
> > 
> > I'm fairly certain the list software doesn't come ready to do this
> > though; I imagine the response from INFRA will be something like
> > "patches welcome", so we should be ready to rollup our sleeves.
> 
> Many lists include a footer that have unsub info - does ezmlm support
> footer append? I wouldn't mind it, if it helps users, and it seems
> simpler than trying to filter random messages.
> 
> -- 
> Michael
> 
>