<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Pranith/Prasanna: At the moment your problem is that you want to write tests in conjunction with your pull request and splitting into multiple repos do not give you this ability. Is that the compelling reason why you want this to happen in the gluster-block repo directly rather than glusto-tests?<br></div></div></blockquote><div><br></div><div>Yes. Goal is to be able to test HEAD with tests at HEAD, write tests once and be done. It would be nice if we can come up with a solution that doesn&#39;t lead to duplication of efforts from contributors to these two different projects like it is happening with GlusterFS now. How can we make that possible?</div></div></div></div></blockquote><div><br></div><div>Okay. Now that I understand what you&#39;re looking for. Let me explain why this project is split up.</div><div><br></div><div>We don&#39;t always test against HEAD. In the current state of the project (glusto-tests), we&#39;ll be writing tests that apply to multiple versions of Gluster simultaneously. That&#39;s why this project is split up. We often want to test the latest tests against an older version. (For example, a point release working fine). Glusto-tests are also end to end tests that are expected to take more than 24 hours to do a complete run. So even for Glusterfs, this is not something we&#39;re going to run per patch.</div><div><br></div><div>The goal that you have stated for gluster-block is slightly different from our goals we have for glusto-tests with Gluster. There are some words of caution:</div><div>* It&#39;s worth looking at how much time each test will add to your run. If it&#39;s going to take more than 2h, you&#39;re probably better off without it.</div><div>* If this is what you want to do, remember, if you have to backport a fix to an older release, you will not be able to run the latest tests against them.</div><div>* The glusto-tests repo is where we coordinate testing. It&#39;s where we manage the changes between versions of gluster and versioning. In short, if you have problems, the place we collaborate to solve them is the glusto-tests repo. If you choose to go the way of including tests in gluster-block, you&#39;re going to be essentially a place where we can&#39;t sync architecture changes with yours.</div><div>* This will create more work for automated testing overall as Rahul has already said.</div><div><br></div><div>The way things are going, we want to be in a place where we can at any point of time, we can tell the state of the entire stack -&gt; Gluster + GD2 + Gluster block. If you split this off, it&#39;s not going to make life impossible for me or Vijay. It&#39;s going to create more work. The point I&#39;m not clear about is whether you have enough gain with this.<br></div></div><br>-- <br><div dir="ltr" class="m_-1949427288847716249m_-710183780553198894m_-6372076400905547670gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">nigelb<br></div></div></div>