+1 I agree with Pradeep and Doug that a new namespace makes for a better structure for packaging and usage.
Regards, Mandeep ----- On Mon, Aug 25, 2014 at 11:30 AM, Doug Hellmann <d...@doughellmann.com> wrote: > > On Aug 23, 2014, at 5:36 PM, Maru Newby <ma...@redhat.com> wrote: > > > > > On Aug 23, 2014, at 4:06 AM, Sumit Naiksatam <sumitnaiksa...@gmail.com> > wrote: > > > >> On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery <mest...@mestery.com> > wrote: > >>> On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka <ihrac...@redhat.com> > wrote: > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA512 > >>>> > >>>> On 20/08/14 18:28, Salvatore Orlando wrote: > >>>>> Some comments inline. > >>>>> > >>>>> Salvatore > >>>>> > >>>>> On 20 August 2014 17:38, Ihar Hrachyshka <ihrac...@redhat.com > >>>>> <mailto:ihrac...@redhat.com>> wrote: > >>>>> > >>>>> 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. > >>>>> > >>>>> > >>>>>> 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. > >>>>> > >>>> > >>>> I wonder where discussion around the proposal is running. Is it > public? > >>>> > >>> The discussion started out privately as the incubation proposal was > >>> put together, but it's now on the mailing list, in person, and in IRC > >>> meetings. Lets keep the discussion going on list now. > >>> > >> > >> In the spirit of keeping the discussion going, I think we probably > >> need to iterate in practice on this idea a little bit before we can > >> crystallize on the policy and process for this new repo. Here are few > >> ideas on how we can start this iteration: > >> > >> * Namespace for the new repo: > >> Should this be in the neutron namespace, or a completely different > >> namespace like "neutron labs"? Perhaps creating a separate namespace > >> will help the packagers to avoid issues of conflicting package owners > >> of the namespace. > > > > I don’t think there is a technical requirement to choose a new > namespace. Python supports sharing a namespace, and packaging can support > this feature (see: oslo.*). > > If the point of the incubator is to signal to deployers that the code > isn’t fully supported, you may want to use a different namespace for the > python/system packages as well. > > Doug > > > > >> > >> * Dependency on Neutron (core) repository: > >> We would need to sort this out so that we can get UTs to run and pass > >> in the new repo. Can we set the dependency on Neutron milestone > >> releases? We already publish tar balls for the milestone releases, but > >> I am not sure we publish these as packages to pypi. If not could we > >> start doing that? With this in place, the incubator would always lag > >> the Neutron core by at the most one milestone release. > > > > Given that it is possible to specify a dependency as a branch/hash/tag > in a git repo [1], I’m not sure it’s worth figuring out how to target > tarballs. Master branch of the incubation repo could then target the > master branch of the Neutron repo and always be assured of being current, > and then released versions could target milestone tags or released versions. > > > > 1: http://pip.readthedocs.org/en/latest/reference/pip_install.html#git > > > >> > >> * Modules overlapping with the Neutron (core) repository: > >> We could initially start with the features that required very little > >> or no changes to the Neutron core, to avoid getting into the issue of > >> blocking on changes to the Neutron (core) repository before progress > >> can be made in the incubator. > > > > +1 > > > > I agree that it would be in an incubated effort’s best interest to put > off doing invasive changes to the Neutron tree as long as possible to > ensure sufficient time to hash out the best approach. > > > >> > >> * Packaging of ancillary code (CLI, Horizon, Heat): > >> We start by adding these as subdirectories inside each feature. The > >> packaging folks are going to find it difficult to package this. > >> However, can we start with this approach, and have a parallel > >> discussion on how we can evolved this strategy? Perhaps the individual > >> projects might decide to allow support for the Neutron incubator > >> features once they can actually see what goes into the incubator, > >> and/or other projects might also follow the incubator approach. > > > > Maybe I’m missing something, but aren’t the integration points available > for the ancillary code the problem that needs solving (if it isn’t > already)? For example, it doesn’t matter the python package name of a > plugin, so long as it is installed on the system Neutron can be configured > to use it. I would hope we could have similar assurances for integration > code when the incubator repo is packaged. > > > > > > m. > > > >> > >> If we have loose consensus on the above, some of us folks who are > >> involved with features that are candidates for the incubator (e.g. > >> GBP, LBaaS), can immediately start iterating on this plan, and report > >> back our progress in a specified time frame. > >> > >> Thanks, > >> ~Sumit. > > > > > > <snip> > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev