I think it's good to have a general build/test process projects can share, so +1 to pulling it out. You should get help from others.
regarding incubation, it is a lot of work, especially for something that's more of an in-house tool than an artifact to release and redistribute. You can't just use apache labs or the build project's repo to work on this? if you do want to incubate, we may want to nominate the hadoop project as the monitoring PMC, rather than incubator@. -steve > On 16 Jun 2015, at 17:59, Allen Wittenauer <a...@altiscale.com> wrote: > > > 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.
