The site is in svn for the main pages. https://svn.apache.org/repos/asf/cassandra/site/src/
And in git for the docs. https://github.com/apache/cassandra/tree/trunk/doc/source For suggested changes make a JIRA with proposed changes. -Jeremiah > On Jun 2, 2017, at 5:36 PM, 大平怜 <rei.oda...@gmail.com> wrote: > > Hi all, > > As for our CAPI Flash enablement code, we are now working on the > plugin approach. Once it is ready, we would like to propose changes > in some Web pages of http://cassandra.apache.org for better plugin > support. I don't find any official process to propose such changes, > but could anyone tell us who we should work with? > > > Thanks, > Rei Odaira > > 2017-05-19 16:56 GMT-05:00 大平怜 <rei.oda...@gmail.com>: >> Hi all, >> >> Everybody seems to agree with improving the plugin ecosystem (as well >> as not small amount of effort needed to do that), but about >> vendor-specific code integration, let me summarize the issues raised >> so far. >> >> 1) How to test it? What if my code breaks the vendor-specific build? >> 2) How to maintain it? Who is to maintain the code? >> 3) How does it affect the Cassandra release cycle? >> 4) How to remove it? It might be hard to remove once integrated, from >> both technical and markting perspective. >> >> I think #3 and #4 are rather general issues for any newly proposed >> changes, while #1 and #2 are the most problematic for niche :-) >> platform specific code. #1 is technically solvable, for example, as >> Jeff (thanks!) showed with the Jenkins slave at ASF and as we are >> trying to connect a ppc machine with a CAPI device to the CI. >> >> #2 must be socially solved, as a component/platform maintainer system >> should be introduced like some other Apache projects. Is there any >> chance to have such a system in Cassandra? >> >> >> Thanks, >> Rei Odaira >> >> 2017-05-18 12:36 GMT-05:00 Jeff Jirsa <jji...@gmail.com>: >>> >>> >>>> On Thu, May 18, 2017 at 10:28 AM, Jeff Jirsa <jji...@gmail.com> wrote: >>>> >>>> >>>> >>>> On Mon, May 15, 2017 at 5:25 PM, Jeremiah D Jordan >>>> <jeremiah.jor...@gmail.com> wrote: >>>>> >>>>> >>>>> >>>>> To me testable means that we can run the tests at the very least for >>>>> every release, but ideally they would be run more often than that. >>>>> Especially with the push to not release unless the test board is all >>>>> passing, we should not be releasing features that we don’t have a test >>>>> board >>>>> for. Ideally that means we have it in ASF CI. If there is someone that >>>>> can >>>>> commit to posting results of runs from an outside CI somewhere, then I >>>>> think >>>>> that could work as well, but that gets pretty cumbersome if we have to >>>>> check >>>>> 10 different CI dashboards at different locations before every release. >>>> >>>> >>>> >>>> It turns out there's a ppc64le jenkins slave @ asf, so I've setup >>>> https://builds.apache.org/view/A-D/view/Cassandra/job/cassandra-devbranch-ppc64le-testall/ >>>> for testing. >>>> >>>> Like our other devbranch-testall builds, it takes a repo+branch as >>>> parameters, and runs unit tests. While the unit tests aren't passing, this >>>> platform should now be considered testable. >>>> >>> >>> (Platform != device, though, the CAPI device obviously isn't there, so the >>> row cache implementation still doesn't have public testing) >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
