@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 <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> 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-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://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:unsubscribehttp://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 >
__________________________________________________________________________ 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