[Starlingx-discuss] Restructuring round 2

Scott Little scott.little at windriver.com
Tue Jul 17 20:48:02 UTC 2018


On 18-07-17 03:55 PM, Dean Troyer wrote:
> We need to stick to the review process as much as possible, we're
> already getting into some bad habits that will be hard to break.
>
> I think it would be useful to post the reviews as soon as possible and
> mark them WIP (workflow -1) so they don't merge.  That's where the
> specific discussions about tweaks can/should happen.
>
> Also, if the reviews for each repo are stacked we can build a manifest
> file to pull the reviews directly from Gerrit and actually test a
> build before merging it.

My challenge is trying to not disrupt the next set of updates being back 
ported to StarlingX from Titanium.  If I go and re-arrange everything, 
their patch sets won't apply.  Conversely their updates will break many 
of the relocation patches if they were created based on todays content.

The model I've adopted is to create scripts to perform all the 
relocations.  I can generate the relocation patches in a hurry. I'll run 
the script as soon as the last titanium back port is accepted or 
abandoned.  The result will be a blizzard of reviews of content that's 
already been reviewed.  The internal stx-integ relocations with 'git mv' 
are trivial enough.  However, package moves between repos will look like 
large blocks of all new code, when it's nothing of the sort.  The only 
competent reviewer is likely another script that runs diff a lot.

My fears are:

1) Standard reviews will just invite lots of comments on the code 
content, rather than it's location and a few path changes.  Those 
battles should already have been fought when the code was delivered to 
it's original location.

2) A long review process might prevent Titanium from converging, forcing 
a third back port cycle.

Hoping someone has suggestions ....


Scott





More information about the Starlingx-discuss mailing list