[Engine-devel] New gerrit flags behavior
Hi everyone! With the latest gerrit upgrade it has become easier to add the propagation of the Code Review and Verified flags when doing a trivial rebase or when no code was changed, so I've enabled those features for all the projects! The change should become effective right away, so let me know if you have any issues. Enjoy! -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 signature.asc Description: OpenPGP digital signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] ovirt-specs project needed
El vie 10 ene 2014 10:50:52 CET, Sandro Bonazzola escribió: Hi, can you please create a new gerrit project named ovirt-specs? it will contain .spec files for needed packages not provided by downstream distributions. It will contain: - httpcomponents-core (needed by java sdk, missing on CentOS) - httpcomponents-client (needed by java sdk, missing on CentOS) It should contain also jasper server, actually in its own repository and jboss actually packaged by us but without a git repo for the spec file. Thanks, Maybe we can use the existing releng-tools repo to store the external projects specs that we need, I think that as they are part of the release process they fit well there. -- David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization RD Email: dc...@redhat.com Web: www.redhat.com RHT Global #: 82-62605 signature.asc Description: OpenPGP digital signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
- Original Message - From: Dave Neary dne...@redhat.com To: Itamar Heim ih...@redhat.com Cc: engine-devel engine-devel@ovirt.org, vdsm-de...@lists.fedorahosted.org Sent: Wednesday, October 9, 2013 12:07:45 PM Subject: Re: [vdsm] stale gerrit patches Hi, On 09/23/2013 12:36 PM, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches I'm coming late to this discussion, but I see that there were some dissenting views from people who want maintainers to be able to store in-progress patches in Gerrit. I am all in favour of treating Gerrit like we treat a bug tracker. If something is opened in the bug tracker, it should be a bug, an open bug is something to be fixed or closed, not to be left indefinitely. An open patch needs to be rejected, reviewed, revised or committed. I don't think Gerrit is the place for in-progress patches (use private branches for that). Just point out that you can also use 'drafts' to store those in progress changes: http://gerrit-documentation.googlecode.com/svn/ReleaseNotes/ReleaseNotes-2.3.html#_drafts Cheers, Dave. -- Dave Neary - Community Action and Impact Open Source and Standards, Red Hat - http://community.redhat.com Ph: +33 9 50 71 55 62 / Cell: +33 6 77 01 92 13 ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] [vdsm] stale gerrit patches
On Mon 23 Sep 2013 12:36:58 PM CEST, Itamar Heim wrote: we have some very old gerrit patches. I'm for abandoning patches which were not touched over 60 days (to begin with, I think the number should actually be lower). they can always be re-opened by any interested party post their closure. i.e., looking at gerrit, the patch list should actually get attention, and not be a few worth looking at, with a lot of old patches thoughts? Thanks, Itamar ___ vdsm-devel mailing list vdsm-de...@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel It might helpful to have a cron-like script that checks the age of the posts and first notifies the sender, the reviewers and the maintainer, and if the patch is not updated in a certain period just abandons it. -- David Caro Red Hat Czech s.r.o. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic RHT Global #: 82-62605 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal for new commit msg design for engine commits
trying, it'll increase ownership and area of responsibility within our code and hopefully provide us the functionality we are looking for. we can start doing the obvious mapping, after-which the responsibility of each team/maintainer to assign a file to a person and define the specific functional areas in it. Moran. But surely labels or meta-data in the commit msg are quicker to implement. - fabian eyal. - fabian ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Infra mailing list in...@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra -- David Caro Red Hat Czech s.r.o. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic RHT Global #: 82-62605 signature.asc Description: OpenPGP digital signature ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal for new commit msg design for engine commits
- Original Message - From: Alon Bar-Lev alo...@redhat.com To: David Caro dcaro...@redhat.com Cc: Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Friday, August 23, 2013 10:45:37 AM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits - Original Message - From: David Caro dcaro...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Friday, August 23, 2013 11:16:31 AM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits On 07/20/2013 08:53 PM, Alon Bar-Lev wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: infra in...@ovirt.org, engine-devel engine-devel@ovirt.org, Fabian Deutsch fabi...@redhat.com Sent: Saturday, July 20, 2013 9:41:56 PM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits This change to commit template has nothing to do with CI. it's a change that should reflect updated components relevance to the commit code. This commit template is mostly invalid, as touching more than one 'subsystem' is possible, and has not enough granularity. I suggest using a tag at the end with some extra syntax, like: Components: core, storage, db Components: all Components: all, !core, !db For example, database change should trigger what? All the jobs that are tagged for that component (db upgrades I suppose). And if the changes affect storage components then also storage, if the changes affect others then those others too. Infra change should trigger what? The same, all the jobs that are tagged as infra. A change of both user interface and command should trigger what? All the jobs tagged by user interface and/or command. So you end up with: userportal: storage: core: db: some message As I suggested before, I think it's better if you end with a commit message like: Some message Components: userportal, storage, core, db Actually it can be easily done with a tag in the gerrit comment instead of the commit message. Just to make who happy? The developer, the qe, the ci and the infra people. This mechanism is to avoid running all the tests all the time. Of course there are some times when all the tests should be run to make sure nothing else changed, but most times you just need to run part of them to make sure you did not break something obvious. And maybe there are 50 tests of network, and you need only 5 of them for the specific change, how do you mark it, so now a developer need to know any test? what if you add one tomorrow which is relevant to a similar change? how do you inform the developer that now he needs 6? As I said before, what the developer specifies is not a list of tests, but a list of components, that qe has to map to different sets of tests that can change with time. So specifying webadmin will run all the tests in that group, that might be only one, or 100, and might be increasing/decreasing with time transparently for the developer. Adding a new component is not common and there's no need to do it so frequently. Why should it be the developer responsibility and not the quality ensuring engineer responsibility to determine which tests should run and when? Of course it's the responsibility of the qe engineer to determine when and which tests should be run. But this is meant to be a new tool for the developer not a substitute for the full qe tests, so the developer can easily make sure that he's changes do not break anything obvious before starting the real tests (that will take more time and resources). The developer just adds some metadata so the qe engineer can decide which tests to run per patch, so it's on qe's hand in the end to decide if ignore or not the metadata and which tests to run. As far as this template was not actually used for anything but humans, it was not that important, but once you formalize it as an interface, I step forward and state that the subject line is not the right tool for the task at hand (or any for this matter). I agree with that, I think that it should be a tag similar to Change-Id, at the end of the commit message. The fact that you have in each commit are the sources that are modified, all the other data is just plain noise. From the sources that are modified you should be able to derive a test plan with high chance that this test program will be correct. Human intervention should be possible by ordering special tests that are outside of the standard policy, for cases in which the standard policy of deriving tests from sources is too narrow
Re: [Engine-devel] Proposal for new commit msg design for engine commits
On Fri 23 Aug 2013 12:19:01 PM CEST, Alon Bar-Lev wrote: - Original Message - From: David Caro Estevez dcaro...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Friday, August 23, 2013 1:00:38 PM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits - Original Message - From: Alon Bar-Lev alo...@redhat.com To: David Caro dcaro...@redhat.com Cc: Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Friday, August 23, 2013 10:45:37 AM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits - Original Message - From: David Caro dcaro...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: Eyal Edri ee...@redhat.com, engine-devel engine-devel@ovirt.org, infra in...@ovirt.org Sent: Friday, August 23, 2013 11:16:31 AM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits On 07/20/2013 08:53 PM, Alon Bar-Lev wrote: - Original Message - From: Eyal Edri ee...@redhat.com To: Alon Bar-Lev alo...@redhat.com Cc: infra in...@ovirt.org, engine-devel engine-devel@ovirt.org, Fabian Deutsch fabi...@redhat.com Sent: Saturday, July 20, 2013 9:41:56 PM Subject: Re: [Engine-devel] Proposal for new commit msg design for engine commits This change to commit template has nothing to do with CI. it's a change that should reflect updated components relevance to the commit code. This commit template is mostly invalid, as touching more than one 'subsystem' is possible, and has not enough granularity. I suggest using a tag at the end with some extra syntax, like: Components: core, storage, db Components: all Components: all, !core, !db For example, database change should trigger what? All the jobs that are tagged for that component (db upgrades I suppose). And if the changes affect storage components then also storage, if the changes affect others then those others too. Infra change should trigger what? The same, all the jobs that are tagged as infra. A change of both user interface and command should trigger what? All the jobs tagged by user interface and/or command. So you end up with: userportal: storage: core: db: some message As I suggested before, I think it's better if you end with a commit message like: Some message Components: userportal, storage, core, db Actually it can be easily done with a tag in the gerrit comment instead of the commit message. Just to make who happy? The developer, the qe, the ci and the infra people. This mechanism is to avoid running all the tests all the time. Of course there are some times when all the tests should be run to make sure nothing else changed, but most times you just need to run part of them to make sure you did not break something obvious. And maybe there are 50 tests of network, and you need only 5 of them for the specific change, how do you mark it, so now a developer need to know any test? what if you add one tomorrow which is relevant to a similar change? how do you inform the developer that now he needs 6? As I said before, what the developer specifies is not a list of tests, but a list of components, that qe has to map to different sets of tests that can change with time. So specifying webadmin will run all the tests in that group, that might be only one, or 100, and might be increasing/decreasing with time transparently for the developer. Adding a new component is not common and there's no need to do it so frequently. Why should it be the developer responsibility and not the quality ensuring engineer responsibility to determine which tests should run and when? Of course it's the responsibility of the qe engineer to determine when and which tests should be run. But this is meant to be a new tool for the developer not a substitute for the full qe tests, so the developer can easily make sure that he's changes do not break anything obvious before starting the real tests (that will take more time and resources). The developer just adds some metadata so the qe engineer can decide which tests to run per patch, so it's on qe's hand in the end to decide if ignore or not the metadata and which tests to run. As far as this template was not actually used for anything but humans, it was not that important, but once you formalize it as an interface, I step forward and state that the subject line is not the right tool for the task at hand (or any for this matter). I agree with that, I think that it should be a tag similar to Change-Id, at the end of the commit message. The fact that you have in each commit are the sources that are modified, all the other data is just plain noise. From the sources that are modified you should be able to derive a test plan with high chance that this test program
[Engine-devel] ovirt_engine_find_bugs failing
Hi, the ovirt_engine_find_bugs job is failing very likely to a commit you made: http://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=commitdiff;h=1bf0e9f59e2208215f729cde32b0829152fef219;hp=6f238e7ee3d25fa28e85a55646bbbf739b49ef1f Can you please take a look at it? Thanks! -- David Caro Red Hat Czech s.r.o. Continuous Integration Engineer - EMEA ENG Virtualization RD Tel.: +420 532 294 605 Email: dc...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyn(ova 99/71, 612 45, Brno, Czech Republic RHT Global #: 82-62605 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
