On 7/12/2017 3:44 PM, Kendall Nelson wrote:

@Jay: I would definitely urge projects to update the places they have any info about bug tracking since different projects use tags differently. I suppose we could add to the SB documentation what the common practices are, but I imagine there will be a lot of project specific details about how the project sets up their boards and worklists, what tags they use, how things are formatted etc that would be better kept elsewhere.

Agreed, this is an opportunity to for Cinder to document how we use StoryBoard as we migrate to it and anything that is specific to our usage is something we document. :-) I am asking if there is a high level common documentation location. I found development documentation and links in your Wiki. Looking for the, 'here is what everyone needs to know to start using StoryBoard' documentation so I can get that linked in our devref.

Hope that makes sense.

@Sean: Agreed! Having it dealt with before we reach critical mass in SB will save us later. As one of the people helping people migrate to sb, I will include this decision in the information I give projects that are migrating. I think we have a FAQ somewhere we can add the decision to as well.

-Kendall (diablo_rojo)

On Wed, Jul 12, 2017 at 1:34 PM Jay S Bryant <jungleb...@gmail.com <mailto:jungleb...@gmail.com>> wrote:

    Kendall,

    It looks like our current bug tracking documentation is quite
    minimal:
    https://docs.openstack.org/cinder/latest/devref/launchpad.html#bug-tracking

    Is there going to be a place where SB is going to be documented
    with some of these details that we can link to under our
    bug-tracking section?

    Thanks!

    Jay



    On 7/12/2017 3:19 PM, Kendall Nelson wrote:
    Hey Sean :)

    So we discussed the issue of tag collisions in the SB meeting we
    had today. Basically, we came to the conclusion that projects
    should append their project to the start of the tag, thereby
    avoiding collision i.e. ironic-compute, nova-compute,
    manila-storage, swift-storage, cinder-storage. If we can ask bug
    triagers in their respective projects to follow and uphold the
    convention, we should be fine. It might also be helpful to add
    this to any directions projects might have about filing bugs so
    new contributors start off on the right foot.

    Thanks for bringing this concern up before it becomes a problem!
    If anyone has other questions or concerns, please attend our
    meetings or drop into our channel (#storyboard)!

    -Kendall Nelson(diablo_rojo)

    [1] https://wiki.openstack.org/wiki/Meetings/StoryBoard

    On Wed, Jul 12, 2017 at 5:47 AM Sean Dague <s...@dague.net
    <mailto:s...@dague.net>> wrote:

        On 07/11/2017 04:31 PM, Jeremy Stanley wrote:
        > On 2017-07-10 07:33:28 -0400 (-0400), Sean Dague wrote:
        > [...]
        >> Ideally storyboard would just be a lot more receptive to
        these kinds of
        >> things, by emitting a more native event stream,
        >
        > Well, there is
        > <URL:
        
http://git.openstack.org/cgit/openstack-infra/storyboard/tree/storyboard/notifications/publisher.py
        >
        > so replacing or partnering its RabbitMQ publisher with
        something
        > like an MQTT publisher into firehose.openstack.org
        <http://firehose.openstack.org> is probably not
        > terribly hard for someone with interest in that and would be
        > generally useful.
        >
        >> and having really good tag support (preferably actually
        project
        >> scoped tags, so setting it on the nova task doesn't impact the
        >> neutron tasks on the same story, as an for instance)
        > [...]
        >
        > Your queries (including those used to build automatic
        tasklists and
        > boards) could just include project in addition to tag,
        right? Or is
        > this more of a UI concern, being able to click on an
        arbitrary tag
        > in the webclient and only get back a set of tagged stories
        for the
        > same project rather than across all projects?

        My concern is based on current limitations in launchpad, and
        to make
        sure they don't get encoded into Storyboard.

        Tags in launchpad are at the Bug level. Bugs map to projects
        as Tasks.
        Which is why you can have 1 Bug set to be impacting both Nova and
        Neutron. You get lots of weirdness today when for instance a
        bug is
        assigned to Nova and Ironic, and the Nova team tags it
        "ironic" in
        triage, but that means that now Ironic has a bug with the
        "ironic" tag.
        Then if later Nova is removed from the bug, it ends up really all
        looking odd and confusing.

        Or the fact that "compute" as a Nova tag means the compute
        worker, but
        other teams tag things with compute to just mean Nova is
        involved.
        Project scoped tags would help clarify what context it is in.

                -Sean

        >
        >
        >
        >
        
__________________________________________________________________________
        > OpenStack Development Mailing List (not for usage questions)
        > Unsubscribe:
        openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
        <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
        >
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
        >


        --
        Sean Dague
        http://dague.net

        
__________________________________________________________________________
        OpenStack Development Mailing List (not for usage questions)
        Unsubscribe:
        openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
        <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
        http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <mailto:openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

    __________________________________________________________________________
    OpenStack Development Mailing List (not for usage questions)
    Unsubscribe:
    openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
    <http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
    http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to