On Wed, Dec 9, 2015 at 12:15 PM, David Caro <dc...@redhat.com> wrote:
> On 12/09 12:00, Amit Aviram wrote: > > On Wed, Dec 9, 2015 at 11:37 AM, Barak Korren <bkor...@redhat.com> > wrote: > > > > > >>> > [1]: http://www.ovirt.org/CI/Build_and_test_standards > > > >>> > > > > > > > > > That's nice, but most of us are not aware of all that.. > > > > > > > > > > Well, we can do a better job advocating that, I try to mention this > > > almost in any infra/devel thread where 'CI' is mentioned. > > > I'm open to suggestions about how to make developers more aware of the > > > fact that the ultimate power to determine what happens in CI had > > > mostly been placed in their hands... > > > > > > What I'm offering is not letting us a choice, exactly because what you > are > > saying regarding the fact that most of the influence of what happens in > CI > > is in our hands. otherwise what happens is the current situation where > > some/most of the developers are not aware of their options, or misses the > > mails or whatever.. > > > > > > > > > > > > From what I'm seeing, most of the developers here don't make their > > > patches > > > > drafts.. moreover, > > > > - personally I didn't even know that it will not trigger jobs if it > is a > > > > draft. (and I'm not the only one) > > > > > > Well, now you know... Adding 'devel' with hope more devs will read > this. > > > > > > > - sometimes I need to label my patches, therefor can't make it a > draft > > > > > > > By 'label' you mean set topic? > > > Not sure those are mutually exclusive, 'git review' options seem to > > > indicate they are not. I will look deeper into that. > > > > > > > nowadays we are waiting for the jobs too much to finish. and the > reality > > > is > > > > that too much jobs shouldn't run at all- despite all of the nice > things > > > you > > > > guys show here.. > > > > > > I which cases besides the patch not being "ready" (=draft...) should > > > jobs not run? > > > > > > > Most of the review process doesn't need the jobs to run. a patch has > 5-10, > > and sometimes much more sets until it is being merged- you don't need to > > run the jobs every single time you are updating your patch.. > > > > > > > > > > > > > > > I still think that it will be a better solution to force the > developer to > > > > activate the tests manually (by adding a flag when pushing or even > doing > > > it > > > > with the jenkins client..) > > > > > > > We tried to add the 'workflow' flag for that at some point (It is used > > > by most infra projects), but it was not accepted with any enthusiasm > > > by the devs, you can search back the discussion on 'devel'. > > > > > > The workflow makes job DISABLING optional. > > I'm suggesting making job ENABLING optional, with some other flag.. > > As we must run it to merge- it won't be missed, and will be triggered > only > > when needed. > > That's not true, the workflow make job enabling optional, if you don't set > it, > it will not run > So I think we should use it :) Why was it rejected? > > > > > > > > > > > > -- > > > Barak Korren > > > bkor...@redhat.com > > > RHEV-CI Team > > > > > > _______________________________________________ > > Infra mailing list > > in...@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Tel.: +420 532 294 605 > Email: dc...@redhat.com > IRC: dcaro|dcaroest@{freenode|oftc|redhat} > Web: www.redhat.com > RHT Global #: 82-62605 >
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel