[
https://issues.apache.org/jira/browse/CASSANDRA-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12875698#action_12875698
]
Eric Evans commented on CASSANDRA-1159:
---------------------------------------
bq. I don't think being able to easily build contrib/ is the line that puts it
on a par with core. It's already on a par in the sense that it's in-tree, so
people expect it to build, at a minimum. I do think that's a level we should
commit to. But it's still useful to distinguish that contrib/ means "stuff that
isn't really part of the core project."
Sorry, if I said "easily buildable" was the line that divided contrib/ and
core, I didn't mean to. What I tried to say is that, "officially supported code
that everyone ought to care about, and be notified of failures over", should be
the line that separates contrib/. Also, at the time that contrib was created, I
am certain that is what it meant, since I was the one that suggested we add it.
:)
{quote}
* demo code (bmt_example, client_only, word_count)
* utilities (circuit, py_stress)
* stuff that used to be part of core, but we didn't want to maintain (maven
- okay, maybe we should drop this one
* a pig loadfunc (unable to think of a good category here)
* stuff I'm going to delete since it's not going to build any time soon
(mutex)
{quote}
It sounds like you are arguing in favor of having _all_ code be considered an
official part of the core with the same general responsibility for maintenance.
In that case it does make sense to add it to Hudson.
It also implicitly raises the barrier to entry (but maybe that's a Good Thing).
> For contrib modules that use Java, have a consistent build mechanism
> --------------------------------------------------------------------
>
> Key: CASSANDRA-1159
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1159
> Project: Cassandra
> Issue Type: Improvement
> Components: Contrib
> Reporter: Jeremy Hanna
> Assignee: Jeremy Hanna
> Priority: Minor
> Fix For: 0.7
>
>
> Contrib modules have a habit of periodically not working for some reason. To
> some extent that's expected - they are optional contrib modules. However, I
> think it's reasonable to at least have some way to perform a periodic sanity
> check on them if we can.
> This improvement would make sure there is a consistent build mechanism -
> build.xml - for each of the contrib modules that use Java. That way, there
> could be a hudson build perhaps nightly or weekly, that could inform the devs
> if the contrib modules are not even compiling. It's not like it would be a
> huge priority to fix immediately, but they would at least be aware that
> changes in the code/config have broken a contrib module.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
