I wonder if the recent influx has anything to do with GSoC. The student
application period begins in a few days. I don't see any Cassandra issues
on the GSoC ideas list, though.
On Sat, 18 Mar 2017 at 10:40 Anthony Grasso
wrote:
+1 to killing the wiki as well. If that is not possible, we should
+1 to killing the wiki as well. If that is not possible, we should at least
put a note on there saying it is deprecated and point people to the new
docs.
On 18 March 2017 at 08:09, Jonathan Haddad wrote:
> +1 to killing the wiki.
>
> On Fri, Mar 17, 2017 at 2:08 PM Blake Eggleston
> wrote:
>
>
https://issues.apache.org/jira/browse/CASSANDRA-7837 may be some interesting
context regarding what's been worked on to get rid of singletons and static
initialization.
> On Mar 17, 2017, at 4:47 PM, Jonathan Haddad wrote:
>
> I'd like to think that if someone refactors existing code, making i
I'd like to think that if someone refactors existing code, making it more
testable (with tests, of course) it should be acceptable on it's own
merit. In fact, in my opinion it sometimes makes more sense to do these
types of refactorings for the sole purpose of improving stability and
testability a
On Fri, Mar 17, 2017 at 2:31 PM, Jason Brown wrote:
> To François's point about code coverage for new code, I think this makes a
> lot of sense wrt large features (like the current work on 8457/12229/9754).
> It's much simpler to (mentally, at least) isolate those changed sections
> and it'll sho
+1 to killing the wiki.
On Fri, Mar 17, 2017 at 2:08 PM Blake Eggleston
wrote:
> With CASSANDRA-8700, docs were moved in tree, with the intention that they
> would replace the wiki. However, it looks like we’re still getting regular
> requests to edit the wiki. It seems like we should be directi
With CASSANDRA-8700, docs were moved in tree, with the intention that they
would replace the wiki. However, it looks like we’re still getting regular
requests to edit the wiki. It seems like we should be directing these folks to
the in tree docs and either disabling edits for the wiki, or just r
> > On 2017-03-17 12:33 (-0700), Stefan Podkowinski wrote:
> >
> >> As you can see there's a large part about using GitHub for editing on
> >> the page. I'd like to know what you think about that and if you'd agree
> >> to accept PRs for such purposes.
I don't want to bury the important point i
On 2017-03-17 13:06 (-0700), benjamin roth wrote:
> Isn't there a way to script that with just a few lines of python or
> whatever?
For docs, probably. Real patches are harder.
There's a minor problem that they're a bit spammy (all PRs create dev@ emails),
but I'd rather tolerate that nois
I don't see how that would be harder compared to merging a patch
attached to a jira ticket. If you'd want to merge my PR you'd just have
to do something like that:
curl -o docs.patch
https://github.com/apache/cassandra/compare/trunk...spodkowinski:docs_gettingstarted.patch
git am docs.patch
git re
Isn't there a way to script that with just a few lines of python or
whatever?
2017-03-17 21:03 GMT+01:00 Jeff Jirsa :
>
>
> On 2017-03-17 12:33 (-0700), Stefan Podkowinski wrote:
>
> > As you can see there's a large part about using GitHub for editing on
> > the page. I'd like to know what you t
On 2017-03-17 12:33 (-0700), Stefan Podkowinski wrote:
> As you can see there's a large part about using GitHub for editing on
> the page. I'd like to know what you think about that and if you'd agree
> to accept PRs for such purposes.
>
The challenge of github PRs isn't that we don't want t
There's recently been a discussion about the wiki and how we should
continue to work on the documentation in general. One of my suggestions
was to start giving users a clearer guideline how they are able to
contribute to our documentation, before having a technical discussion
around tools and wikis
I think you can refactor any project with little risk and increase test
coverage.
What is needed:
Rules. Discipline. Perseverance. Small iterations. Small iterations. Small
iterations.
- Refactor in the smallest possible unit
- Split large classes into smaller ones. Remove god classes by pul
To François's point about code coverage for new code, I think this makes a
lot of sense wrt large features (like the current work on 8457/12229/9754).
It's much simpler to (mentally, at least) isolate those changed sections
and it'll show up better in a code coverage report. With small patches,
tha
As someone who spent a lot of time looking at the singletons topic in the
past, Blake brings a great perspective here. Figuring out and communicating
how best to test with the system we have (and of course incrementally
making that system easier to work with/test) seems like an achievable goal.
On
On Fri, Mar 17, 2017 at 12:33 PM, Blake Eggleston
wrote:
> I think we’re getting a little ahead of ourselves talking about DI
> frameworks. Before that even becomes something worth talking about, we’d
> need to have made serious progress on un-spaghettifying Cassandra in the
> first place. It’s a
done
---
On 2017-03-17 06:02, Rahul S wrote:
Hi
I would like to contribute to the Cassandra wiki please. My username
is rahul3.
Thanks
Rahul
From Alia to Anushka, Arijit to Armaan, Papon to Pritam, Sonu to
Sukhwinder and Varun to Diljit - the biggest music and Bollywood stars
say Music k
I think we’re getting a little ahead of ourselves talking about DI frameworks.
Before that even becomes something worth talking about, we’d need to have made
serious progress on un-spaghettifying Cassandra in the first place. It’s an
extremely tall order. Adding a DI framework right now would be
On 2017-03-16 14:51 (-0700), Qingcun Zhou wrote:
>
> When we talk about code coverage for new code, should we encourage people
> to contribute unit test cases for existing code?
>
Unit tests for existing untested code seems like something we'd welcome and
encourage.
On Fri, Mar 17, 2017 at 9:46 AM, Edward Capriolo
wrote:
>
>
> On Fri, Mar 17, 2017 at 6:41 AM, Ryan Svihla wrote:
>
>> Different DI frameworks have different initialization costs, even inside
>> of
>> spring even depending on how you wire up dependencies (did it use autowire
>> with reflection,
On Fri, Mar 17, 2017 at 6:41 AM, Ryan Svihla wrote:
> Different DI frameworks have different initialization costs, even inside of
> spring even depending on how you wire up dependencies (did it use autowire
> with reflection, parse a giant XML of explicit dependencies, etc).
>
> To back this asse
Different DI frameworks have different initialization costs, even inside of
spring even depending on how you wire up dependencies (did it use autowire
with reflection, parse a giant XML of explicit dependencies, etc).
To back this assertion up for awhile in that community benching different
DI fra
Hi
I would like to contribute to the Cassandra wiki please. My username is
rahul3.
Thanks
Rahul
From Alia to Anushka, Arijit to Armaan, Papon to Pritam, Sonu to Sukhwinder and
Varun to Diljit - the biggest music and Bollywood stars say Music ko Mirchi ka
Salaam! Catch the Royal Stag Mirchi
24 matches
Mail list logo
