Thanks a lot, Jeremiah, Stefan, That is exactly what I was looking for.
Rei Odaira 2017-06-03 3:36 GMT-05:00 Stefan Podkowinski <s...@apache.org>: > I'd suggest to use the git docs for the new pages, so we can accept pull > requests for adding other plugins. [1] > > We can also link there from the main pages. Maybe the community page > would be a good place for that. > > [1] https://cassandra.apache.org/doc/latest/development/documentation.html > > On 06/03/2017 02:28 AM, J. D. Jordan wrote: >> 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 >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
