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
