+1 for renaming the 'test' target to 'test-core', and adding a 'test'
target that depends on 'test-core' and 'test-contrib'. That's what
other projects tend to do.
Paul Elschot wrote:
When a contrib fails and is not fixed, that might be a good reason to
remove it from the distribution. With such a policy the present contribs would
also stay up to date, provided their tests are good enough.
Thinking about it a bit more, there is a process to add contribs, but there
is not really a process to remove them. The policy of removing a contrib
before a release when its unit tests fail could make a nice fit for that.
I think what you're arguing is that, unlike the core, contrib is not
guaranteed to be back-compatible (since removing a module is not a
back-compatible change). Otherwise this is no different than other bugs
and code changes. If a contrib package is failing tests or breaking the
build, then we should file an issue in Jira. One potential patch is to
remove the package (since incompatible changes are permitted in
contrib). That can be proposed, and if no one with a binding vote
objects, it can happen. We shouldn't release with unresolved issues,
whether they involve contrib or core. Does that sound reasonable?
Doug
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
