[Engine-devel] repository closure status
Hi, 3.3.0 general availability is scheduled for: 2013-08-28 I've just checked repositories closure, here is the result: nightly Fedora 18: # repoclosure -l fedora -l updates -l updates-testing -r ovirt-nightly Reading in repository metadata - please wait Checking Dependencies Repos looked at: 4 fedora ovirt-nightly updates updates-testing Num Packages in Repos: 61537 package: ovirt-hosted-engine-setup-0.0.0-0.0.master.fc18.noarch from ovirt-nightly unresolved deps: sanlock-python = 0:2.8 sanlock = 0:2.8 package: vdsm-4.12.0-63.gitc7fc753.fc18.x86_64 from ovirt-nightly unresolved deps: libvirt-daemon = 0:1.0.2-1 package: vdsm-4.12.0-67.git978b0a4.fc18.x86_64 from ovirt-nightly unresolved deps: libvirt-daemon = 0:1.0.2-1 package: vdsm-4.12.0-72.git8d05744.fc18.x86_64 from ovirt-nightly unresolved deps: libvirt-daemon = 0:1.0.2-1 3.3 (RC) Fedora 18: # repoclosure -l fedora -l updates -l updates-testing -r ovirt-3.3 Reading in repository metadata - please wait Checking Dependencies Repos looked at: 4 fedora ovirt-3.3 updates updates-testing Num Packages in Repos: 61421 package: vdsm-4.12.0-0.1.rc3.fc18.i686 from ovirt-3.3 unresolved deps: python-ethtool = 0:0.8-1 libvirt-daemon = 0:1.0.2-1 package: vdsm-4.12.0-0.1.rc3.fc18.x86_64 from ovirt-3.3 unresolved deps: python-ethtool = 0:0.8-1 libvirt-daemon = 0:1.0.2-1 nightly Fedora 19: # repoclosure -l fedora -l updates -l updates-testing -r ovirt-nightly Reading in repository metadata - please wait Checking Dependencies Repos looked at: 4 fedora ovirt-nightly updates updates-testing Num Packages in Repos: 50256 package: ovirt-engine-reports-3.3.0-0.2.master.20130803235659.fc19.noarch from ovirt-nightly unresolved deps: jasperreports-server = 0:4.7.0 3.3 (RC) Fedora 19 is ok. -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ 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
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. That's just not true. The sources are complicated enough to make two changes in the same file to affect different components. Any reused code is prone to affect multiple components, making it really hard to determine by which changed files which tests to run. And if you go down to the function/class level it's even harder to decide and to maintain. And of course it's not human error free, as the metadata in the files/directories is defined and maintained by a human. And in my opinion is a lot harder to implement and maintain, and a lot less agile, and does not get rid of the human factor. Regards, Alon Nevertheless, i have no problems with your suggestions for metadata per directory to map all ovirt code. any suggestion how to push it forward? Eyal. - Original Message - From: Alon Bar-Lev alo...@redhat.com To: Eyal Edri
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. That's just not true. The sources are complicated enough to make two changes in the same file to affect different components. Any reused code is prone to affect multiple components, making it really hard to determine by which changed files which tests to run. And if you go down to the function/class level it's even harder to decide and to maintain. And of course it's not human error free, as the metadata in the files/directories is defined and
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
- 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
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 will be
