[Starlingx-discuss] Directory restructuring
The current directory structure leaves a lot to be desired. References to mwa and cgcs should be removed and the directory structure can be flattened a bit to reduce path lengths. I propose to ... 1) Rename the mwa-* subdirectories, making the directory name match the git name. e.g. mwa-sparta will be replaced by stx-integ. 2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with 'stx-utils' is not very attractive. I'm thinking something more like 'packages' or 'src'. Other options welcome. Can we agree this is a positive step? Is it the right time to undertake this change? Both changes in the same set of updates, or split them? It will require both a manifest change, and a number of updates to hard coded paths within various scripts. Grep is my friend, but I might need a little help identifying scripts not originating from Wind Rivers original code drop. I'm a little worried about out of tree or side branch copies of the manifests. Thought on how to handle this? Scott Little
On Thu, Jun 21, 2018 at 9:27 AM, Scott Little <scott.little@windriver.com> wrote:
The current directory structure leaves a lot to be desired. References to mwa and cgcs should be removed and the directory structure can be flattened a bit to reduce path lengths. I propose to ...
1) Rename the mwa-* subdirectories, making the directory name match the git name. e.g. mwa-sparta will be replaced by stx-integ.
++ I naming the directories after the repo makes the most sense, thats fine, that's what we are all used to and where the mwa-* names came from before the Great Pivot. repo gives us the flexibility to do what makes the most sense here.
2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with 'stx-utils' is not very attractive. I'm thinking something more like 'packages' or 'src'. Other options welcome.
++ I'm fine with a different name, not sure I have a better idea of what though.
Can we agree this is a positive step? Is it the right time to undertake this change? Both changes in the same set of updates, or split them?
Totally positive! My experiences say that this is the sort of thing that will be painful no matter when we do it, waiting for X usually means when X comes Y has appeared to wait on. I favor doing it as soon as we know what we want to do. I would split them into two sets of reviews though, I think that will make debugging a bit simpler with only one type of thing changing at a time.
It will require both a manifest change, and a number of updates to hard coded paths within various scripts. Grep is my friend, but I might need a little help identifying scripts not originating from Wind Rivers original code drop.
We'll be able to help there, I think most of those are concerned with things outside or next to the build tree, like the mirror creation.
I'm a little worried about out of tree or side branch copies of the manifests. Thought on how to handle this?
We can use Zulu/Gerrit's Depends-On capability to co-ordinate the merge of these reviews so we do not spend a significant amount of time with repos in a inconsistent state. Maybe make all of the (other) reviews depend on the manifest review, then we +W the manifest review last and Zulu will merge them all at roughly the same time. Right now there is only one manifest file in stx-manifest. The pain here will be all in-flight work affected, which is likely to be a lot of it. Ian has mentioned about 70 reviews queued up since R5 release, I suspect much of that would need to be rebased. This is the 'X' I mention above. If we hold the restructure to merge all of that first something else may come up in the mean time. I would like to hear from someone closer to those affected here about how to weigh this tradeoff. Thanks for kicking this off Scott dt -- Dean Troyer dtroyer@gmail.com
I have the two sets of updates nearly ready. 1) Rename the mwa-* subdirectories, making the directory name match the git name. e.g. mwa-sparta will be replaced by stx-integ. 2) Strip out the addons/wr-cgcs/layers/cgcs, replacing it with 'stx' After both change sets, common paths will look like ... e.g. $MY_REPO/stx/stc-integ $MY_REPO/stx/git/nova I think we are targeting July 5 to have the change sets out for review, and hopefully quick acceptance. With respect to the manifest files, I'm still working with stx-r0.xml. Is that ok, or would it be preferable to start a new one? The old would be unbuildable. I'm just wondering if it would help folks during the transition to still have access to the old manifest. Scott On 18-06-21 11:17 AM, Dean Troyer wrote:
On Thu, Jun 21, 2018 at 9:27 AM, Scott Little <scott.little@windriver.com> wrote:
The current directory structure leaves a lot to be desired. References to mwa and cgcs should be removed and the directory structure can be flattened a bit to reduce path lengths. I propose to ...
1) Rename the mwa-* subdirectories, making the directory name match the git name. e.g. mwa-sparta will be replaced by stx-integ. ++
I naming the directories after the repo makes the most sense, thats fine, that's what we are all used to and where the mwa-* names came from before the Great Pivot. repo gives us the flexibility to do what makes the most sense here.
2) Strip out the addons/wr-cgcs/layers/cgcs, however replacing it with 'stx-utils' is not very attractive. I'm thinking something more like 'packages' or 'src'. Other options welcome. ++
I'm fine with a different name, not sure I have a better idea of what though.
Can we agree this is a positive step? Is it the right time to undertake this change? Both changes in the same set of updates, or split them? Totally positive! My experiences say that this is the sort of thing that will be painful no matter when we do it, waiting for X usually means when X comes Y has appeared to wait on. I favor doing it as soon as we know what we want to do.
I would split them into two sets of reviews though, I think that will make debugging a bit simpler with only one type of thing changing at a time.
It will require both a manifest change, and a number of updates to hard coded paths within various scripts. Grep is my friend, but I might need a little help identifying scripts not originating from Wind Rivers original code drop. We'll be able to help there, I think most of those are concerned with things outside or next to the build tree, like the mirror creation.
I'm a little worried about out of tree or side branch copies of the manifests. Thought on how to handle this? We can use Zulu/Gerrit's Depends-On capability to co-ordinate the merge of these reviews so we do not spend a significant amount of time with repos in a inconsistent state. Maybe make all of the (other) reviews depend on the manifest review, then we +W the manifest review last and Zulu will merge them all at roughly the same time.
Right now there is only one manifest file in stx-manifest. The pain here will be all in-flight work affected, which is likely to be a lot of it. Ian has mentioned about 70 reviews queued up since R5 release, I suspect much of that would need to be rebased. This is the 'X' I mention above. If we hold the restructure to merge all of that first something else may come up in the mean time. I would like to hear from someone closer to those affected here about how to weigh this tradeoff.
Thanks for kicking this off Scott dt
On Fri, Jun 29, 2018 at 3:09 PM, Scott Little <scott.little@windriver.com> wrote:
I have the two sets of updates nearly ready.
1) Rename the mwa-* subdirectories, making the directory name match the git name. e.g. mwa-sparta will be replaced by stx-integ.
2) Strip out the addons/wr-cgcs/layers/cgcs, replacing it with 'stx'
After both change sets, common paths will look like ... e.g.
$MY_REPO/stx/stc-integ $MY_REPO/stx/git/nova
Much better!
I think we are targeting July 5 to have the change sets out for review, and hopefully quick acceptance.
OK, holiday week should be slow and is a good time to do this I think. We should have https://review.openstack.org/578532 merged by then so Depends-On will work across repos and we could make them all depend on the manifest change so everything merges at once. The cool thing is, if (when!) we have tests running, we could test the entire set together using this. I think you should go ahead and post them to Gerrit and mark them WIP so I don't go and merge them early (oops). repo can pull from Gerrit easily. That would give us a chance to try it out, we may have some additional things that need tweaking to follow your changes immediately.
With respect to the manifest files, I'm still working with stx-r0.xml. Is that ok, or would it be preferable to start a new one? The old would be unbuildable. I'm just wondering if it would help folks during the transition to still have access to the old manifest.
We need to make stx-manifest/default.xml be the normal starting point. Thanks Scott! dt -- Dean Troyer dtroyer@gmail.com
participants (2)
-
Dean Troyer
-
Scott Little