Yeah, i understood that, just want to make sure that we can restore those jobs, so that we can use the job to test all the FRS related fixes.
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 > > > -- Thanks Anil
_______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
