Open Stack

My +1 on both points.
Even more: project tests should enforce these style rules like it's done in
other projects.

I think those should be filed as wish-list bugs at least if not a
blueprints.


Eugene.


On Thu, Jun 6, 2013 at 12:44 PM, Tatiana V. Mazur <tmazur at mirantis.com>wrote:

> Hello!
>
> Recently I had to upload some patch sets and rebase some branches for this
> purpose. It appears that rebasing on changed master branch is not a trivial
> task. You know, when nearly each Horizon module includes a total mash of
> comma separated imports, that's really not a trivial task. Problems start
> when you add some method from the same module in an existing import
> statement like here:
>
> from .views import (IndexView, CreateView, EditAttachmentsView, DetailView,
>                     CreateSnapshotView)
>
> or even here:
>
> from .views import IndexView
> from .views import AddPoolView, AddMemberView, AddMonitorView, AddVipView
> from .views import (UpdatePoolView, UpdateMemberView,
>                     UpdateVipView, UpdateMonitorView)
> from .views import PoolDetailsView, VipDetailsView
> from .views import MemberDetailsView, MonitorDetailsView
> from .views import AddPMAssociationView, DeletePMAssociationView
>
> All patch sets including this kind of changes can't be merged
> automatically. You have to rebase manually, just because of a few imports.
> I was wondering if there is a local Horizon standard for importing and
> tried to find it in HACKING.rst (like all standards are described in other
> projects). And it appears there's no HACKING.rst in Horizon! That's why I
> have a few questions:
>
> 1. Does it make sense to implement all imports uniformly like that is done
> in other projects?
>
> Something like this would be nice:
>
> from quantum.api.extensions import (
>     ExtensionMiddleware,
>     PluginAwareExtensionManager,
> )
> from quantum.common import config
> from quantum.extensions import (
>     credential,
>     qos,
> )
>
> Or just one import per line. That would solve merging problems and code
> would look much better.
>
> 2. Does it make sense to add HACKING.rst in Horizon?
>
> I think yes. We could describe standards there and we would never get such
> kind of rebase and merge problems.
>
> What do you think about it? I could do it if you find it reasonable .
>
>
> Kind regards,
> Tatiana
>
> ______________________________**_________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130606/ddce184c/attachment.html>