Marcus, It's a good rant! I brought up the whole download an archive and run it and partly because I figure there's problems like this since CloudStack has always been installed one way and one way only.
But I don't know the specifics. Do you have any examples you can share? That way we can show people why this should not be done. Will be a good lesson for us all. Also if you show some examples, other developers can help in locating similar problems so you don't have to do all the work alone? Thanks! --Alex > -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Thursday, February 14, 2013 8:38 AM > To: cloudstack-dev@incubator.apache.org > Subject: name change of cloud- to cloudstack- explosion > > I (and others) have been working through a ton of issues revolving > around this name change, and while I think it's a good move in > general, I wanted to bring up two points to consider for similar > changes in the future. I've been primarily working in the 4.1 branch. > > 1) This is showing me just how tied the code is to the installation. > Mostly on the agent side, but a bit on the server side as well. > Someone mentioned in the future being able to download an archive and > just run it wherever you extract it, I think there's going to be a bit > of work there in making paths compatible. It has also been mentioned > that we should make some globals such that we don't have paths > sprinkled all over the code, that's probably worthwhile as well. > > 2) I'm beginning to think that this sort of thing should be done in a > branch, thoroughly tested, and then merged in. I'm not sure what the > thinking was here as-is. If someone moves a file elsewhere, are they > thinking "this needs to be done, we'll just do it, see what breaks and > fix it later", or are they just unaware of item #1 above and have no > idea what code might be relying on that file being there in the right > place. I would hope that someone would at least do a grep through the > code or something. This is perhaps a subtle thing because changing > paths doesn't necessarily cause builds to break or some tests to fail. > > Sorry for the rant. I understand that we didn't have packages at all a > few weeks ago, so this should be a step up. Ideally, changing the way > something is packaged shouldn't require changes to the code, or at > worst minimal changes, but we're not there and I think it caught us > off guard. Perhaps I don't understand all of the subtleties, but the > lesson I take from this is that we should have first made packaging > work as it did before, instead of introducing sweeping changes at the > same time.
