Since a couple of people have brought it up:
I think the release question is probably one of the big question marks.
Other than tar balls, how does something like this actually get used
downstream?
For test-patch, in particular, I have a few thoughts on this:
Short term:
* Projects that want to move RIGHT NOW would modify their Jenkins jobs
to checkout from the Yetus repo (preferably at a well known tag or branch) in
one directory and their project repo in another directory. Then it’s just a
matter of passing the correct flags to test-patch. This is pretty much how
I’ve been personally running test-patch for about 6 months now. Under Jenkins,
we’ve seen this work with NiFi (incubating) already.
* Create a stub version of test-patch that projects could check into
their repo, replacing the existing test-patch. This stub version would git
clone from either ASF or github and then execute test-patch accordingly on
demand. With the correct smarts, it could make sure it has a cached version to
prevent continual clones.
Longer term:
* I’ve been toying with the idea of (ab)using Java repos and packaging
as a transportation layer, either in addition or in combination with something
like a maven plugin. Something like this would clearly be better for offline
usage and/or to lower the network traffic.
It’s probably worth pointing out that plugins can get sucked in from
outside the Yetus dir structure, so project specific bits can remain in those
projects. This would mean that, e.g., if ambari decides they want to change
the dependency ordering such that ambari-metrics always gets built first,
that’s completely doable without the Yetus project getting involved. This is
particularly relevant for things like the Dockerfile where projects would
almost certainly want to dictate their build and test time dependencies.
