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