On 27/03/13 15:26, Sean Mackrory wrote: > Overall I think I like this - thanks for doing all the work for this fork! > It would indeed be nice to have a more sophisticated language for this. > Some thoughts: > > - If we do make a move to Python, we ought to make sure it works on > Python 2.4 initially, as we're still doing releases that we intend to > support on RHEL 5. I haven't tried the fork on RHEL 5 yet, so I'm just > mentioning it - don't know if there actually are any small issues. > > Yeah i could try and and test against this tomorrow there are a few things i'd have to look out for since i think i used with in there etc which is python >= 2.5 but its not nessecary etc.
> - do-component-build and install_.sh: I think those should remain as > bash scripts. Did you have any intention to the contrary? > Yeah this is true we should deffo keep this this is a nice way to have the builds be the same on both deb/rpm. > > - Some of the do-component-build scripts source 'bigtop.bom' to get > component versions in the environment. We need to make sure we still > generate that in a shell-friendly form. > Ah this is an interesting problem but if we were to output environment variables for the child-processes of subprocess.call this might work. Other outputting an bash friendly bom like before. There is definitely a way to work around this. Though i am not sure what way yet :P. > > - Don't know how I feel about "demoting" the tests. I've been under the > impression that they were still maintained (though I admit I haven't paid > much attention to them myself), but if they're not well maintained, I think > I'd rather we make a plan to give them more attention than accept their > unmaintained-ness. Yeah it might be my ignorance but I’ve never got that side of bigtop to work yet. And not sure how it works I think I put bigtop-deploy and test under contrib mostly because it undocumented and not really that important for the main functions of bigtop to package software. > > Definitely a big decision to make and there's a lot of discussion and work > to go - but put me down for a +1. > And i plan to make the code a lot nicer i did this in an afternoon and i know its probably not great yet but there is a lot of room for more interesting use of bigtop for long-term. Thanks for your +1. I think with some work i could try and bring it up to scratch with trunk bigtop and see how the community finds it i think its a necessary step in the long run even though the gcc hacker in my likes makefiles :). --Phil
