Open Stack

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 <rpodolyaka at mirantis.com
> <mailto:rpodolyaka at 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.zqfan at gmail.com
>     <mailto:aji.zqfan at 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
>         <mordred at inaugust.com <mailto:mordred at 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 at lists.openstack.org
>             <mailto:OpenStack-dev at lists.openstack.org>
>             http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>         --
>         blog: zqfan.github.com <http://zqfan.github.com>
>         git: github.com/zqfan <http://github.com/zqfan>
>
>         _______________________________________________
>         OpenStack-dev mailing list
>         OpenStack-dev at lists.openstack.org
>         <mailto:OpenStack-dev at lists.openstack.org>
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> blog: zqfan.github.com <http://zqfan.github.com>
> git: github.com/zqfan <http://github.com/zqfan>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Sean Dague
http://dague.net