Re: [openstack-dev] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed
Hi, thanks for the advice. Will take a look. Regards On Mon, Feb 19, 2018, 8:28 AM Matthias Runge wrote: > On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote: > > Hello kolla team, > > > > It looks like stable builds for kolla have been failing for some time > now. Just forwarding this on to make sure the team is aware of it before > the need for a stable release comes up. > > > > > Build failed. > > > > > > - build-openstack-sphinx-docs > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/build-openstack-sphinx-docs/b0f5081/html/ > : SUCCESS in 2m 50s > > > - openstack-tox-py27 > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/openstack-tox-py27/b6577a4/ > : SUCCESS in 2m 27s > > > - kolla-publish-centos-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-source/29e3a2b/ > : POST_FAILURE in 1h 16m 44s > > > - kolla-publish-centos-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc12a93/ > : POST_FAILURE in 1h 08m 48s (non-voting) > > > - kolla-publish-ubuntu-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-source/dd419ce/ > : POST_FAILURE in 56m 40s > > > - kolla-publish-ubuntu-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-binary/a7fca30/ > : POST_FAILURE in 52m 05s (non-voting) > > > - kolla-publish-oraclelinux-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-source/7e87ef0/ > : POST_FAILURE in 1h 35m 59s > > > - kolla-publish-oraclelinux-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-binary/56eb5bd/ > : POST_FAILURE in 1h 42m 57s (non-voting) > > This one is differs significantly from the other build failures. > > Previously, only both ubuntu-related builds failed. > > Matthias > -- > Matthias Runge > > Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Michael Cunningham, > Michael O'Neill, Eric Shander > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed
On Sun, Feb 18, 2018 at 05:15:18AM -0600, Sean McGinnis wrote: > Hello kolla team, > > It looks like stable builds for kolla have been failing for some time now. > Just forwarding this on to make sure the team is aware of it before the need > for a stable release comes up. > > > Build failed. > > > > - build-openstack-sphinx-docs > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/build-openstack-sphinx-docs/b0f5081/html/ > > : SUCCESS in 2m 50s > > - openstack-tox-py27 > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/openstack-tox-py27/b6577a4/ > > : SUCCESS in 2m 27s > > - kolla-publish-centos-source > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-source/29e3a2b/ > > : POST_FAILURE in 1h 16m 44s > > - kolla-publish-centos-binary > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc12a93/ > > : POST_FAILURE in 1h 08m 48s (non-voting) > > - kolla-publish-ubuntu-source > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-source/dd419ce/ > > : POST_FAILURE in 56m 40s > > - kolla-publish-ubuntu-binary > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-binary/a7fca30/ > > : POST_FAILURE in 52m 05s (non-voting) > > - kolla-publish-oraclelinux-source > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-source/7e87ef0/ > > : POST_FAILURE in 1h 35m 59s > > - kolla-publish-oraclelinux-binary > > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-binary/56eb5bd/ > > : POST_FAILURE in 1h 42m 57s (non-voting) This one is differs significantly from the other build failures. Previously, only both ubuntu-related builds failed. Matthias -- Matthias Runge Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all][i18n] Accepting translations for Queens
Could everybody import translations, please?
* for master so that you have translated releasenotes
* for stable/queens for the iminent Queens release. Note that this one
removes translated releasenotes, we only translate and publish
releasenotes from master.
Full list of open reviews:
https://review.openstack.org/#/q/status:open+topic:zanata/translations
Thanks,
Andreas
--
Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tripleo] Usage of Depends-On in TripleO CI
Just an FYI if you haven't seen the thread on openstack-dev. -- Forwarded message -- From: Emilien Macchi Date: Sun, Feb 18, 2018 at 7:25 PM Subject: Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax To: "OpenStack Development Mailing List (not for usage questions)" < openstack-dev@lists.openstack.org> I just realized that the new syntax doesn't work when third party jobs use an old version of Zuul (e.g. RDO RCI). Which means: Depends-On: https://review.openstack.org/#/c/542556/ doesn't work and Depends-On: Ia30965b362d1c05d216f59b4cc1b3cb7e1284046 works for third party jobs. We have to be very careful how we use the feature in TripleO CI. I've lost a bit of time trying to figuring out why my code wasn't passing our functional tests when I realized my code wasn't properly checkout. My recommendation for TripleO devs: use the old syntax if you want your code to be tested by RDO Third party CI (now voting btw). Thanks, [...] __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [infra][all] New Zuul Depends-On syntax
I just realized that the new syntax doesn't work when third party jobs use an old version of Zuul (e.g. RDO RCI). Which means: Depends-On: https://review.openstack.org/#/c/542556/ doesn't work and Depends-On: Ia30965b362d1c05d216f59b4cc1b3cb7e1284046 works for third party jobs. We have to be very careful how we use the feature in TripleO CI. I've lost a bit of time trying to figuring out why my code wasn't passing our functional tests when I realized my code wasn't properly checkout. My recommendation for TripleO devs: use the old syntax if you want your code to be tested by RDO Third party CI (now voting btw). Thanks, On Mon, Feb 5, 2018 at 1:11 PM, Alex Schultz wrote: > On Thu, Feb 1, 2018 at 11:55 AM, James E. Blair > wrote: > > Zane Bitter writes: > > > >> Yeah, it's definitely nice to have that flexibility. e.g. here is a > >> patch that wouldn't merge for 3 months because the thing it was > >> dependent on also got proposed as a backport: > >> > >> https://review.openstack.org/#/c/514761/1 > >> > >> From an OpenStack perspective, it would be nice if a Gerrit ID implied > >> a change from the same Gerrit instance as the current repo and the > >> same branch as the current patch if it exists (otherwise any branch), > >> and we could optionally use a URL instead to select a particular > >> change. > > > > Yeah, that's reasonable, and it is similar to things Zuul does in other > > areas, but I think one of the thing we want to do with Depends-On is > > consider that Zuul isn't the only audience. It's there just as much for > > the reviewers, and other folks. So when it comes to Gerrit change ids, > > I feel we had to constrain it to Gerrit's own behavior. When you click > > on one of those in Gerrit, it shows you all of the changes across all of > > the repos and branches with that change-id. So that result list is what > > Zuul should work with. Otherwise there's a discontinuity between what a > > user sees when they click the hyperlink under the change-id and what > > Zuul does. > > > > Similarly, in the new system, you click the URL and you see what Zuul is > > going to use. > > > > And that leads into the reason we want to drop the old syntax: to make > > it seamless for a GitHub user to know how to Depends-On a Gerrit change, > > and vice versa, with neither requiring domain-specific knowledge about > > the system. > > > > While I can appreciate that, having to manage urls for backports in > commit messages will lead to missing patches and other PEBAC related > problems. Perhaps rather than throwing out this functionality we can > push for improvements in the gerrit interaction itself? I'm really -1 > on removing the change-id syntax just for this reasoning. The UX of > having to manage complex depends-on urls for things like backports > makes switching to URLs a non-starter unless I have a bunch of > external system deps (and I generally don't). > > Thanks, > -Alex > > > -Jim > > > > > __ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [keystone] Queens RC review dashboard
On 2/1/2018 9:51 AM, Lance Bragstad wrote: Just like with feature freeze, I put together a review dashboard that contains patches we need to land in order to cut a release candidate [0]. I'll be adding more patches throughout the day, but so far there are 21 changes there waiting for review. If there is something I missed, please don't hesitate to ping me and I'll get it added. Thanks for all the hard work. We're on the home stretch! [0]https://goo.gl/XVw3wr I reviewed your open stable/queens changes, left a question in one about how you want to handle the 'fixes' release note. I thought since I'm stable core I could +2 these but I can't, looks like keystone-stable-maint or the release core team can do that. -- Thanks, Matt __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] Adding Takashi Natsume to python-novaclient core
Thank you, Matt and everyone. But I would like to become a core reviewer for the nova project as well as python-novaclient. I have contributed more in the nova project than python-novaclient. I have done total 2,700+ reviews for the nova project in all releases (*1). (Total 115 reviews only for python-novaclient.) *1: http://stackalytics.com/?release=all&user_id=natsume-takashi On 2018/02/16 2:18, Matt Riedemann wrote: On 2/9/2018 9:01 AM, Matt Riedemann wrote: I'd like to add Takashi to the python-novaclient core team. python-novaclient doesn't get a ton of activity or review, but Takashi has been a solid reviewer and contributor to that project for quite awhile now: http://stackalytics.com/report/contribution/python-novaclient/180 He's always fast to get new changes up for microversion support and help review others that are there to keep moving changes forward. So unless there are objections, I'll plan on adding Takashi to the python-novaclient-core group next week. I've added Takashi to python-novaclient-core: https://review.openstack.org/#/admin/groups/572,members Thanks everyone. Regards, Takashi Natsume NTT Software Innovation Center E-mail: natsume.taka...@lab.ntt.co.jp __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] About the convention to use '.' instead of 'source'.
Excerpts from Jeremy Stanley's message of 2018-02-18 16:01:52 +: > On 2018-02-18 03:55:51 -0600 (-0600), Monty Taylor wrote: > [...] > > I'd honestly argue in favor of assuming bash and using 'source' > > because it's more readable. We don't make allowances for alternate > > shells in our examples anyway. > > > > I personally try to use 'source' vs . and $() vs. `` as > > aggressively as I can. > > > > That said - I completely agree with fungi on the description of > > the tradeoffs of each direction, and I do think it's valuable to > > pick one for the docs. > > Yes, it's not my call but I too would prefer more readable examples > over a strict adherence to POSIX. As long as we say somewhere that > our examples assume the user is in a GNU bash(1) environment and > that the examples may require minor adjustment for other shells, I > think that's a perfectly reasonable approach. If there's a > documentation style guide, that too would be a great place to > encourage examples following certain conventions such as source > instead of ., $() instead of ``, [] instead of test, an so on... and > provide a place to explain the rationale so that reviewers have a > convenient response they can link for bulk "improvements" which seem > to indicate ignorance of our reasons for these choices. I've proposed reverting the style-guide change that seems to have led to this discussion in https://review.openstack.org/#/c/545718/2 Doug __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tripleo] Updates on containerized undercloud
This is an update on what has been achieved this week with the regard of Containerized Undercloud efforts in TripleO: TL;DR: really good efforts have been made and we can now deploy a full (multinode) overcloud in CI. OVB testing in progress and lot of remaining items! ## Bugfixes docker-registry: add missing firewall rules - https://review.openstack.org/#/c/545185/ mistral-executor: mount /var/lib/mistral - https://review.openstack.org/#/c/545143/ docker: configure group/user for deployment_user - https://review.openstack.org/#/c/544761/ + dependencies Fix PublicVirtualFixedIPs in envs - https://review.openstack.org/#/c/544744/ Align zaqar max_messages_post_size with undercloud - https://review.openstack.org/#/c/544756/ undercloud_post: fix subnet name - https://review.openstack.org/#/c/544587/ ## CI We manage to run a containerized overcloud deployed by a containerized undercloud in CI, results can be seen here: https://review.openstack.org/#/c/542906/ The job is running on featureser010 now (for testing purpose) but as James mentioned in the review, we won't switch this job to run a containerized undercloud. Note there is no impact on the job runtime. We'll need to properly deprecate the non-containerized undercloud first but we'll need to find a CI job that we can use for gating, so we avoid regression during the cycle. Now we're working on deploying featureset001 (ovb-ha), with TLS, net-iso, Ironic/Nova/Neutron (baremetal bits) from a containerized undercloud: https://review.openstack.org/#/c/542556/ It's not working yet but we're working toward the blockers as they come during testing. # TLS Support All patches that were in progress have been merged, and now under testing in ovb-ha + containerized u/c (see above). # UI Support Work is still in progress, patches are ready for review, but some one them don't pass pep8 yet. We'll hopefully fix it soon. # Other items routed ctlplane networking: Harald is currently making progress on the items, some patches are ready for review. Create temp copy of tripleo-heat-templates before processing them: Bogdan is working on https://review.openstack.org/#/c/542875 - the patch is under review! Upgrades: no work has been started so far but we'll probably discuss about this topic during the PTG. As usual please comment or add anything that I missed. Thanks all for your help/reviews/efforts so far, Emilien On Tue, Feb 13, 2018 at 6:41 AM, Emilien Macchi wrote: > > > On Tue, Feb 13, 2018 at 2:40 AM, Harald Jensås wrote: > >> On Fri, 2018-02-09 at 14:39 -0800, Emilien Macchi wrote: >> > On Fri, Feb 9, 2018 at 2:30 PM, James Slagle >> > wrote: >> > [...] >> > >> > > You may want to add an item for the routed ctlplane work that >> > > landed >> > > at the end of Queens. Afaik, that will need to be supported with >> > > the >> > > containerized undercloud. >> > >> > Done: https://trello.com/c/kFtIkto1/17-routed-ctlplane-networking >> > >> >> Tanks Emilien, >> >> >> I added several work items to the Trello card, and a few patches. Still >> WiP. >> >> Do we have any CI that use containerized undercloud with actual Ironic >> deployement? Or are they all using deployed-server? >> >> E.g do we have anything actually testing this type of change? >>https://review.openstack.org/#/c/543582 >> >> I belive that would have to be an ovb job with containerized undercloud? >> > > I'm working on it since last week: https://trello.com/c/ > uLqbHTip/13-switch-other-jobs-to-run-a-containerized-undercloud > But currently trying to make things stable again, we introduce regressions > and this is high prio now. > -- > Emilien Macchi > -- Emilien Macchi __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] About the convention to use '.' instead of 'source'.
On 2018-02-18 03:55:51 -0600 (-0600), Monty Taylor wrote: [...] > I'd honestly argue in favor of assuming bash and using 'source' > because it's more readable. We don't make allowances for alternate > shells in our examples anyway. > > I personally try to use 'source' vs . and $() vs. `` as > aggressively as I can. > > That said - I completely agree with fungi on the description of > the tradeoffs of each direction, and I do think it's valuable to > pick one for the docs. Yes, it's not my call but I too would prefer more readable examples over a strict adherence to POSIX. As long as we say somewhere that our examples assume the user is in a GNU bash(1) environment and that the examples may require minor adjustment for other shells, I think that's a perfectly reasonable approach. If there's a documentation style guide, that too would be a great place to encourage examples following certain conventions such as source instead of ., $() instead of ``, [] instead of test, an so on... and provide a place to explain the rationale so that reviewers have a convenient response they can link for bulk "improvements" which seem to indicate ignorance of our reasons for these choices. -- Jeremy Stanley signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [zaqar] Fwd: [Openstack-stable-maint] Stable check of openstack/zaqar failed
Hello zaqar team, It looks like stable jobs have been failing for some time now for zaqar stable branches. Just forwarding on to make sure the team is aware of this. Thanks, Sean > Begin forwarded message: > > From: "A mailing list for the OpenStack Stable Branch test reports." > > Subject: [Openstack-stable-maint] Stable check of openstack/zaqar failed > Date: February 18, 2018 at 01:03:06 CST > To: openstack-stable-ma...@lists.openstack.org > Reply-To: openstack-dev@lists.openstack.org > > Build failed. > > - build-openstack-sphinx-docs > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/zaqar/stable/ocata/build-openstack-sphinx-docs/1e8b5bb/html/ > : SUCCESS in 4m 08s > - openstack-tox-py27 > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/zaqar/stable/ocata/openstack-tox-py27/db30e4f/ > : TIMED_OUT in 40m 44s > > ___ > Openstack-stable-maint mailing list > openstack-stable-ma...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [kolla]Fwd: [Openstack-stable-maint] Stable check of openstack/kolla failed
Hello kolla team, It looks like stable builds for kolla have been failing for some time now. Just forwarding this on to make sure the team is aware of it before the need for a stable release comes up. Thanks, Sean > Begin forwarded message: > > From: "A mailing list for the OpenStack Stable Branch test reports." > > Subject: [Openstack-stable-maint] Stable check of openstack/kolla failed > Date: February 18, 2018 at 01:51:32 CST > To: openstack-stable-ma...@lists.openstack.org > Reply-To: openstack-dev@lists.openstack.org > > Build failed. > > - build-openstack-sphinx-docs > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/build-openstack-sphinx-docs/b0f5081/html/ > : SUCCESS in 2m 50s > - openstack-tox-py27 > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/openstack-tox-py27/b6577a4/ > : SUCCESS in 2m 27s > - kolla-publish-centos-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-source/29e3a2b/ > : POST_FAILURE in 1h 16m 44s > - kolla-publish-centos-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-centos-binary/dc12a93/ > : POST_FAILURE in 1h 08m 48s (non-voting) > - kolla-publish-ubuntu-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-source/dd419ce/ > : POST_FAILURE in 56m 40s > - kolla-publish-ubuntu-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-ubuntu-binary/a7fca30/ > : POST_FAILURE in 52m 05s (non-voting) > - kolla-publish-oraclelinux-source > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-source/7e87ef0/ > : POST_FAILURE in 1h 35m 59s > - kolla-publish-oraclelinux-binary > http://logs.openstack.org/periodic-stable/git.openstack.org/openstack/kolla/stable/ocata/kolla-publish-oraclelinux-binary/56eb5bd/ > : POST_FAILURE in 1h 42m 57s (non-voting) > > ___ > Openstack-stable-maint mailing list > openstack-stable-ma...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-stable-maint __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [docs] About the convention to use '.' instead of 'source'.
On 02/17/2018 03:03 PM, Jeremy Stanley wrote: On 2018-02-17 13:47:02 -0500 (-0500), Hongbin Lu wrote: [...] If anyone can clarify the rationals of this convention, it will be really helpful. [...] There's a trade-off here: while `.` is standardized in POSIX sh (under Utilities, Dot in the specification), it's easy to miss when reading documentation and/or cutting and pasting from examples. On the other hand, `source` is easier to see but was originally unique to csh (which lacks `.`) and subsequently borrowed by the bash shell environment as an alias for `.` ostensibly to ease migration for users of csh and its derivatives. The `source` command is not implemented by a number of other popular shells however, which may make it a poor interoperability choice (given csh is an arguably less popular shell these days) unless we assume a specific shell (e.g., bash). I'd honestly argue in favor of assuming bash and using 'source' because it's more readable. We don't make allowances for alternate shells in our examples anyway. I personally try to use 'source' vs . and $() vs. `` as aggressively as I can. That said - I completely agree with fungi on the description of the tradeoffs of each direction, and I do think it's valuable to pick one for the docs. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
