-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 22/10/14 12:07, Thierry Carrez wrote: > Ihar Hrachyshka wrote: >> [...] For stable branches, we have so called periodic jobs that >> are triggered once in a while against the current code in a >> stable branch, and report to openstack-stable-maint@ mailing >> list. An example of failing periodic job report can be found at >> [2]. I envision that similar approach can be applied to test >> auxiliary features in gate. So once something is broken in >> master, the interested parties behind the auxiliary feature will >> be informed in due time. [...] > > The main issue with periodic jobs is that since they are > non-blocking, they can get ignored really easily. It takes a bit of > organization and process to get those failures addressed. > > It's only recently (and a lot thanks to you) that failures in the > periodic jobs for stable branches are being taken into account > quickly and seriously. For years the failures just lingered until > they blocked someone's work enough for that person to go and fix > them. > > So while I think periodic jobs are a good way to increase corner > case testing coverage, I am skeptical of our collective ability to > have the discipline necessary for them not to become a pain. We'll > need a strict process around them: identified groups of people > signed up to act on failure, and failure stats so that we can > remove jobs that don't get enough attention. >
There should be interest groups behind each of periodic jobs (maybe sometimes consisting of one person). Yes, jobs should be tracked, though I assume that if the group is really interested in it, it will track it on daily basis. Otherwise, we'll see it rot and eventually removed. Let's say anyone can propose a job to remove in the mailing list, and we'll assess case by case whether it's ok to remove it instead of e.g. fixing it (because we have no interested parties to track it). Another question to solve is how we disseminate state of those jobs. Do we create a separate mailing list for that? Obviously we should not reuse -dev one, and it's overkill to create one mailing list per interest group. /Ihar -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCgAGBQJUSmWxAAoJEC5aWaUY1u5742kIAIIwMpTt3WL5j7RQkwtEc9qj xEHe0cC9gHtsCgxYrDkbhX2t3YmwZYg7tvzRYSJtds7hkRtiG4fjHSkdTWp3bW0m jYGoC7x4wMxjP6CPv2q/3CGdkE4+0AK9/aGurL22tcmHsqHj8COIAfuMB4np/y9n FSVyiHS86mlCx02BXIJkJwefpyO4ayM2H6IvtNjhtwYiwoH7mxQAvPpCW2vZPZOt xBSDTu0tcvlOm0xi8V8S2LDRvVaoV90w8zAh2jaNmeYVU3f/Js+X3VUa579epBOE kc0zaG1WYrcVxWkBDVGDRCBlvA9oCaQ4C8ZUFtJzGNS8Nss5/QfVndtoZSwWr5I= =L0NC -----END PGP SIGNATURE----- _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
