<div dir="ltr"><div class="gmail_extra">Some comments inline.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Salvatore<br><br><div class="gmail_quote">On 20 August 2014 17:38, Ihar Hrachyshka <span dir="ltr"><<a href="mailto:ihrachys@redhat.com" target="_blank">ihrachys@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA512<br>
<br>
Hi all,<br>
<br>
I've read the proposal for incubator as described at [1], and I have<br>
several comments/concerns/suggestions to this.<br>
<br>
Overall, the idea of giving some space for experimentation that does<br>
not alienate parts of community from Neutron is good. In that way, we<br>
may relax review rules and quicken turnaround for preview features<br>
without loosing control on those features too much.<br>
<br>
Though the way it's to be implemented leaves several concerns, as follows:<br>
<br>
1. From packaging perspective, having a separate repository and<br>
tarballs seems not optimal. As a packager, I would better deal with a<br>
single tarball instead of two. Meaning, it would be better to keep the<br>
code in the same tree.<br>
<br>
I know that we're afraid of shipping the code for which some users may<br>
expect the usual level of support and stability and compatibility.<br>
This can be solved by making it explicit that the incubated code is<br>
unsupported and used on your user's risk. 1) The experimental code<br>
wouldn't probably be installed unless explicitly requested, and 2) it<br>
would be put in a separate namespace (like 'preview', 'experimental',<br>
or 'staging', as the call it in Linux kernel world [2]).<br>
<br>
This would facilitate keeping commit history instead of loosing it<br>
during graduation.<br>
<br>
Yes, I know that people don't like to be called experimental or<br>
preview or incubator... And maybe neutron-labs repo sounds more<br>
appealing than an 'experimental' subtree in the core project. Well,<br>
there are lots of EXPERIMENTAL features in Linux kernel that we<br>
actively use (for example, btrfs is still considered experimental by<br>
Linux kernel devs, while being exposed as a supported option to RHEL7<br>
users), so I don't see how that naming concern is significant.<br></blockquote><div><br></div><div>I think this is the whole point of the discussion around the incubator and the reason for which, to the best of my knowledge, no proposal has been accepted yet. </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2. If those 'extras' are really moved into a separate repository and<br>
tarballs, this will raise questions on whether packagers even want to<br>
cope with it before graduation. When it comes to supporting another<br>
build manifest for a piece of code of unknown quality, this is not the<br>
same as just cutting part of the code into a separate<br>
experimental/labs package. So unless I'm explicitly asked to package<br>
the incubator, I wouldn't probably touch it myself. This is just too<br>
much effort (btw the same applies to moving plugins out of the tree -<br>
once it's done, distros will probably need to reconsider which plugins<br>
they really want to package; at the moment, those plugins do not<br>
require lots of time to ship them, but having ~20 separate build<br>
manifests for each of them is just too hard to handle without clear<br>
incentive).<br></blockquote><div><br></div><div>One reason instead for moving plugins out of the main tree is allowing their maintainers to have full control over them.</div><div>If there was a way with gerrit or similars to give somebody rights to merge code only on a subtree I probably would not even consider the option of moving plugin and drivers away. From my perspective it's not that I don't want them in the main tree, it's that I don't think it's fair for core team reviewers to take responsibility of approving code that they can't fully tests (3rd partt CI helps, but is still far from having a decent level of coverage).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. The fact that neutron-incubator is not going to maintain any stable<br>
branches for security fixes and major failures concerns me too. In<br>
downstream, we don't generally ship the latest and greatest from PyPI.<br>
Meaning, we'll need to maintain our own downstream stable branches for<br>
major fixes. [BTW we already do that for python clients.]<br>
<br></blockquote><div><br></div><div>This is a valid point. We need to find an appropriate trade off. My thinking was that incubated projects could be treated just like client libraries from a branch perspective.</div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Another unclear part of the proposal is that notion of keeping<br>
Horizon and client changes required for incubator features in<br>
neutron-incubator. AFAIK the repo will be governed by Neutron Core<br>
team, and I doubt the team is ready to review Horizon changes (?). I<br>
think I don't understand how we're going to handle that. Can we just<br>
postpone Horizon work till graduation?<br>
<br></blockquote><div><br></div><div>I too do not think it's a great idea, mostly because there will be horizon bits not shipped with horizon, and not verified by horizon core team.</div><div>I think it would be ok to have horizon support for neutron incubator. It won't be the first time that support for experimental features is added in horizon.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
5. The wiki page says that graduation will require full test coverage.<br>
Does it mean 100% coverage in 'coverage' report? I don't think our<br>
existing code is even near that point, so maybe it's not fair to<br>
require that from graduated code.<br></blockquote><div><br></div><div>I agree that by these standards we should take the whole neutron and return it to incubation, or probably just chuck it in the bin.</div><div>It's not a mystery that Neutron quality is well below integrated level but let's not diverge.</div>
<div><br></div><div>On the other hand, the fact that Neutron's code is rubbish does not authorise the addition of further rubbish.</div><div>I see this requirement for graduation as a measure to ensure new additions to neutron have proper quality.</div>
<div>In the meanwhile it will be mandatory for the neutron community to keep working on quality, scalability and improve testing coverage.</div><div>Otherwise there will be no talk about neutron-incubator, mostly because probably there will be no neutron.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
A separate tree would probably be reasonable if it would be governed<br>
by a separate team. But as it looks now, it's still Neutron Cores who<br>
will do the review heavy-lifting. So I wonder why not just applying<br>
different review rules for patches for core and the staging subtree.<br></blockquote><div><br></div><div>This is a good point. As a neutron core I don't want to do the heavy lifting there. I think we should define rules which allow teams to iterate quickly while enabling the neutron core team to retain some form of control on what goes in the incubator.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[1]: <a href="https://wiki.openstack.org/wiki/Network/Incubator" target="_blank">https://wiki.openstack.org/wiki/Network/Incubator</a><br>
[2]:<br>
<a href="http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging" target="_blank">http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging</a><br>
<br>
/Ihar<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)<br>
<br>
iQEcBAEBCgAGBQJT9MDpAAoJEC5aWaUY1u57bYAH/0LsZonj3zVmWomUBBPriUOm<br>
GRoNBHq6C7BCfO7gRnQQyRd/N4jCL4Y1Dfbfv2Ypulsgf0x+ugvmzOrWm2Sa7KiS<br>
F3adumx+0OjJSMb5SSOxZQHpsZFjJmwtJjat9vwOYFXcCXhn8r9AgN3TPm5GyZ29<br>
NPY+SQdqu+G/ZgXd94sE2+gGbx0H5nLZusJD0yiUpoNExhv4qvjHSZW1rwssb+Ac<br>
3dU3LU1FqhM7UxkgnWk6AGYHfLjr5CfxXBrmikQsxXljl8Sko9DBTpKa3YtVcBX1<br>
FdMWLGn13nFNasGAKHot/aRfmdfPIzN0TsjjfRstm0W1VLvvbQjLxGTQDEyey/U=<br>
=vdaC<br>
-----END PGP SIGNATURE-----<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br></div></div>