Re: [openstack-dev] [all] periodic jobs for master

2014-10-29 Thread Jeremy Stanley
On 2014-10-29 16:49:08 + (+), Andrea Frittoli wrote: [...] > About post merge CI: > http://kilodesignsummit.sched.org/event/1e33d1f4896a52e2c02b062cfc18ba39#.VFEZqvmsV8E > About moving functional test to projects: > http://kilodesignsummit.sched.org/event/575938e4837e8293615845582d7e3e7f#.V

Re: [openstack-dev] [all] periodic jobs for master

2014-10-29 Thread Andrea Frittoli
> > I'm sorry I've missed the email that you referred to before. Indeed, > it looks like I'm not the first one who started to think about the > matter. Summit wise, will there be any sessions where the subject will > be discussed? > Yes. About post merge CI: http://kilodesignsummit.sched.org/event

Re: [openstack-dev] [all] periodic jobs for master

2014-10-29 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 25/10/14 00:16, James E. Blair wrote: > Andrea Frittoli writes: > >> I also believe we can find ways to make post-merge / periodic >> checks useful. We need to do that to keep the gate to a sane >> scale. > > Yes, we have a plan to do that that

Re: [openstack-dev] [all] periodic jobs for master

2014-10-24 Thread James E. Blair
Andrea Frittoli writes: > I also believe we can find ways to make post-merge / periodic checks useful. > We need to do that to keep the gate to a sane scale. Yes, we have a plan to do that that we outlined at the infra/QA meetup this summer and described to this list in this email: http://lists

Re: [openstack-dev] [all] periodic jobs for master

2014-10-24 Thread Andrea Frittoli
I also believe we can find ways to make post-merge / periodic checks useful. We need to do that to keep the gate to a sane scale. On 24 October 2014 17:33, Thierry Carrez wrote: > Ihar Hrachyshka wrote: >> Another question to solve is how we disseminate state of those jobs. >> Do we create a sepa

Re: [openstack-dev] [all] periodic jobs for master

2014-10-24 Thread Thierry Carrez
Ihar Hrachyshka wrote: > 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. Should we explore other avenues than email for

Re: [openstack-dev] [all] periodic jobs for master

2014-10-24 Thread Ihar Hrachyshka
-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

Re: [openstack-dev] [all] periodic jobs for master

2014-10-22 Thread David Kranz
On 10/22/2014 06:07 AM, 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 r

Re: [openstack-dev] [all] periodic jobs for master

2014-10-22 Thread Chris Dent
On Wed, 22 Oct 2014, Thierry Carrez wrote: 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 o

Re: [openstack-dev] [all] periodic jobs for master

2014-10-22 Thread Thierry Carrez
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 t

[openstack-dev] [all] periodic jobs for master

2014-10-21 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, introducing a new auxiliary feature (e.g. a new messaging backend; some specific configuration of common services, like multiple workers in neutron; a new db driver supported by oslo.db; a plugin that lacks its own third-party CI like linuxb