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: github.com/zqfan <http://github.com/zqfan>
_______________________________________________
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
_______________________________________________
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: github.com/zqfan <http://github.com/zqfan>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
