I believe the idea here is that projects can choose the list of jobs that will run to verify a patch, which means:
- Some projects that do not have or do not want to run csit on patches can set the list to EMPTY (default state). - In case of issues as you mention, committers of a project can temporary set the list of csit jobs to EMPTY. With the above I think the process is flexible enough to accommodate most or all projects needs. BR/Luis > On Jul 6, 2016, at 12:59 PM, Robert Varga <[email protected]> wrote: > > On 07/06/2016 07:28 PM, Andrew Grimberg wrote: >> Secondly, committers would _lose_ the verify rights as they would become >> completely managed by Jenkins. The values would change from -1 .. +1 to >> become -1 .. +2 >> >> Thirdly, committers would _lose_ the submit right. This would be >> completely controlled by Jenkins based upon state transitions. >> Effectively turning the "Approve +1" right that committers would be >> gaining into what would effectively be a "conditionally submit this >> code, provided all tests pass" operation. > > While I like the overall idea, I certainly do not have enough faith in > infrastructure and verification pipeline stability. > > I presume those test definitions will be in JJB, which means that when > infra goes south (as it has numerous times over the past year) or a > project goes AWOL (and looses its snapshot artifacts, for example), we > are dead in the water with no options to move forward until whatever > went wrong gets resolved -- which is a heavily PST-centric process and > has taken days (and weeks) to complete on more than one occasion. > > I am sorry, but this proposal will need to show a serious long-term SLA > before committers can be *asked* to relinquish these rights. > > Bye, > Robert > > _______________________________________________ > dev mailing list > [email protected] > https://lists.opendaylight.org/mailman/listinfo/dev _______________________________________________ openflowplugin-dev mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/openflowplugin-dev
