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.
Thanks,
Roman.
