On 22/06/2022 13:32, Bertrand Marquis wrote:Hi Andrew and Christopher,
I will not dig into the details of the issues you currently have
but it seems you are trying to re-do the work we already did
and have been using for quite a while.
Currently we maintain the xtf on arm code in gitlab and we
recently rebased it on the latest xtf master:
https://gitlab.com/xen-project/people/bmarquis/xtf
If possible I would suggest to start from there.
Sorry to be blunt, but no. I've requested several times for that seriesto be broken down into something which is actually reviewable, andbecause that has not been done, I'm doing it at the fastest pace myother priorities allow.Notice how 2/3 of the patches in the past year have been bitsspecifically carved out of the ARM series, or improvements to preventthe ARM series introducing technical debt. Furthermore, you've nottaken the "build ARM in CI" patch that I wrote specifically for you tobe part of the series, and you've got breakages to x86 from rebasing.At this point, I am not interested in seeing any work which is notmorphing (and mostly pruning) the arm-wip branch down into a set ofclean build system modifications that can bootstrap theas-minimal-as-I-can-make-it stub.
Andy,
You are not in a position to dictate to anyone else what work they will be doing; particularly if that dictation means, “Do nothing until I can get a chance to get around to it.”
Bertrand and his team have their own goals and priorities they need to accomplish, just like you do: they need to get additional XTF tests working, and they need to be able to share those with partners. They already put off that work for over a year waiting for you to get around to the architectural re-work you had in mind. It’s not reasonable to expect them to put off indefinitely their own needs and priorities, any more than it’s reasonable for them to expect you to drop your security work and other things you’ve been working on instead of refactoring the XTF architecture.
Bertrand knew when he made the branch that the more work done on the branch, the more effort it would take to eventually merge it upstream. You were told that they were going to create a branch and continue working on it; and you knew that the longer you delayed the architectural re-work you had in mind, the further Bertrand’s branch would drift. It was more important for you to work on security issues; it was more important for Bertrand to get additional functionality implemented and shared. You and Bertrand have both made your decisions with the full knowledge of the implications of your choices; there’s no point in complaining now that the natural consequences of your choices have in fact come to pass. And it’s hypocritical to be angry at Bertrand for having priorities higher than easy merging, when you did exactly the same thing.
Bertrands response to this thread — suggesting that you begin by testing his branch to see whether the bugs you’re looking at have already been fixed there — was reasonable, polite, and cooperative. Yours has not been; and this kind of response isn’t likely to encourage him to be cooperative in the future.
The sooner you accept that Bertrand's branch is going to continue to develop, gain more features and bugfixes, the more effectively you’ll be able to begin reducing the diff between the two, such that things can eventually be merged.
-George