cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 大平怜 <rei.oda...@gmail.com>
Subject Re: Integrating vendor-specific code and developing plugins
Date Mon, 05 Jun 2017 21:37:22 GMT
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 <spod@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.odaira@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.odaira@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 <jjirsa@gmail.com>:
>>>>>
>>>>>
>>>>>> On Thu, May 18, 2017 at 10:28 AM, Jeff Jirsa <jjirsa@gmail.com>
wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, May 15, 2017 at 5:25 PM, Jeremiah D Jordan
>>>>>> <jeremiah.jordan@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-unsubscribe@cassandra.apache.org
>>> For additional commands, e-mail: dev-help@cassandra.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: dev-help@cassandra.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@cassandra.apache.org
For additional commands, e-mail: dev-help@cassandra.apache.org


Mime
View raw message