Thanks for this Julien!
I took a look and here is what I think. I think the 'steady state' use case of this is going to be that bigtop trunk would support building a HBase package that was based off of a recent release of HBase (use case #1) but also building from an arbitrary branch of HBase from it's github repo (use case #2).
Now, today, if someone has use case #1, they don't have to make any changes, they clone the bigtop repo and issue a command to build a package. I want to be able to do something similar for use case #2, so for that, if the user is happy with the github branch that Bigtop currently builds against, then all the user has to do is issue a simple command.
So, what follows is we can't clobber the existing variables in bigtop.mk, right? I personally don't want users to switch between flags or change code to be able to build from a github branch instead of an hbase release. That kinds leaves us with just one option in my opinion, that's to introduce new commands like 'make hbase-github-rpm' in addition to the 'make hbase-rpm'. For that we will need a new set of properties that we would need to set for HBase.
Again, we can't clobber existing properties, we have to introduce a completely additive set of new properties, which we need to set for every component. That new additive set can reside in bigtop.mk, but could also reside in another .mk file like bigtop-github.com. I think I have a slight preference to the latter i.e. using bigtop-github.mk. What do you think?
Also, I think the patch is incomplete but i suppose that was intentional since you are just getting our thoughts