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

2016-11-12 Thread Josh McKenzie 
>
> I strongly feel that there should be a better way e.g. a summary field in
> JIRA which filters out the discussions, arguments, solutions etc.and just
> crisply summarizes the problem, solution under discussion and the current
> status.


I've personally found that attaching a design doc for moderate to large
efforts with a combination of use-case, problem statement, and current
design helps give that snapshot and keep people on the same page. Nothing
too burdensome, just a page or so to summarize the pages and pages of JIRA
conversations and where we ended up.

If someone wants to understand the path on how things got to their current
point, JIRA comments get you there.

On Sat, Nov 12, 2016 at 2:23 AM, Anuj Wadehra <
anujw_2...@yahoo.co.in.invalid> wrote:

> Thanks for the information Jeremy.
>
> My main concern is around making JIRAs easy to understand. I am not sure
> how community feels about it. But, I have personally observed that long
> discussion thread on JIRAs is not user friendly for someone trying to
> understand the ticket or may be trying to contribute to the discussion/fix
> . I strongly feel that there should be a better way e.g. a summary field in
> JIRA which filters out the discussions, arguments, solutions etc.and just
> crisply summarizes the problem, solution under discussion and the current
> status. Sometimes description of the defect is not sufficient.   For a new
> comer trying to understand a JIRA, this summary would be a good start to
> understand the problem upfront and then if you want to go into details, you
> can understand the long JIRA thread.
> Also, some JIRAs are in dead state and you don't get a clue what's the
> current status after so much discussion over the ticket? Some JIRAs are
> neither rejected nor validated, so even if its a bug, some people would be
> reluctant to pick JIRAs which have not been validated yet.
>
>
> ThanksAnuj
>
>
>
>
> On Friday, 11 November 2016 1:40 AM, Jeremy Hanna <
> jeremy.hanna1...@gmail.com> wrote:
>
>
>  Regarding low hanging fruit, on the How To Contribute page [1] we’ve
> tried to keep a list of lhf tickets [2] linked to help people get started.
> They are usually good starting points and don’t require much context.  I
> rarely see duplicates from lhf tickets.
>
> Regarding duplicates, in my experience those who resolve tickets as
> duplicates are generally pretty good.
>
> I think the safest bet to start is to look at How To Contribute page and
> the lhf labeled tickets.
>
> [1] https://wiki.apache.org/cassandra/HowToContribute <
> https://wiki.apache.org/cassandra/HowToContribute>
> [2] https://issues.apache.org/jira/secure/IssueNavigator.
> jspa?reset=true&jqlQuery=project+=+12310865+AND+labels+
> =+lhf+AND+status+!=+resolved  jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=
> project+=+12310865+AND+labels+=+lhf+AND+status+!=+resolved>
>
> > On Nov 10, 2016, at 12:06 PM, Anuj Wadehra 
> wrote:
> >
> >
> > Hi,
> >
> > We need to understand that time is precious for all of us. Even if a
> developer has intentions to contribute, he may take months to contribute
> his first patch or may be longer. Some common entry barriers are:
> > 1. Difficult to identify low hanging fruits. 30 JIRA comments on a
> ticket and a new comer is LOST, even though the exact fix may be much
> simpler.
> > 2. Dead JIRA discussions with no clue on the current status of the
> ticket.
> > 3. No response on new JIRAs raised. Response time  to validate/reject
> the problem is important. Should I pick? Is it really a bug? Maybe some
> expert can confirm it first and then I can pick it..
> > 4.Ping Pong JIRAs: Your read 10 comments of a ticket then see duplicates
> and related ones..then read 30 more comments and then so on till you land
> up on same JIRA which is not concluded yet.
> > Possible Solution for above 4 points:
> > A. Add a new JIRA field to crisply summarize what conclusive discussion
> has taken place till now ,what's the status of current JIRA,
> proposed/feasible solution etc.
> > B. Mark low hanging fruits regularly.
> > C. Validate/Reject newly reported JIRAs on priority. Using dev list to
> validate/reject the issue before logging the JIRA??
> > D. Make sure that duplicates are real proven duplicates.
> >
> > 5. Insufficient code comments.
> > Solution: Coding comments should be a mandatory part of code review
> checklist. It makes reviews faster and encourage people to understand the
> flow and fix things on their own.
> > 6. Insufficient Design documentation.
> > Solution:Detailed documentation for at least new features so that people
> are comfortable with the design. Reading English and understanding
> diagrams/flows is much simpler than just jumping into the code upfront.
> > 7. No/Little formal communication on active development and way forward.
> > Solution: What about a monthly summary of New/Hot/critical JIRAs and new
> feature development (with JIRA links so that topics of interest are
> acc

Re: [VOTE] Release Apache Cassandra 3.0.10 (Take 3)

2016-11-12 Thread Jake Luciani 
+1

On Nov 11, 2016 9:18 PM, "Jeff Jirsa"  wrote:

> +1
>
> --
> Jeff Jirsa
>
>
> > On Nov 11, 2016, at 5:36 PM, Michael Shuler 
> wrote:
> >
> > I propose the following artifacts for release as 3.0.10.
> >
> > sha1: d6a3ef4863142c3f9fc1def911f28341fc78f2e8
> > Git:
> > http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=
> shortlog;h=refs/tags/3.0.10-tentative
> > Artifacts:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1134/org/apache/cassandra/apache-cassandra/3.0.10/
> > Staging repository:
> > https://repository.apache.org/content/repositories/
> orgapachecassandra-1134/
> >
> > The Debian packages are available here: http://people.apache.org/~
> mshuler
> >
> > The vote will be open for 72 hours (longer if needed).
> >
> > [1]: (CHANGES.txt) https://goo.gl/4UxyAJ
> > [2]: (NEWS.txt) https://goo.gl/8tfmEU
> >
>

Re: [VOTE] Release Apache Cassandra 3.0.10 (Take 3)

2016-11-12 Thread Nate McCall 
+1

On Sat, Nov 12, 2016 at 2:36 PM, Michael Shuler  wrote:
> I propose the following artifacts for release as 3.0.10.
>
> sha1: d6a3ef4863142c3f9fc1def911f28341fc78f2e8
> Git:
> http://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/3.0.10-tentative
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1134/org/apache/cassandra/apache-cassandra/3.0.10/
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachecassandra-1134/
>
> The Debian packages are available here: http://people.apache.org/~mshuler
>
> The vote will be open for 72 hours (longer if needed).
>
> [1]: (CHANGES.txt) https://goo.gl/4UxyAJ
> [2]: (NEWS.txt) https://goo.gl/8tfmEU
>

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

2016-11-12 Thread Ben Slater 
For anyone that’s interested, I’ve submitted my doc changes for point 2
below (emphasising contributions other than new features) here:
https://issues.apache.org/jira/browse/CASSANDRA-12906

I haven’t added anything about the sponsor/shepherd idea as doesn’t seem to
be agreed at this point.

Cheers
Ben

On Mon, 7 Nov 2016 at 09:34 Nate McCall  wrote:

> Ben,
> Thank you for providing two thoughtful, concrete recommendations.
> There is some good feedback in general on this thread, but I'm calling
> Ben's response out because point #1 is important to discuss and point
> #2 is immediately actionable.
>
> > 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.)
>
> This is a good idea, but it assumes a single point triage and resource
> management that we don't really have right now.
>
> For the history of the project, we had triage in the form of sponsored
> resources flighting most of the new issues. This has made the rest of
> us complacent. It's probably the most immediate thing to fix and I
> don't know how to do that.
>
> Does anybody have any recommendations about ASF projects doing this
> effectively? Note that the folks from DS engineering are still heavily
> involved and I very much thank them for that, but diversifying is the
> only way to get us over our complacency.
>
> > 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.
>
> Also a good idea and much more accessible/easily fixable.
>
> We will gladly look at any doc updates for this, looping in the
> broader community once published (this last part being key - I'm
> afraid if we ask for help too early, we'll get tons of interest to
> which we cannot reply and then be in even worse shape).
>
> -Nate
>