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.

Version: GnuPG/MacGPG2 v2.0.22 (Darwin)


OpenStack-dev mailing list

Reply via email to