Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi all,

I've read the proposal for incubator as described at [1], and I have
several comments/concerns/suggestions to this.

Overall, the idea of giving some space for experimentation that does
not alienate parts of community from Neutron is good. In that way, we
may relax review rules and quicken turnaround for preview features
without loosing control on those features too much.

Though the way it's to be implemented leaves several concerns, as follows:

1. From packaging perspective, having a separate repository and
tarballs seems not optimal. As a packager, I would better deal with a
single tarball instead of two. Meaning, it would be better to keep the
code in the same tree.

I know that we're afraid of shipping the code for which some users may
expect the usual level of support and stability and compatibility.
This can be solved by making it explicit that the incubated code is
unsupported and used on your user's risk. 1) The experimental code
wouldn't probably be installed unless explicitly requested, and 2) it
would be put in a separate namespace (like 'preview', 'experimental',
or 'staging', as the call it in Linux kernel world [2]).

This would facilitate keeping commit history instead of loosing it
during graduation.

Yes, I know that people don't like to be called experimental or
preview or incubator... And maybe neutron-labs repo sounds more
appealing than an 'experimental' subtree in the core project. Well,
there are lots of EXPERIMENTAL features in Linux kernel that we
actively use (for example, btrfs is still considered experimental by
Linux kernel devs, while being exposed as a supported option to RHEL7
users), so I don't see how that naming concern is significant.

2. If those 'extras' are really moved into a separate repository and
tarballs, this will raise questions on whether packagers even want to
cope with it before graduation. When it comes to supporting another
build manifest for a piece of code of unknown quality, this is not the
same as just cutting part of the code into a separate
experimental/labs package. So unless I'm explicitly asked to package
the incubator, I wouldn't probably touch it myself. This is just too
much effort (btw the same applies to moving plugins out of the tree -
once it's done, distros will probably need to reconsider which plugins
they really want to package; at the moment, those plugins do not
require lots of time to ship them, but having ~20 separate build
manifests for each of them is just too hard to handle without clear
incentive).

3. The fact that neutron-incubator is not going to maintain any stable
branches for security fixes and major failures concerns me too. In
downstream, we don't generally ship the latest and greatest from PyPI.
Meaning, we'll need to maintain our own downstream stable branches for
major fixes. [BTW we already do that for python clients.]

4. Another unclear part of the proposal is that notion of keeping
Horizon and client changes required for incubator features in
neutron-incubator. AFAIK the repo will be governed by Neutron Core
team, and I doubt the team is ready to review Horizon changes (?). I
think I don't understand how we're going to handle that. Can we just
postpone Horizon work till graduation?

5. The wiki page says that graduation will require full test coverage.
Does it mean 100% coverage in 'coverage' report? I don't think our
existing code is even near that point, so maybe it's not fair to
require that from graduated code.

A separate tree would probably be reasonable if it would be governed
by a separate team. But as it looks now, it's still Neutron Cores who
will do the review heavy-lifting. So I wonder why not just applying
different review rules for patches for core and the staging subtree.

[1]: https://wiki.openstack.org/wiki/Network/Incubator
[2]:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/staging

/Ihar
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJT9MDpAAoJEC5aWaUY1u57bYAH/0LsZonj3zVmWomUBBPriUOm
GRoNBHq6C7BCfO7gRnQQyRd/N4jCL4Y1Dfbfv2Ypulsgf0x+ugvmzOrWm2Sa7KiS
F3adumx+0OjJSMb5SSOxZQHpsZFjJmwtJjat9vwOYFXcCXhn8r9AgN3TPm5GyZ29
NPY+SQdqu+G/ZgXd94sE2+gGbx0H5nLZusJD0yiUpoNExhv4qvjHSZW1rwssb+Ac
3dU3LU1FqhM7UxkgnWk6AGYHfLjr5CfxXBrmikQsxXljl8Sko9DBTpKa3YtVcBX1
FdMWLGn13nFNasGAKHot/aRfmdfPIzN0TsjjfRstm0W1VLvvbQjLxGTQDEyey/U=
=vdaC
-----END PGP SIGNATURE-----