Re: [openstack-dev] Requirements syncing job is live
Hello ZhiQiang, I'm not sure what HEADs you mean: oslo-incubator doesn't contain git submodules, but rather regular Python packages. On the other hand, oslo.version/oslo.messaging/oslo.* are separate libraries, having their own releases, so syncing of global requirements will effectively make projects use newer versions of those libs. Thanks, Roman On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan aji.zq...@gmail.com wrote: great job! thanks (how about auto sync from oslo too? - projects.txt: projects want to be automatically synced from oslo - heads.txt: HEAD for each module in oslo whenever module maintainer think current module is strong enough to publish, then he/she can edit the heads.txt of that module line, then jenkins will propose a sync patch for projects listed in projects.txt this behavior will be dangerous, since it may pass gate test when merge but cause internal bug which is not well test coverd) On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor mord...@inaugust.com wrote: Hey all! The job to automatically propose syncs from the openstack/requirements repo went live today - as I'm sure you all noticed, since pretty much everyone got a patch of at least some size. The job works the same way as the translations job - it will propose a patch any time the global repo changes - but if there is already an outstanding change that has not been merged, it will simply amend that change. So there should only ever be one change per branch per project in the topic openstack/requirements submitted by the jenkins user. If a change comes in and you say to yourself ZOMG, that version would break us - then you should definitely go and propose an update to the global list itself, which is in the global-requirements.txt file in the openstack/requirements repo. The design goal, as discussed at the last two summits, is that we should converge on alignment by the release at the very least. With this and the changes that exist now in the gate to block non-aligned requirements, once we get aligned, we shouldn't probably be too far out from each other moving forward. Additionally, the list of projects to receive updates is managed in a file, projects.txt, in the openstack/requirements repo. If you are running a project and would like to receive syncing patches, feel free to add yourself to the list. Enjoy! Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Requirements syncing job is live
Hi, Roman, auto sync requirements is a good job. It is so good that I'm wondering if the oslo-incubator can do such job too, because i noticed that there are some patches just update oslo-incubator modules, (no related bug, just normal update, sorry i cannot remember specific example), sometimes only one single module. I think if some modules in oslo-incubator fix important bugs, new wonderful features or just a series of stable enough commits, then the maintainer can modify the HEAD(git commit hash id of that module stable version, the oslo-incubator's real HEAD will always newer than it, sorry for the confused term) of that module in conf file, then jenkins can propose a patch to each project automatically, and all project can be aligned to the 'HEAD'. sorry, i didn't notice the other independent oslo libraries, i just hope oslo-incubator can do this (unlike oslo.config can be installed independent, only update requirement can do such job) On Wed, Oct 2, 2013 at 4:01 PM, Roman Podolyaka rpodoly...@mirantis.comwrote: Hello ZhiQiang, I'm not sure what HEADs you mean: oslo-incubator doesn't contain git submodules, but rather regular Python packages. On the other hand, oslo.version/oslo.messaging/oslo.* are separate libraries, having their own releases, so syncing of global requirements will effectively make projects use newer versions of those libs. Thanks, Roman On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan aji.zq...@gmail.com wrote: great job! thanks (how about auto sync from oslo too? - projects.txt: projects want to be automatically synced from oslo - heads.txt: HEAD for each module in oslo whenever module maintainer think current module is strong enough to publish, then he/she can edit the heads.txt of that module line, then jenkins will propose a sync patch for projects listed in projects.txt this behavior will be dangerous, since it may pass gate test when merge but cause internal bug which is not well test coverd) On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor mord...@inaugust.comwrote: Hey all! The job to automatically propose syncs from the openstack/requirements repo went live today - as I'm sure you all noticed, since pretty much everyone got a patch of at least some size. The job works the same way as the translations job - it will propose a patch any time the global repo changes - but if there is already an outstanding change that has not been merged, it will simply amend that change. So there should only ever be one change per branch per project in the topic openstack/requirements submitted by the jenkins user. If a change comes in and you say to yourself ZOMG, that version would break us - then you should definitely go and propose an update to the global list itself, which is in the global-requirements.txt file in the openstack/requirements repo. The design goal, as discussed at the last two summits, is that we should converge on alignment by the release at the very least. With this and the changes that exist now in the gate to block non-aligned requirements, once we get aligned, we shouldn't probably be too far out from each other moving forward. Additionally, the list of projects to receive updates is managed in a file, projects.txt, in the openstack/requirements repo. If you are running a project and would like to receive syncing patches, feel free to add yourself to the list. Enjoy! Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Requirements syncing job is live
Requirements is a little different, because we actually know in advance that the code will work with the latest requirements before we propose the change to the projects, as the requirements changes are gated on tempest/devstack. proposed changes to oslo don't attempt to run them against all the projects (though... that would be interesting...) so we don't actually know that what's in oslo will work everywhere (and it often doesn't). So there autosync is not yet appropriate. On 10/02/2013 04:40 AM, ZhiQiang Fan wrote: Hi, Roman, auto sync requirements is a good job. It is so good that I'm wondering if the oslo-incubator can do such job too, because i noticed that there are some patches just update oslo-incubator modules, (no related bug, just normal update, sorry i cannot remember specific example), sometimes only one single module. I think if some modules in oslo-incubator fix important bugs, new wonderful features or just a series of stable enough commits, then the maintainer can modify the HEAD(git commit hash id of that module stable version, the oslo-incubator's real HEAD will always newer than it, sorry for the confused term) of that module in conf file, then jenkins can propose a patch to each project automatically, and all project can be aligned to the 'HEAD'. sorry, i didn't notice the other independent oslo libraries, i just hope oslo-incubator can do this (unlike oslo.config can be installed independent, only update requirement can do such job) On Wed, Oct 2, 2013 at 4:01 PM, Roman Podolyaka rpodoly...@mirantis.com mailto:rpodoly...@mirantis.com wrote: Hello ZhiQiang, I'm not sure what HEADs you mean: oslo-incubator doesn't contain git submodules, but rather regular Python packages. On the other hand, oslo.version/oslo.messaging/oslo.* are separate libraries, having their own releases, so syncing of global requirements will effectively make projects use newer versions of those libs. Thanks, Roman On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan aji.zq...@gmail.com mailto:aji.zq...@gmail.com wrote: great job! thanks (how about auto sync from oslo too? - projects.txt: projects want to be automatically synced from oslo - heads.txt: HEAD for each module in oslo whenever module maintainer think current module is strong enough to publish, then he/she can edit the heads.txt of that module line, then jenkins will propose a sync patch for projects listed in projects.txt this behavior will be dangerous, since it may pass gate test when merge but cause internal bug which is not well test coverd) On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: Hey all! The job to automatically propose syncs from the openstack/requirements repo went live today - as I'm sure you all noticed, since pretty much everyone got a patch of at least some size. The job works the same way as the translations job - it will propose a patch any time the global repo changes - but if there is already an outstanding change that has not been merged, it will simply amend that change. So there should only ever be one change per branch per project in the topic openstack/requirements submitted by the jenkins user. If a change comes in and you say to yourself ZOMG, that version would break us - then you should definitely go and propose an update to the global list itself, which is in the global-requirements.txt file in the openstack/requirements repo. The design goal, as discussed at the last two summits, is that we should converge on alignment by the release at the very least. With this and the changes that exist now in the gate to block non-aligned requirements, once we get aligned, we shouldn't probably be too far out from each other moving forward. Additionally, the list of projects to receive updates is managed in a file, projects.txt, in the openstack/requirements repo. If you are running a project and would like to receive syncing patches, feel free to add yourself to the list. Enjoy! Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com http://zqfan.github.com git:
Re: [openstack-dev] Requirements syncing job is live
Hi, Sean Dague, Thank you for the clarification. On Wed, Oct 2, 2013 at 7:44 PM, Sean Dague s...@dague.net wrote: Requirements is a little different, because we actually know in advance that the code will work with the latest requirements before we propose the change to the projects, as the requirements changes are gated on tempest/devstack. proposed changes to oslo don't attempt to run them against all the projects (though... that would be interesting...) so we don't actually know that what's in oslo will work everywhere (and it often doesn't). So there autosync is not yet appropriate. On 10/02/2013 04:40 AM, ZhiQiang Fan wrote: Hi, Roman, auto sync requirements is a good job. It is so good that I'm wondering if the oslo-incubator can do such job too, because i noticed that there are some patches just update oslo-incubator modules, (no related bug, just normal update, sorry i cannot remember specific example), sometimes only one single module. I think if some modules in oslo-incubator fix important bugs, new wonderful features or just a series of stable enough commits, then the maintainer can modify the HEAD(git commit hash id of that module stable version, the oslo-incubator's real HEAD will always newer than it, sorry for the confused term) of that module in conf file, then jenkins can propose a patch to each project automatically, and all project can be aligned to the 'HEAD'. sorry, i didn't notice the other independent oslo libraries, i just hope oslo-incubator can do this (unlike oslo.config can be installed independent, only update requirement can do such job) On Wed, Oct 2, 2013 at 4:01 PM, Roman Podolyaka rpodoly...@mirantis.com mailto:rpodolyaka@mirantis.**com rpodoly...@mirantis.com wrote: Hello ZhiQiang, I'm not sure what HEADs you mean: oslo-incubator doesn't contain git submodules, but rather regular Python packages. On the other hand, oslo.version/oslo.messaging/**oslo.* are separate libraries, having their own releases, so syncing of global requirements will effectively make projects use newer versions of those libs. Thanks, Roman On Wed, Oct 2, 2013 at 5:02 AM, ZhiQiang Fan aji.zq...@gmail.com mailto:aji.zq...@gmail.com wrote: great job! thanks (how about auto sync from oslo too? - projects.txt: projects want to be automatically synced from oslo - heads.txt: HEAD for each module in oslo whenever module maintainer think current module is strong enough to publish, then he/she can edit the heads.txt of that module line, then jenkins will propose a sync patch for projects listed in projects.txt this behavior will be dangerous, since it may pass gate test when merge but cause internal bug which is not well test coverd) On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor mord...@inaugust.com mailto:mord...@inaugust.com wrote: Hey all! The job to automatically propose syncs from the openstack/requirements repo went live today - as I'm sure you all noticed, since pretty much everyone got a patch of at least some size. The job works the same way as the translations job - it will propose a patch any time the global repo changes - but if there is already an outstanding change that has not been merged, it will simply amend that change. So there should only ever be one change per branch per project in the topic openstack/requirements submitted by the jenkins user. If a change comes in and you say to yourself ZOMG, that version would break us - then you should definitely go and propose an update to the global list itself, which is in the global-requirements.txt file in the openstack/requirements repo. The design goal, as discussed at the last two summits, is that we should converge on alignment by the release at the very least. With this and the changes that exist now in the gate to block non-aligned requirements, once we get aligned, we shouldn't probably be too far out from each other moving forward. Additionally, the list of projects to receive updates is managed in a file, projects.txt, in the openstack/requirements repo. If you are running a project and would like to receive syncing patches, feel free to add yourself to the list. Enjoy! Monty __**_ OpenStack-dev mailing list
Re: [openstack-dev] Requirements syncing job is live
On 2013-10-02 07:44:11 -0400 (-0400), Sean Dague wrote: Requirements is a little different, because we actually know in advance that the code will work with the latest requirements before we propose the change to the projects, as the requirements changes are gated on tempest/devstack. [...] Well, just gating the global change on tempest/devstack doesn't guarantee the resulting per-project changes will work for other project-specific tests (static analysis/style, unit/functional, et cetera). However, Jenkins is also going to report test results on those changes once they're proposed so it's still covered during that latter phase. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Requirements syncing job is live
great job! thanks (how about auto sync from oslo too? - projects.txt: projects want to be automatically synced from oslo - heads.txt: HEAD for each module in oslo whenever module maintainer think current module is strong enough to publish, then he/she can edit the heads.txt of that module line, then jenkins will propose a sync patch for projects listed in projects.txt this behavior will be dangerous, since it may pass gate test when merge but cause internal bug which is not well test coverd) On Wed, Oct 2, 2013 at 1:27 AM, Monty Taylor mord...@inaugust.com wrote: Hey all! The job to automatically propose syncs from the openstack/requirements repo went live today - as I'm sure you all noticed, since pretty much everyone got a patch of at least some size. The job works the same way as the translations job - it will propose a patch any time the global repo changes - but if there is already an outstanding change that has not been merged, it will simply amend that change. So there should only ever be one change per branch per project in the topic openstack/requirements submitted by the jenkins user. If a change comes in and you say to yourself ZOMG, that version would break us - then you should definitely go and propose an update to the global list itself, which is in the global-requirements.txt file in the openstack/requirements repo. The design goal, as discussed at the last two summits, is that we should converge on alignment by the release at the very least. With this and the changes that exist now in the gate to block non-aligned requirements, once we get aligned, we shouldn't probably be too far out from each other moving forward. Additionally, the list of projects to receive updates is managed in a file, projects.txt, in the openstack/requirements repo. If you are running a project and would like to receive syncing patches, feel free to add yourself to the list. Enjoy! Monty ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- blog: zqfan.github.com git: github.com/zqfan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
