<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi all,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I am not sure that merging the test repository on the kata-containers repository will help to make easier the release process or if we will gain any benefit in doing it. I see a lot issues and a lot work that will need to be done if we
merge the test repository into kata-containers. First, we will need to change the CI installation scripts, the tests scripts, the Jenkins jobs configurations, the scripts that are running on the Github Actions, etc. Second, when we raise the PR to merge tests
in kata-containers, we will need to create a special CI to test this PR because if we only merge it without testing it well that will be a disaster. Third, do we have a strategy to merge PRs that are merged later on the test repository or what we are going
to do? Now about the release, I strongly believe that even if we merge the repos the release process the problem will be still there. The main issue why we spend a lot of time in doing releases is because the lack of backporting. In my experience, I have face
that people do not backport their PRs that are merge on main into the stable branches maybe because they forget, they do not know if a certain PR needs a backport or they just do not care about stable branches. If someone is doing a backport and a certain
CI is failing (which is non familiar or it is not the owner) an issue needs to be created and ask the owners to start to take a look in order to have help and fix the issue before the release process begins. I noticed that most of the time PRs are merged and
a certain CI is failing and no issues are created at all. Doing the merging of the repositories will require effort and time, even if a certain person only does the job this will require guidance and support from other members and I am not sure if this is
a priority for the project. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards,<o:p></o:p></p>
<p class="MsoNormal">Gabriela<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Cameron Meadors <cmeadors@redhat.com> <br>
<b>Sent:</b> Tuesday, August 17, 2021 2:00 PM<br>
<b>To:</b> Fabiano Fidêncio <fabiano@fidencio.org><br>
<b>Cc:</b> kata-dev <kata-dev@lists.katacontainers.io><br>
<b>Subject:</b> Re: [kata-dev] About merging the tests repo into the kata-containers one<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">I only have one comment that I have already made and it got some traction so worth bringing up again. The comment is that there is value in separating e2e/integration tests that are not version specific from component/unit tests that are.
There should be much less churn in the non-version specific tests therefore reducing the overhead of having a separate repo. On the other hand, changes to version specific tests normally are made at the same time as their respective code changes. I am not
sure if we know which tests are version specific or not and if we are ready to make a forward looking decisions like this now, but I think keeping the test repo but only having non-versions specific tests there would solve the problems that have been presented.
I think it also might solve the problem that Gabriela's proposal would solve, although I don't fully understand that problem.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Anyway, just wanted to bring that up again. One single repo or two separate repos will both work. Just a matter of the tradeoffs.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Aug 16, 2021 at 8:44 AM Fabiano Fidêncio <<a href="mailto:fabiano@fidencio.org" target="_blank">fabiano@fidencio.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal">During the last architecture committee meeting (Aug 10th, 2021) this<br>
topic was brought up again and it's driven by simplifying the current<br>
workflow.<br>
<br>
Archana & Eric raised some concerns about the amount of churn / commit<br>
pollution in the kata-containers repository.<br>
<br>
This discussion is not new, we've had it on<br>
<a href="https://github.com/kata-containers/kata-containers/issues/187" target="_blank">https://github.com/kata-containers/kata-containers/issues/187</a> and we<br>
even agreed in one of the meetings that merging the repo would be the<br>
way to go, although it'd generate a lot of work that no-one at that<br>
point would be willing to take.<br>
<br>
Regardless of what was discussed, we didn't get the input of people<br>
who are majoritarily working on that repo, being Gabriela & Salvador<br>
the main ones, and I know they may have some concerns about the topic.<br>
So, Gabriela, Salvador, would you mind sharing the concerns?<br>
<br>
One last thing from my side, while I'm in favour of doing the move,<br>
I'd like to ensure we take the decision based on the right<br>
motivations. Merging the repos will *not* solve the problems we have<br>
on maintaining the stable branches and, for that, please take a look<br>
at Gabriela's proposal<br>
<a href="https://github.com/kata-containers/kata-containers/issues/2429" target="_blank">https://github.com/kata-containers/kata-containers/issues/2429</a><br>
<br>
Please, share your opinions, concerns, and ideas.<br>
<br>
Best Regards,<br>
-- <br>
Fabiano Fidêncio<br>
<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>