Topics

[honeycomb-dev] [nsh_sfc-dev] [discuss] Federating Jira with OpNFV

Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES@Cisco) <mmarsale@...>
 

I'd actually say it's a good idea.
The OPNFV issues are already in relations with fd.io issues. FDS from OPNFV is the biggest use case for Honeycomb. With FDS + Honeycomb in mind, there are many features required by FDS from Honeycomb, upon which the FDS builds. We track those features in fd.io JIRA and they are visible to FDS, but I'd say it's difficult to properly link them and keep that all up-to-date on FDS/ONPFV side. Why just not use JIRA features to make it easier?

So thinking mostly about "FDS ------depends------> fd.io" relationships here, it might be a bit easier to track and plan everything on both ends.

Maybe, if possible, we could limit what the federation includes e.g. one sided dependencies (OPNFV -> FD.IO).

Maros

-----Original Message-----
From: honeycomb-dev-bounces@... [mailto:honeycomb-dev-bounces@...] On Behalf Of Joel M. Halpern
Sent: Friday, September 16, 2016 5:27 AM
To: Keith Burns <alagalah@...>; Edward Warnicke <hagbard@...>; tsc@...; discuss@...; vpp-dev <vpp-dev@...>; csit-dev@...; deb_dpdk@...; honeycomb-dev@...; tldk-dev@...; nsh_sfc-dev@...; one-dev@...; trex-dev@...; vppsb-dev@...
Subject: Re: [honeycomb-dev] [nsh_sfc-dev] [discuss] Federating Jira with OpNFV

If there is an OPNFV activity that finds themselves blocked by an open fd.io issue, wouldn't we prefer that they point at our ticket for the issue, rather than them creating a proxy ticket?

Yours,
Joel

On 9/15/16 10:57 PM, Keith Burns wrote:
Would OPNFV JIRA issues be able to block/be dependent on etc FDIO
issues, or in any way cause a mesh of ticket interdependencies?

If so then my preference would be not to federate.



On Thu, Sep 15, 2016 at 9:26 AM Edward Warnicke <hagbard@...
<mailto:hagbard@...>> wrote:

In todays TSC meeting we discussed the possibility of federating the
fd.io <http://fd.io> Jira with the OpNFV Jira.
Federation 'connects' two Jira's while allowing them to remain
independent. The fd.io <http://fd.io> projects would
continue to be in the fd.io <http://fd.io> Jira, and the fd.io
<http://fd.io> issues would continue to be in the fd.io
<http://fd.io> Jira... but they would be accessible within the OpNFV
Jira, thus easing the process of that community in working on
integration of fd.io <http://fd.io> with other projects.

The sentiment towards this in the TSC call was warm, but there was a
desire to broaden the conversation over email.

There is a more complete description of Jira federation here:


https://confluence.atlassian.com/enterprise/federating-jira-managing-m
ultiple-instances-461504624.html

What do folks think?

Ed
_______________________________________________
discuss mailing list
discuss@... <mailto:discuss@...>
https://lists.fd.io/mailman/listinfo/discuss



_______________________________________________
nsh_sfc-dev mailing list
nsh_sfc-dev@...
https://lists.fd.io/mailman/listinfo/nsh_sfc-dev
_______________________________________________
honeycomb-dev mailing list
honeycomb-dev@...
https://lists.fd.io/mailman/listinfo/honeycomb-dev