I think there's still an issue, I get a infinite loop in the find_matching_files when running the report-released-packages.
> For 3 - I think either we keep all of esm-apps in subprojects or none of it -
> so for now I am keeping esm-apps/trusty there but we can revise later if/when
> needed.
>
Sure, that's cool by me :)
> 4 - push-esm-metrics appears to still function but since you wrote it I would
> be grateful if you could check the output is still as expected.
>
Yes, I can certainly take a look on that, but the infinite loop needs to be figured out first.
> 5 - I was trying to keep the number of changes limited here but am happy to
> refactor that in the future as I agree, it would be good to keep as much of
> the release specific info bits in the subprojects{} dict as possible. We can
> still generate releases_names, release_stamps etc from this to keep API
> compatibility though if we don't feel like refactoring everything else in UCT
> etc too.
Hi Alex,
> Thanks @ebarretto - 1 is addressed by /git.launchpad. net/~alexmurray /ubuntu- cve- commit/ ?id=54a1cfc84cc 8ea03ce8b8ff093 2e162103c4ef0f and 2 in /git.launchpad. net/~alexmurray /ubuntu- cve- commit/ ?id=34605c0a6cf 228e32e94ca1869 12f4b0d0e2b374 plus /code.launchpad .net/~alexmurra y/ubuntu- security- tools/+ git/ubuntu- tools/+ merge/405431 for UST.
> https:/
> tracker/
> https:/
> tracker/
> https:/
> security-
>
I think there's still an issue, I get a infinite loop in the find_matching_files when running the report- released- packages.
> For 3 - I think either we keep all of esm-apps in subprojects or none of it -
> so for now I am keeping esm-apps/trusty there but we can revise later if/when
> needed.
>
Sure, that's cool by me :)
> 4 - push-esm-metrics appears to still function but since you wrote it I would
> be grateful if you could check the output is still as expected.
>
Yes, I can certainly take a look on that, but the infinite loop needs to be figured out first.
> 5 - I was trying to keep the number of changes limited here but am happy to
> refactor that in the future as I agree, it would be good to keep as much of
> the release specific info bits in the subprojects{} dict as possible. We can
> still generate releases_names, release_stamps etc from this to keep API
> compatibility though if we don't feel like refactoring everything else in UCT
> etc too.
That's fine by me as-is, I was just wondering :)