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
