[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