I think we should discuss the FRS at the DDF in a small OFP breakout - and probably beyond in the next OFP meeting and then decide.
On Thu, Oct 5, 2017 at 10:08 AM, Luis Gomez <[email protected]> wrote: > My question is simple, will OFP devs look and fix FRS related bugs? if yes > we can restore the FRS jobs, if not I think we are waisting resources. > > > On Oct 5, 2017, at 1:27 AM, Anil Vishnoi <[email protected]> wrote: > > I would suggest atleast we should open a bug for all the issues. > > Given that these jobs are remove, how do we verify that the job passes > with the new fixes ? Is there any way we can trigger these jobs ? > > On Tue, Oct 3, 2017 at 7:28 PM, Luis Gomez <[email protected]> wrote: > >> OK, we do not want to use unnecessary resources so here is the patch: >> https://git.opendaylight.org/gerrit/#/c/63927/ >> >> We can always revert if anybody wants to support FRS in future. >> >> BR/Luis >> >> >> On Sep 29, 2017, at 10:57 AM, Luis Gomez <[email protected]> wrote: >> >> Hi ofp devs, >> >> We have been marking FRS tests IGNORE for a while because this >> functionality has never been stable, my question is should we: 1) remove >> these jobs as suggested by this mail or 2) open bugs and fix FRS given we >> have people for this. >> >> BR/Luis >> >> >> Begin forwarded message: >> >> *From: *Jamo Luhrsen <[email protected]> >> *Subject: **[release] CSIT jobs with IGNORE status or no activity to >> resolve* >> *Date: *September 29, 2017 at 9:47:48 AM PDT >> *To: *Release <[email protected]>, " >> [email protected]" <[email protected] >> light.org> >> >> Hi all, >> >> Every release now (including SRs) we have one step to validate >> CSIT status. It's becoming very common for projects just to quickly mark >> their >> failing jobs as IGNORE or OKAY without providing any bug id or notes >> about progress to resolve the failures. >> >> There are probably several reasons projects do this, but the end result >> is that >> these jobs are not providing any value and just taking up valuable >> resources. >> >> We would like to start removing all jobs that go two releases in this same >> state. >> >> Having jobs with failures is ok. But those failures should be associated >> with >> some bug and/or some activity to resolve the failures. >> >> We can start this process with the Oxygen release in March, using >> Nitrogen's >> status [0] unless there are objections. >> >> Of course, each project would be notified prior to job removal, but the >> goal is >> to remove this overhead of investigating the same project CSIT failures. I >> took the liberty to do this already for SNMP [1]. >> >> Thanks, >> JamO >> >> [0] https://docs.google.com/spreadsheets/d/1VcB12FBiFV4GAEHZSspH >> BNxKI_9XugJp-6Qbbw20Omk/edit#gid=1568731761 >> [1] https://git.opendaylight.org/gerrit/#/q/topic:remove-snmp-csit >> _______________________________________________ >> release mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/release >> >> >> >> >> _______________________________________________ >> openflowplugin-dev mailing list >> [email protected] >> https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev >> >> > > > -- > Thanks > Anil > > > > _______________________________________________ > openflowplugin-dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev > >
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
