On Thu, Nov 17, 2011 at 02:55PM, Roman Shaposhnik wrote: > On Wed, Nov 16, 2011 at 11:12 PM, Konstantin Boudnik <[email protected]> wrote: > >> ═ ═ 1. We are getting a reasonable traction with downstream > >> communities turning to > >> ═ ═ Bigtop for integration testing of their RCs. It would be nice to > >> have a formal policy > >> ═ ═ on how we can accommodate these requests. So far, I've been using a > >> fork of > >> ═ ═ Bigtop on Github to do ad-hoc builds and validation, but perhaps > >> we can have > >> ═ ═ long-lived branch for that, or may be there's a better option. Let > >> me know what > >> ═ ═ do you think. > > > > can we do a parametrized stack where we can set the versions of included > > components separately from BigTop's pom and read them at the runtime? ═I > > guess > > Gradle would solve this problem for us but for now we might have to go with > > some inlined Groovy hacks. > > Here's the problem we're trying to solve here: we are starting to get requests > for (at least!) validating RCs of the projects that constitute Bigtop > so that they > know there's no regression compared to what was there. Here's a practical > example -- ZK RC 3.3.4 has been posted. I would like to verify that replacing > a single component (ZK) in a Bigtop 0.2.0 stack will NOT lead to a regression. > Right now, I'm doing this in a rather ad-hoc manner pushing to my own GitHub > repo and building (and soon testing) over here: > http://bigtop01.cloudera.org:8080/view/RCs/? > > This works, but I'm not sure this is the best way to handle it.
As per our offline chat you explained to me that what I was proposing is pretty much implemented (except for the automation part) and in fact the branch above is serving exactly this purpose. As for the question where to host such a branch, I'd say let's have next to the development and release branches of BigTop and call self-explanatory. Say, wasteland or something to that effect. So, whoever need can check it out and experiment in any way. Cos
