Open Stack

@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.

@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 <jungleboyj at 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 <sean at 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 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20170712/3305eefe/attachment.html>