For the project extra repo you will have to make the case to the TSC, this is explain in detail the issue you have today and how an extra repo would help with the same. After that you can get approval (or rejection) from TSC.
> On May 14, 2018, at 10:04 AM, Michael Vorburger <[email protected]> wrote: > > On Mon, May 14, 2018 at 6:59 PM, Luis Gomez <[email protected] > <mailto:[email protected]>> wrote: > > afaik we do not allow cycles between projects so this code may require new > project (if this has different scope than original) or new repo to resolve > the conflict. > > Can you tell us more about the "new repo" option? If we could have a 2nd > repo, which from a governance perspective is part of the existing genius > project, to host the code that is currently in genius/tools and genius/srm, > and build that before openflowplugin, and then openflowplugin and then after > that the "main" genius, then that is probably a good solution to this problem. > > How would we get that? >> On May 14, 2018, at 8:05 AM, Michael Vorburger <[email protected] >> <mailto:[email protected]>> wrote: >> >> On Mon, May 14, 2018 at 1:52 PM, D Arunprakash <[email protected] >> <mailto:[email protected]>> wrote: >> Hello, >> >> We are trying to use the genius service recovery framework(srm-api) from >> openflowplugin. >> >> https://git.opendaylight.org/gerrit/#/c/68998/ >> <https://git.opendaylight.org/gerrit/#/c/68998/> >> >> >> Since, odl-genius-srm was exposed as an independent feature and srm-api >> doesn’t dependent on ofp, we didn’t find any issues during compiling or >> feature install. >> >> >> >> But the autorelease validate jenkin build always failing with the below >> error. >> >> >> >> https://jenkins.opendaylight.org/releng/job/openflowplugin-validate-autorelease-fluorine/81/console >> >> <https://jenkins.opendaylight.org/releng/job/openflowplugin-validate-autorelease-fluorine/81/console> >> >> >> 09:17:41 + ./scripts/determine-merge-order.py >> >> 09:17:42 Traceback (most recent call last): >> >> 09:17:42 File "./scripts/determine-merge-order.py", line 80, in <module> >> >> 09:17:42 determine_merge_order() >> >> 09:17:42 File "./scripts/determine-merge-order.py", line 68, in >> determine_merge_order >> >> 09:17:42 for d in deps_order: >> >> 09:17:42 File >> "/w/workspace/openflowplugin-validate-autorelease-fluorine/venv/lib/python2.7/site-packages/networkx/algorithms/dag.py", >> line 197, in topological_sort >> >> 09:17:42 raise nx.NetworkXUnfeasible("Graph contains a cycle or graph >> changed " >> >> 09:17:42 networkx.exception.Ne >> <http://networkx.exception.ne/>tworkXUnfeasible: Graph contains a cycle or >> graph changed during iteration >> >> 09:17:42 Build step 'Execute shell' marked build as failure >> >> 09:17:42 $ ssh-agent -k >> >> >> >> >> >> Could you please let us know if the feature exposed from genius is proper or >> jenkin autorelease script detect the circular dependency, even though the >> odl-genius-srm doesn’t dependent on ofp. >> >> >> Arun, yeah you (OFP) should be able to depend on odl-genius-srm now, that's >> what all the effort of Moving datastore related utils from mdsalutil to new >> "genius.tools" was all about... I just had a look (on latest master) through >> genius/srm and genius/features/odl-genius-srm to make sure we didn't forget >> anything obvious, but all seems right to me... >> >> integration-dev: could any of you shed light on exactly what the failure >> above is trying to tell us - what cycle in the graph has this found? >> >> One thought: Are we allowed to have cycles between projects as long as >> artifacts themselves don't have cycles? Because that is what we are doing >> here - ofp wants genius.srm which needs genius.tools, which is independant >> of the rest of all of genius. genius.mdsalutils and the rest of genius is >> dependant on ofp. >> >> Or is that ^^^ is a problem for integration/autorelease? But why? there >> isn't really a cycle; and you can build this in a Maven reactor from sources >> without requiring binaries. >> >> Otherwise we have a bigger problem. Resolving that would require an entire >> new ODL project. OMG the paperwork... :-( >> >> Tx, >> M. >> -- >> Michael Vorburger, Red Hat >> [email protected] <mailto:[email protected]> | IRC: vorburger >> @freenode | ~ = http://vorburger.ch <http://vorburger.ch/> >> >> >> >> Regards, >> >> Arun >> >> >> _______________________________________________ >> genius-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.opendaylight.org/mailman/listinfo/genius-dev >> <https://lists.opendaylight.org/mailman/listinfo/genius-dev> >> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> <mailto:[email protected]> >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> <https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev> >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
