<div dir="ltr">Hi,<div><br></div><div><div class="gmail_extra"><div class="gmail_quote">2017-07-14 11:04 GMT+02:00 Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Then I fail to understand why you're talking about source-only upload<br>
when I was talking about setting-up a CI. This makes no sense. Could you<br>
explain how the 2 are related?</blockquote><div><br></div><div>I think we are completely lost in this discussion.</div><div><br></div><div>It's simple, what I'm saying:</div><div><ol><li>don't have CI __now__<br></li><li>don't have tempest __now__</li></ol><div>Have both later.</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I was talking about setting-up a recieved hook type of CI, not using<br>
what I've setup on OpenStack infra, since you wrote you don't want to<br>
use it anymore. Now, you're complaining that the OpenStack infra is<br>
failing (do I understand this bit correctly?), though why should I<br>
attempt to fix the sources.list (which is a simple commit), if you're<br>
not going to use it anyway?<br></blockquote><div><br></div><div>I'm complaining that OS infra is failing and nobody is going to fix it and take care of it in future.</div><div><br></div><div>I'm fine to have CI with alioth Git, later. Difference is simple: If optional CI fails, we can work on packages even without it. If CI fails now, development is stopped. And it's broken now (for > 6 weeks now).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do not agree with you at all here. It is my point of view that running<br>
tempest and validating packages is a must have for OpenStack. On each<br>
and every release, I have seen failure to functional test OpenStack, and<br>
running tempest was super helpful. Not doing any type of functional<br>
testing is a huge regression, which would lead me to advise against<br>
using OpenStack in Debian if someone asks.<br></blockquote><div><br></div><div>Jessie was released without tempest check. I know it's not ideal and not perfect, but it's better than nothing.</div><div>BTW: We don't have tempest now in OS infra. We have only "build check". Same, as anybody must do before upload - build package.</div><div><br></div><div>Compare it:</div><div><ol><li>tempest - we don't have it now, we will don't have it in near future<br></li><li>tests run during build - we have now in CI and we will run them before upload even without CI (when building package before upload)</li></ol><div>Sounds same?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Also, I don't think you can compare OpenStack with other packages. It's<br>
quite unique in Debian to have such a large amount of packages for a<br>
single software solution, and I don't know anything else that interact<br>
with so many parts of the system (including, but not limited to: KVM,<br>
Qemu, libvirt, rabbitmq-server, Maria/MySQL server, networking bridges,<br>
etc.).<br></blockquote><div><br></div><div>Xorg, kernel, systemd, dbus for example?</div><div><br></div><div>For me OS packages is same as other Debian packages and I want to work with them same as with other packages.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If not using an automatic deployment of OpenStack and tempest, how will<br>
you make sure that the next release is really working? I see only a<br>
single other way: following the install-guide (which may, at the same<br>
time, provide you an opportunity to maintain it) and manually install<br>
OpenStack, then manually run tempest. This could work, but would need a<br>
lot more time than using the automation already in place.<br></blockquote><div><br></div><div>I want to use/run tempest, but later.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Probably Debconf would be a good place/time to discuss it with DSA.<br></blockquote><div><br></div><div>yep, I already arranged sprint at DebConf, will you be there?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do not think that there's my way vs your way. I don't think anyone can<br>
even remotely contest the advantage of functional testing. The only<br>
issue is how, and if there's enough resources to do it.<br></blockquote><div><br></div><div>As i sad: functional testing is nice, but not must-have.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The reason why I decide to stop doing the OpenStack packaging in Debian,<br>
is because I cannot be fulltime on it, and I saw that there's not enough<br>
contributor. Therefore, my thinking is that quality cannot be at the<br>
level I think it should be. If you can't, or don't want to run tempest<br>
and functional test packages, then I would advise you to not attempt to<br>
continue the packaging of OpenStack in Debian as well. There's nothing<br>
personal here, and nothing about your skills (you are a very skilled<br>
person).<br></blockquote><div><br></div><div>I can't tempest a functional test packages now, but I'm open to have it later.</div><div><br></div><div>TBH, my motivation is to have working Git for packages I'm in uploader field. Do you have any problem with my suggestions for this group of OS packages? </div><div><br></div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Best regards<br> Ondřej Nový<br> <br>Email: <a href="mailto:novy@ondrej.org" target="_blank">novy@ondrej.org</a></div><div>PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B<br></div></div></div></div></div></div>
</div></div></div>