[Starlingx-discuss] Directory restructuring
Scott Little
scott.little at windriver.com
Fri Jun 29 20:09:04 UTC 2018
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 at 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
>
More information about the Starlingx-discuss
mailing list