From fandree at amazon.com Thu Jun 6 13:34:11 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Thu, 6 Jun 2019 13:34:11 +0000 Subject: [Rust-VMM] rust-vmm CI Message-ID: <1559828051548.78148@amazon.com> Hey everyone, A while ago we discussed about having a centralized placed for Buildkite pipelines and other integration tests that can be run for all repositories in rust-vmm [1]. For this scope I opened PR in rust-vmm-ci that contains: - a Buildkite pipeline with tests that can be run for all crates. The only pipeline there is the Linux one, but we will also add the Windows pipeline. In the meantime we can test vm-memory using the windows pipeline defined in the repository. - test_coverage.py: test to check that coverage does when merging new PRs The point of having one place with all common tests is to ensure that we keep the same quality standard across all crates in rust-vmm. It also avoids duplicating the same tests and pipelines across multiple repositories. It should make adding a CI for a new repository easier in the future. The mechanism I chose for using the same Buildkite pipeline in all repository is git submodules. More details about why I chose this approach can be found in the initial issue[1]. Let me know what you think on these 2 PRs: 1. rust-vmm-ci PR with the pipeline and integration tests [2] 2. kvm-ioctls PR that adds rust-vmm-ci as a git submodule [3]. Regards, Andreea [1] https://github.com/rust-vmm/community/issues/56 [2] https://github.com/rust-vmm/rust-vmm-ci/pull/2 [3] https://github.com/rust-vmm/kvm-ioctls/pull/48 Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Fri Jun 7 08:23:08 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Fri, 7 Jun 2019 10:23:08 +0200 Subject: [Rust-VMM] Project gate keeping Message-ID: <20190607082308.GA17640@caravaggio> All, As discussed during last week's call, I'd like to propose a light process for PR reviews and gate keeping. At the moment, when a PR lands in any of the existing crates, no one gets assigned to review it and we're asking for 2 review approvals before merging it. Those approvals should come from members of the crate's "team", and we need to arbitrarily build those teams on the fly based on the crate activity and contributions. As the number of incoming PRs is increasing, I feel we're starting to see some limitations with the above described model. While many PRs get actively reviewed, others slightly less. Also, pinging people for reviews and approvals is handled manually at the moment. In order to improve that situation, here is my proposal: - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected gatekeepers will be automatically assigned to any incoming PR. - Any gate keeper is free to assign someone else from the gate keeper team if she/he does not have the badwidth/knowledge to review the PR. - Encourage CODEOWNERS[1] file additions. Not all repos may need such ownership so I don't think this should be mandatory. - Any PR will be mergeable when any of the below conditions are met: * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper approved it. * On CODEOWNERS-less repos, 2 gate keepers approved it. - Initial PRs for empty crates could be handled differently and informally require more approvals from different people. I guess the natural question coming next is who should be part of this gate keeper team. rust-vmm being almost 6 months old, I think we now have a good idea of who are the most active contributors to the project. And I think it's logical to build this initial gate keepers team from those initial active contributors: Andreea Florescu @andreeaflorescu Alexandru Agache @alexandruag Alexandra Iordache @aghecenco Jiang Liu @jiangliu Paolo Bonzini @bonzini Zach Reizner @zachreizner Jenny Mankin @jennymankin Sebastien Boeuf @sboeuf Rob Bradford @rbradford Samuel Ortiz @sameo Comments, disagreements, additions, etc are all very welcome. Cheers, Samuel. [1] https://help.github.com/en/articles/about-code-owners --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From pbonzini at redhat.com Fri Jun 7 15:28:55 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Fri, 7 Jun 2019 17:28:55 +0200 Subject: [Rust-VMM] Project gate keeping In-Reply-To: <20190607082308.GA17640@caravaggio> References: <20190607082308.GA17640@caravaggio> Message-ID: <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> On 07/06/19 10:23, Samuel Ortiz wrote: > - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected > gatekeepers will be automatically assigned to any incoming PR. Would gatekeepers be automatically given access to all rustvmm repos? Is that possible from the GitHub UI or do you have to do that manually? > - Any gate keeper is free to assign someone else from the gate keeper > team if she/he does not have the badwidth/knowledge to review the PR. > - Encourage CODEOWNERS[1] file additions. Not all repos may need such > ownership so I don't think this should be mandatory. > - Any PR will be mergeable when any of the below conditions are met: > * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper > approved it. > * On CODEOWNERS-less repos, 2 gate keepers approved it. I think even that is too much; I don't see a reason to overload gatekeepers with the task of closing PRs. My proposal is: - up to 2 randomly selected code owners, or gatekeepers if there are <2 code owners will be automatically assigned to any incoming PR - as far as the GitHub UI is concerned, just one approving review from a code owner or gatekeeper is enough to merge - code owners and gatekeepers however are warmly encouraged to wait for a review from a second person for anything except obvious bugfixes, or to wait for a second code owner or gatekeeper to actually do the merge and close the PR. > - Initial PRs for empty crates could be handled differently and > informally require more approvals from different people. Agreed. Paolo From fandree at amazon.com Mon Jun 10 08:23:26 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Mon, 10 Jun 2019 08:23:26 +0000 Subject: [Rust-VMM] Project gate keeping In-Reply-To: <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> References: <20190607082308.GA17640@caravaggio>, <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> Message-ID: <1560155006024.67986@amazon.com> I prefer having two approvals either from code owners or gatekeepers when there are no code owners. Merging a PR with only one review should be an exception from my point of view. More often than not 2 different people looking at the code will find different bugs or other issues (lack of tests, documentation, others?). GitHub allows administrators to merge PRs even though there are not 2 reviews, so we can merge PRs with one review if needed, but I think we should have 2 reviewers as the rule. Andreea ________________________________________ From: Paolo Bonzini Sent: Friday, June 7, 2019 6:28 PM To: Samuel Ortiz; rust-vmm ML Subject: Re: [Rust-VMM] Project gate keeping On 07/06/19 10:23, Samuel Ortiz wrote: > - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected > gatekeepers will be automatically assigned to any incoming PR. Would gatekeepers be automatically given access to all rustvmm repos? Is that possible from the GitHub UI or do you have to do that manually? > - Any gate keeper is free to assign someone else from the gate keeper > team if she/he does not have the badwidth/knowledge to review the PR. > - Encourage CODEOWNERS[1] file additions. Not all repos may need such > ownership so I don't think this should be mandatory. > - Any PR will be mergeable when any of the below conditions are met: > * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper > approved it. > * On CODEOWNERS-less repos, 2 gate keepers approved it. I think even that is too much; I don't see a reason to overload gatekeepers with the task of closing PRs. My proposal is: - up to 2 randomly selected code owners, or gatekeepers if there are <2 code owners will be automatically assigned to any incoming PR - as far as the GitHub UI is concerned, just one approving review from a code owner or gatekeeper is enough to merge - code owners and gatekeepers however are warmly encouraged to wait for a review from a second person for anything except obvious bugfixes, or to wait for a second code owner or gatekeeper to actually do the merge and close the PR. > - Initial PRs for empty crates could be handled differently and > informally require more approvals from different people. Agreed. Paolo _______________________________________________ Rust-vmm mailing list Rust-vmm at lists.opendev.org http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. From samuel.ortiz at intel.com Mon Jun 10 08:34:49 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Mon, 10 Jun 2019 10:34:49 +0200 Subject: [Rust-VMM] Project gate keeping In-Reply-To: <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> References: <20190607082308.GA17640@caravaggio> <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> Message-ID: <20190610083449.GA14245@caravaggio> Hi Paolo, On Fri, Jun 07, 2019 at 05:28:55PM +0200, Paolo Bonzini wrote: > On 07/06/19 10:23, Samuel Ortiz wrote: > > - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected > > gatekeepers will be automatically assigned to any incoming PR. > > Would gatekeepers be automatically given access to all rustvmm repos? > Is that possible from the GitHub UI or do you have to do that manually? AFAIK with github you create a rust-vmm gatekeepers team, and then you have to manually add this team to each new repo. Much less tedious than added folks one by one. > > - Any gate keeper is free to assign someone else from the gate keeper > > team if she/he does not have the badwidth/knowledge to review the PR. > > - Encourage CODEOWNERS[1] file additions. Not all repos may need such > > ownership so I don't think this should be mandatory. > > - Any PR will be mergeable when any of the below conditions are met: > > * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper > > approved it. > > * On CODEOWNERS-less repos, 2 gate keepers approved it. > > I think even that is too much; I don't see a reason to overload > gatekeepers with the task of closing PRs. My proposal is: > > - up to 2 randomly selected code owners, or gatekeepers if there are <2 > code owners will be automatically assigned to any incoming PR > > - as far as the GitHub UI is concerned, just one approving review from a > code owner or gatekeeper is enough to merge > > - code owners and gatekeepers however are warmly encouraged to wait for > a review from a second person for anything except obvious bugfixes, I'd rather have a requirement for a second approval. The "warmly encouraged" part of that statement is a little too vague imho. Cheers, Samuel. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From pbonzini at redhat.com Mon Jun 10 11:25:07 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Mon, 10 Jun 2019 13:25:07 +0200 Subject: [Rust-VMM] Project gate keeping In-Reply-To: <1560155006024.67986@amazon.com> References: <20190607082308.GA17640@caravaggio> <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> <1560155006024.67986@amazon.com> Message-ID: On 10/06/19 10:23, Florescu, Andreea wrote: > I prefer having two approvals either from code owners or gatekeepers > when there are no code owners. Merging a PR with only one review > should be an exception from my point of view. More often than not 2 > different people looking at the code will find different bugs or > other issues (lack of tests, documentation, others?). > > GitHub allows administrators to merge PRs even though there are not 2 > reviews, so we can merge PRs with one review if needed, but I think > we should have 2 reviewers as the rule. My fear is that the second review will, more often than not, be a "drive-by" review where X gave a positive review so Y just clicks approve and merge---especially if the second review has to be from a gatekeeper that may not be that much in touch with the code. So I have no particular qualms with requiring two reviews, but I'd rather not require a separate gatekeeper "super-review" and instead allow 2 code owner reviews when there are 2 code owners. Paolo From fandree at amazon.com Mon Jun 10 12:52:20 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Mon, 10 Jun 2019 12:52:20 +0000 Subject: [Rust-VMM] Project gate keeping In-Reply-To: References: <20190607082308.GA17640@caravaggio> <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> <1560155006024.67986@amazon.com>, Message-ID: <1560171139490.79297@amazon.com> Hey Paolo, Two reviews from code owners sounds good to me as well. We should make sure that repositories being crated have code owners. Regards, Andreea ________________________________________ From: Paolo Bonzini Sent: Monday, June 10, 2019 2:25 PM To: Florescu, Andreea; Samuel Ortiz; rust-vmm ML Subject: Re: [Rust-VMM] Project gate keeping On 10/06/19 10:23, Florescu, Andreea wrote: > I prefer having two approvals either from code owners or gatekeepers > when there are no code owners. Merging a PR with only one review > should be an exception from my point of view. More often than not 2 > different people looking at the code will find different bugs or > other issues (lack of tests, documentation, others?). > > GitHub allows administrators to merge PRs even though there are not 2 > reviews, so we can merge PRs with one review if needed, but I think > we should have 2 reviewers as the rule. My fear is that the second review will, more often than not, be a "drive-by" review where X gave a positive review so Y just clicks approve and merge---especially if the second review has to be from a gatekeeper that may not be that much in touch with the code. So I have no particular qualms with requiring two reviews, but I'd rather not require a separate gatekeeper "super-review" and instead allow 2 code owner reviews when there are 2 code owners. Paolo Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. From samuel.ortiz at intel.com Tue Jun 11 05:07:37 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Tue, 11 Jun 2019 07:07:37 +0200 Subject: [Rust-VMM] Project gate keeping In-Reply-To: References: <20190607082308.GA17640@caravaggio> <22c09ab1-83e9-dcd0-19a6-45b0942ac371@redhat.com> <1560155006024.67986@amazon.com> Message-ID: <20190611050737.GB14245@caravaggio> On Mon, Jun 10, 2019 at 01:25:07PM +0200, Paolo Bonzini wrote: > On 10/06/19 10:23, Florescu, Andreea wrote: > > I prefer having two approvals either from code owners or gatekeepers > > when there are no code owners. Merging a PR with only one review > > should be an exception from my point of view. More often than not 2 > > different people looking at the code will find different bugs or > > other issues (lack of tests, documentation, others?). > > > > GitHub allows administrators to merge PRs even though there are not 2 > > reviews, so we can merge PRs with one review if needed, but I think > > we should have 2 reviewers as the rule. > > My fear is that the second review will, more often than not, be a > "drive-by" review where X gave a positive review so Y just clicks > approve and merge---especially if the second review has to be from a > gatekeeper that may not be that much in touch with the code. > > So I have no particular qualms with requiring two reviews, but I'd > rather not require a separate gatekeeper "super-review" and instead > allow 2 code owner reviews when there are 2 code owners. That sounds reasonable to me. 2 code owners reviews when there are at least 2 of them, otherwise 1+1 or 0+2. It's also good to have gate keepers to be able to help with the review if for some reason one of the code owners is MIA. Cheers, Samuel. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From zachr at google.com Wed Jun 12 15:09:21 2019 From: zachr at google.com (Zach Reizner) Date: Wed, 12 Jun 2019 08:09:21 -0700 Subject: [Rust-VMM] Project gate keeping In-Reply-To: <20190607082308.GA17640@caravaggio> References: <20190607082308.GA17640@caravaggio> Message-ID: On Fri, Jun 7, 2019 at 1:24 AM Samuel Ortiz wrote: > All, > > As discussed during last week's call, I'd like to propose a light > process for PR reviews and gate keeping. > > At the moment, when a PR lands in any of the existing crates, no one > gets assigned to review it and we're asking for 2 review approvals > before merging it. Those approvals should come from members of the > crate's "team", and we need to arbitrarily build those teams on the > fly based on the crate activity and contributions. > > As the number of incoming PRs is increasing, I feel we're starting to > see some limitations with the above described model. While many PRs get > actively reviewed, others slightly less. Also, pinging people for > reviews and approvals is handled manually at the moment. > > In order to improve that situation, here is my proposal: > > - Have a team of 8-10 rust-vmm gatekeepers. 2 randomly selected > gatekeepers will be automatically assigned to any incoming PR. > - Any gate keeper is free to assign someone else from the gate keeper > team if she/he does not have the badwidth/knowledge to review the PR. > - Encourage CODEOWNERS[1] file additions. Not all repos may need such > ownership so I don't think this should be mandatory. > - Any PR will be mergeable when any of the below conditions are met: > * When a repo has a CODEOWNERS file, 1 code owner and 1 gate keeper > approved it. > * On CODEOWNERS-less repos, 2 gate keepers approved it. > - Initial PRs for empty crates could be handled differently and > informally require more approvals from different people. > > I guess the natural question coming next is who should be part of this > gate keeper team. rust-vmm being almost 6 months old, I think we now > have a good idea of who are the most active contributors to the > project. And I think it's logical to build this initial gate keepers > team from those initial active contributors: > > Andreea Florescu @andreeaflorescu > Alexandru Agache @alexandruag > Alexandra Iordache @aghecenco > Jiang Liu @jiangliu > Paolo Bonzini @bonzini > Zach Reizner @zachreizner > Jenny Mankin @jennymankin > Sebastien Boeuf @sboeuf > Rob Bradford @rbradford > Samuel Ortiz @sameo > I agree to serve as a gatekeeper and the overall plan sounds good. Thanks. > > Comments, disagreements, additions, etc are all very welcome. > > Cheers, > Samuel. > > [1] https://help.github.com/en/articles/about-code-owners > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at openstack.org Wed Jun 19 18:05:51 2019 From: james at openstack.org (James Cole) Date: Wed, 19 Jun 2019 11:05:51 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: Hi everyone, Thanks again for all your feedback on the last round of logo ideas. As someone in a non-technical role, your expert perspectives have been really helpful when designing. Before going too far down any rabbit trails, I wanted to update you on some logo progress. After our last email exchange, I decided to scrap a majority of my concepts because some were too similar to Ubuntu’s mark and others were a little too generic. While the epicyclic gear idea generally seemed to have the most potential, gear icons have come to represent very unspecific things like system settings or unrelated things like bicycle shops and manufacturing. A gear might also introduce confusion between Rust-VMM and the Rust programming language, which uses an R inside a gear as its primary symbol. It seemed like a worthwhile exercise to try something different. One problem with any iconographic representation of this project is that the functionality is too complex to distill into a simple visual symbol. I emailed Andreea Florescu for some advice and further explanation about the project, and she suggested thinking about Rust-VMM as a sort of collection of puzzle pieces. After a lot of iterations, I came up with an R icon that is constructed from puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the functionality of the project to make conceptual sense. I’ve mocked it up in a few different ways to show how it could live on a shirt, sticker, and as a GitHub avatar. I would love to get your feedback on idea in the attached PDF and if you think something like this could work. The PDF is also available online here. Please let me know your thoughts. Thank you! James Cole Graphic Designer OpenStack Foundation > On Mar 19, 2019, at 4:29 PM, James Cole wrote: > > Greetings Rust-VMM Team, > > > My name is James Cole and I’m a Graphic Designer with the OpenStack Foundation. We’ve been working on some logo concepts for Rust-VMM and wanted to share them with you. I’ve attached a PDF to this message, or you can view the document online here . > > From your earlier brainstorm, it looked like a popular visual concept centered around the use of an epicyclic gear to illustrate the idea of systems within a system. Page 1 of the PDF shows a few examples of epicyclic gears from around the web and Page 2 shows a simplified epicyclic gear we created in a triangular configuration. > > Page 3 shows some of the more illustratively complex ideas for icons, although you’ll noticed detail can get lost at small sizes. Page 4 shows some additional variations and configurations of the triangular epicyclic gear idea. > > Pages 5 and 6 are mostly there to show how some of the icons can work beside the name, although we haven’t really dug into typography yet. > > I’d love to get your thoughts on this stuff and see if you’d be interested in pursuing any of these ideas further. I’ll be checking this thread for your feedback over the next few days before making changes or exploring more colors and typography. > > Thanks! Looking forward to hearing what you think! > > > James Cole > Graphic Designer > OpenStack Foundation > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Rust-VMM_LogoConcepts_R2.pdf Type: application/pdf Size: 1613137 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From pbonzini at redhat.com Wed Jun 19 22:23:11 2019 From: pbonzini at redhat.com (Paolo Bonzini) Date: Thu, 20 Jun 2019 00:23:11 +0200 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: On 19/06/19 20:05, James Cole wrote: > > After our last email exchange, I decided to scrap a majority of my > concepts because some were too similar to Ubuntu’s mark and others were > a little too generic. While the epicyclic gear idea generally seemed to > have the most potential, gear icons have come to represent very > unspecific things like system settings or unrelated things like bicycle > shops and manufacturing. A gear might also introduce confusion between > Rust-VMM and the Rust programming language, which uses an R inside a > gear as its primary symbol. It seemed like a worthwhile exercise to try > something different.  > > One problem with any iconographic representation of this project is that > the functionality is too complex to distill into a simple visual symbol. > I emailed Andreea Florescu for some advice and further explanation about > the project, and she suggested thinking about Rust-VMM as a sort of > collection of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed > from puzzle pieces. It is simple, easily recognizable, and doesn’t > depend on the functionality of the project to make conceptual sense. > I’ve mocked it up in a few different ways to show how it could live on a > shirt, sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you > think something like this could work. The PDF is also available online > here. >  Please > let me know your thoughts. > I like it. :) Paolo From raduweis at amazon.com Thu Jun 20 00:43:47 2019 From: raduweis at amazon.com (Weiss, Radu) Date: Thu, 20 Jun 2019 00:43:47 +0000 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: I’m personally on the sidelines, but I do like the logo & color scheme 😊. +1 From: Paolo Bonzini Date: 2019-06-20 [Q2] [W25] [Thursday] at 00:25:18 To: James Cole , "rust-vmm at lists.opendev.org" Subject: Re: [Rust-VMM] Rust-VMM Logo Concepts On 19/06/19 20:05, James Cole wrote: After our last email exchange, I decided to scrap a majority of my concepts because some were too similar to Ubuntu’s mark and others were a little too generic. While the epicyclic gear idea generally seemed to have the most potential, gear icons have come to represent very unspecific things like system settings or unrelated things like bicycle shops and manufacturing. A gear might also introduce confusion between Rust-VMM and the Rust programming language, which uses an R inside a gear as its primary symbol. It seemed like a worthwhile exercise to try something different. One problem with any iconographic representation of this project is that the functionality is too complex to distill into a simple visual symbol. I emailed Andreea Florescu for some advice and further explanation about the project, and she suggested thinking about Rust-VMM as a sort of collection of puzzle pieces. After a lot of iterations, I came up with an R icon that is constructed from puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the functionality of the project to make conceptual sense. I’ve mocked it up in a few different ways to show how it could live on a shirt, sticker, and as a GitHub avatar. I would love to get your feedback on idea in the attached PDF and if you think something like this could work. The PDF is also available online here. Please let me know your thoughts. I like it. :) Paolo _______________________________________________ Rust-vmm mailing list Rust-vmm at lists.opendev.org http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: From xu at hyper.sh Thu Jun 20 03:10:18 2019 From: xu at hyper.sh (Xu Wang) Date: Thu, 20 Jun 2019 11:10:18 +0800 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: Looks cool, like it. On Thu, Jun 20, 2019 at 2:08 AM James Cole wrote: > Hi everyone, > > Thanks again for all your feedback on the last round of logo ideas. As > someone in a non-technical role, your expert perspectives have been really > helpful when designing. Before going too far down any rabbit trails, I > wanted to update you on some logo progress. > > After our last email exchange, I decided to scrap a majority of my > concepts because some were too similar to Ubuntu’s mark and others were a > little too generic. While the epicyclic gear idea generally seemed to have > the most potential, gear icons have come to represent very unspecific > things like system settings or unrelated things like bicycle shops and > manufacturing. A gear might also introduce confusion between Rust-VMM and > the Rust programming language, which uses an R inside a gear as its primary > symbol. It seemed like a worthwhile exercise to try something different. > > One problem with any iconographic representation of this project is that > the functionality is too complex to distill into a simple visual symbol. I > emailed Andreea Florescu for some advice and further explanation about the > project, and she suggested thinking about Rust-VMM as a sort of collection > of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed > from puzzle pieces. It is simple, easily recognizable, and doesn’t depend > on the functionality of the project to make conceptual sense. I’ve mocked > it up in a few different ways to show how it could live on a shirt, > sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you > think something like this could work. The PDF is also available online > here. > Please > let me know your thoughts. > > Thank you! > > *James Cole* > Graphic Designer > OpenStack Foundation > > > On Mar 19, 2019, at 4:29 PM, James Cole wrote: > > Greetings Rust-VMM Team, > > > My name is James Cole and I’m a Graphic Designer with the OpenStack > Foundation. We’ve been working on some logo concepts for Rust-VMM and > wanted to share them with you. I’ve attached a PDF to this message, or you > can view the document online here > > . > > From your earlier brainstorm, it looked like a popular visual concept > centered around the use of an epicyclic gear to illustrate the idea of > systems within a system. Page 1 of the PDF shows a few examples of > epicyclic gears from around the web and Page 2 shows a simplified epicyclic > gear we created in a triangular configuration. > > Page 3 shows some of the more illustratively complex ideas for icons, > although you’ll noticed detail can get lost at small sizes. Page 4 shows > some additional variations and configurations of the triangular epicyclic > gear idea. > > Pages 5 and 6 are mostly there to show how some of the icons can work > beside the name, although we haven’t really dug into typography yet. > > I’d love to get your thoughts on this stuff and see if you’d be interested > in pursuing any of these ideas further. I’ll be checking this thread for > your feedback over the next few days before making changes or exploring > more colors and typography. > > Thanks! Looking forward to hearing what you think! > > > *James Cole* > Graphic Designer > OpenStack Foundation > > > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > -- Xu Wang Senior Staff Engineer at AntFin A member of Kata Containers project github/twitter/wechat: @gnawux -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Thu Jun 20 04:23:10 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Thu, 20 Jun 2019 06:23:10 +0200 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: <20190620042310.GD32210@caravaggio> On Wed, Jun 19, 2019 at 08:05:51PM +0200, James Cole wrote: > After a lot of iterations, I came up with an R icon that is constructed from > puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the > functionality of the project to make conceptual sense. I’ve mocked it up in a > few different ways to show how it could live on a shirt, sticker, and as a > GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you think > something like this could work. The PDF is also available online here. Please > let me know your thoughts. I personally love it, thanks a lot! Cheers, Samuel. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From liuj97 at gmail.com Thu Jun 20 04:33:14 2019 From: liuj97 at gmail.com (Liu Jiang) Date: Thu, 20 Jun 2019 12:33:14 +0800 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <20190620042310.GD32210@caravaggio> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190620042310.GD32210@caravaggio> Message-ID: <5EF032A9-B4CC-49E7-9DE2-A9EAA0F0E547@gmail.com> +1 > On Jun 20, 2019, at 12:23 PM, Samuel Ortiz wrote: > > On Wed, Jun 19, 2019 at 08:05:51PM +0200, James Cole wrote: >> After a lot of iterations, I came up with an R icon that is constructed from >> puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the >> functionality of the project to make conceptual sense. I’ve mocked it up in a >> few different ways to show how it could live on a shirt, sticker, and as a >> GitHub avatar. >> >> I would love to get your feedback on idea in the attached PDF and if you think >> something like this could work. The PDF is also available online here. Please >> let me know your thoughts. > I personally love it, thanks a lot! > > Cheers, > Samuel. > --------------------------------------------------------------------- > Intel Corporation SAS (French simplified joint stock company) > Registered headquarters: "Les Montalets"- 2, rue de Paris, > 92196 Meudon Cedex, France > Registration Number: 302 456 199 R.C.S. NANTERRE > Capital: 4,572,000 Euros > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From zhipengh512 at gmail.com Thu Jun 20 04:39:24 2019 From: zhipengh512 at gmail.com (Zhipeng Huang) Date: Thu, 20 Jun 2019 12:39:24 +0800 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: <5EF032A9-B4CC-49E7-9DE2-A9EAA0F0E547@gmail.com> References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> <20190620042310.GD32210@caravaggio> <5EF032A9-B4CC-49E7-9DE2-A9EAA0F0E547@gmail.com> Message-ID: looks awesome On Thu, Jun 20, 2019 at 12:36 PM Liu Jiang wrote: > +1 > > > On Jun 20, 2019, at 12:23 PM, Samuel Ortiz > wrote: > > > > On Wed, Jun 19, 2019 at 08:05:51PM +0200, James Cole wrote: > >> After a lot of iterations, I came up with an R icon that is constructed > from > >> puzzle pieces. It is simple, easily recognizable, and doesn’t depend on > the > >> functionality of the project to make conceptual sense. I’ve mocked it > up in a > >> few different ways to show how it could live on a shirt, sticker, and > as a > >> GitHub avatar. > >> > >> I would love to get your feedback on idea in the attached PDF and if > you think > >> something like this could work. The PDF is also available online here. > Please > >> let me know your thoughts. > > I personally love it, thanks a lot! > > > > Cheers, > > Samuel. > > --------------------------------------------------------------------- > > Intel Corporation SAS (French simplified joint stock company) > > Registered headquarters: "Les Montalets"- 2, rue de Paris, > > 92196 Meudon Cedex, France > > Registration Number: 302 456 199 R.C.S. NANTERRE > > Capital: 4,572,000 Euros > > > > This e-mail and any attachments may contain confidential material for > > the sole use of the intended recipient(s). Any review or distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > _______________________________________________ > > Rust-vmm mailing list > > Rust-vmm at lists.opendev.org > > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > -- Zhipeng (Howard) Huang Principle Engineer OpenStack, Kubernetes, CNCF, LF Edge, ONNX, Kubeflow, OpenSDS, Open Service Broker API, OCP, Hyperledger, ETSI, SNIA, DMTF, W3C -------------- next part -------------- An HTML attachment was scrubbed... URL: From yi.y.sun at linux.intel.com Thu Jun 20 05:29:31 2019 From: yi.y.sun at linux.intel.com (Yi Sun) Date: Thu, 20 Jun 2019 13:29:31 +0800 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: <20190620052931.GA18465@yi.y.sun> So cool! I love it. On 19-06-19 11:05:51, James Cole wrote: > Hi everyone, > > Thanks again for all your feedback on the last round of logo ideas. As someone in a non-technical role, your expert perspectives have been really helpful when designing. Before going too far down any rabbit trails, I wanted to update you on some logo progress. > > After our last email exchange, I decided to scrap a majority of my concepts because some were too similar to Ubuntu’s mark and others were a little too generic. While the epicyclic gear idea generally seemed to have the most potential, gear icons have come to represent very unspecific things like system settings or unrelated things like bicycle shops and manufacturing. A gear might also introduce confusion between Rust-VMM and the Rust programming language, which uses an R inside a gear as its primary symbol. It seemed like a worthwhile exercise to try something different. > > One problem with any iconographic representation of this project is that the functionality is too complex to distill into a simple visual symbol. I emailed Andreea Florescu for some advice and further explanation about the project, and she suggested thinking about Rust-VMM as a sort of collection of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed from puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the functionality of the project to make conceptual sense. I’ve mocked it up in a few different ways to show how it could live on a shirt, sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you think something like this could work. The PDF is also available online here. Please let me know your thoughts. > > Thank you! > > James Cole > Graphic Designer > OpenStack Foundation > > > > > On Mar 19, 2019, at 4:29 PM, James Cole wrote: > > > > Greetings Rust-VMM Team, > > > > > > My name is James Cole and I’m a Graphic Designer with the OpenStack Foundation. We’ve been working on some logo concepts for Rust-VMM and wanted to share them with you. I’ve attached a PDF to this message, or you can view the document online here . > > > > From your earlier brainstorm, it looked like a popular visual concept centered around the use of an epicyclic gear to illustrate the idea of systems within a system. Page 1 of the PDF shows a few examples of epicyclic gears from around the web and Page 2 shows a simplified epicyclic gear we created in a triangular configuration. > > > > Page 3 shows some of the more illustratively complex ideas for icons, although you’ll noticed detail can get lost at small sizes. Page 4 shows some additional variations and configurations of the triangular epicyclic gear idea. > > > > Pages 5 and 6 are mostly there to show how some of the icons can work beside the name, although we haven’t really dug into typography yet. > > > > I’d love to get your thoughts on this stuff and see if you’d be interested in pursuing any of these ideas further. I’ll be checking this thread for your feedback over the next few days before making changes or exploring more colors and typography. > > > > Thanks! Looking forward to hearing what you think! > > > > > > James Cole > > Graphic Designer > > OpenStack Foundation > > > > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm From cdupontd at redhat.com Thu Jun 20 08:58:40 2019 From: cdupontd at redhat.com (Christophe de Dinechin) Date: Thu, 20 Jun 2019 10:58:40 +0200 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: <44418F49-F1CE-4626-82D7-8C281031D1D2@redhat.com> > On 19 Jun 2019, at 20:05, James Cole > wrote: > > Hi everyone, > > Thanks again for all your feedback on the last round of logo ideas. As someone in a non-technical role, your expert perspectives have been really helpful when designing. Before going too far down any rabbit trails, I wanted to update you on some logo progress. > > After our last email exchange, I decided to scrap a majority of my concepts because some were too similar to Ubuntu’s mark and others were a little too generic. While the epicyclic gear idea generally seemed to have the most potential, gear icons have come to represent very unspecific things like system settings or unrelated things like bicycle shops and manufacturing. A gear might also introduce confusion between Rust-VMM and the Rust programming language, which uses an R inside a gear as its primary symbol. It seemed like a worthwhile exercise to try something different. > > One problem with any iconographic representation of this project is that the functionality is too complex to distill into a simple visual symbol. I emailed Andreea Florescu for some advice and further explanation about the project, and she suggested thinking about Rust-VMM as a sort of collection of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed from puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the functionality of the project to make conceptual sense. I’ve mocked it up in a few different ways to show how it could live on a shirt, sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you think something like this could work. The PDF is also available online here. Please let me know your thoughts. It looks great. Also, it is fundamentally monochrome, so we could for example use color variations for specific aspects of the project (e.g. for specific crates, etc) Thank you for the great work! Christophe > > Thank you! > > James Cole > Graphic Designer > OpenStack Foundation > > > >> On Mar 19, 2019, at 4:29 PM, James Cole > wrote: >> >> Greetings Rust-VMM Team, >> >> >> My name is James Cole and I’m a Graphic Designer with the OpenStack Foundation. We’ve been working on some logo concepts for Rust-VMM and wanted to share them with you. I’ve attached a PDF to this message, or you can view the document online here. >> >> From your earlier brainstorm, it looked like a popular visual concept centered around the use of an epicyclic gear to illustrate the idea of systems within a system. Page 1 of the PDF shows a few examples of epicyclic gears from around the web and Page 2 shows a simplified epicyclic gear we created in a triangular configuration. >> >> Page 3 shows some of the more illustratively complex ideas for icons, although you’ll noticed detail can get lost at small sizes. Page 4 shows some additional variations and configurations of the triangular epicyclic gear idea. >> >> Pages 5 and 6 are mostly there to show how some of the icons can work beside the name, although we haven’t really dug into typography yet. >> >> I’d love to get your thoughts on this stuff and see if you’d be interested in pursuing any of these ideas further. I’ll be checking this thread for your feedback over the next few days before making changes or exploring more colors and typography. >> >> Thanks! Looking forward to hearing what you think! >> >> >> James Cole >> Graphic Designer >> OpenStack Foundation >> >> > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -------------- next part -------------- An HTML attachment was scrubbed... URL: From zachr at google.com Thu Jun 20 16:47:33 2019 From: zachr at google.com (Zach Reizner) Date: Thu, 20 Jun 2019 09:47:33 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: On Wed, Jun 19, 2019 at 11:09 AM James Cole wrote: > Hi everyone, > > Thanks again for all your feedback on the last round of logo ideas. As > someone in a non-technical role, your expert perspectives have been really > helpful when designing. Before going too far down any rabbit trails, I > wanted to update you on some logo progress. > > After our last email exchange, I decided to scrap a majority of my > concepts because some were too similar to Ubuntu’s mark and others were a > little too generic. While the epicyclic gear idea generally seemed to have > the most potential, gear icons have come to represent very unspecific > things like system settings or unrelated things like bicycle shops and > manufacturing. A gear might also introduce confusion between Rust-VMM and > the Rust programming language, which uses an R inside a gear as its primary > symbol. It seemed like a worthwhile exercise to try something different. > > One problem with any iconographic representation of this project is that > the functionality is too complex to distill into a simple visual symbol. I > emailed Andreea Florescu for some advice and further explanation about the > project, and she suggested thinking about Rust-VMM as a sort of collection > of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed > from puzzle pieces. It is simple, easily recognizable, and doesn’t depend > on the functionality of the project to make conceptual sense. I’ve mocked > it up in a few different ways to show how it could live on a shirt, > sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you > think something like this could work. The PDF is also available online > here. > Please > let me know your thoughts. > Looks good to me :) > > Thank you! > > *James Cole* > Graphic Designer > OpenStack Foundation > > > On Mar 19, 2019, at 4:29 PM, James Cole wrote: > > Greetings Rust-VMM Team, > > > My name is James Cole and I’m a Graphic Designer with the OpenStack > Foundation. We’ve been working on some logo concepts for Rust-VMM and > wanted to share them with you. I’ve attached a PDF to this message, or you > can view the document online here > > . > > From your earlier brainstorm, it looked like a popular visual concept > centered around the use of an epicyclic gear to illustrate the idea of > systems within a system. Page 1 of the PDF shows a few examples of > epicyclic gears from around the web and Page 2 shows a simplified epicyclic > gear we created in a triangular configuration. > > Page 3 shows some of the more illustratively complex ideas for icons, > although you’ll noticed detail can get lost at small sizes. Page 4 shows > some additional variations and configurations of the triangular epicyclic > gear idea. > > Pages 5 and 6 are mostly there to show how some of the icons can work > beside the name, although we haven’t really dug into typography yet. > > I’d love to get your thoughts on this stuff and see if you’d be interested > in pursuing any of these ideas further. I’ll be checking this thread for > your feedback over the next few days before making changes or exploring > more colors and typography. > > Thanks! Looking forward to hearing what you think! > > > *James Cole* > Graphic Designer > OpenStack Foundation > > > > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.ortiz at intel.com Mon Jun 24 13:00:34 2019 From: samuel.ortiz at intel.com (Samuel Ortiz) Date: Mon, 24 Jun 2019 15:00:34 +0200 Subject: [Rust-VMM] 2019-06-26 Meeting: Call for Agenda Message-ID: <20190624130034.GA28929@caravaggio> All, The agenda for our next meeting (Wed June 26th) is empty. Please send an email or add an entry to the agenda etherpad [1] if you have something you'd like to discuss. If it is still empty by tomorrow (June 25th) 7am PST, we will cancel the meeting. Cheers, Samuel. [1] https://etherpad.openstack.org/p/rust_vmm_2019_biweekly_calls --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From claire at openstack.org Tue Jun 25 12:55:43 2019 From: claire at openstack.org (claire at openstack.org) Date: Tue, 25 Jun 2019 12:55:43 +0000 Subject: [Rust-VMM] Updated invitation: Rust-VMM Bi-Weekly Community Mtg @ Every 2 weeks from 10am to 11am on Wednesday from Wed Feb 6 to Wed Dec 18 except Wed Jun 26 10am (CST) (rust-vmm@lists.opendev.org) Message-ID: <000000000000540acb058c257208@google.com> This event has been changed. Title: Rust-VMM Bi-Weekly Community Mtg Notes / Agenda: https://etherpad.openstack.org/p/rust_vmm_2019_biweekly_calls Join Zoom Meeting https://zoom.us/j/181523033 One tap mobile +16699006833,,181523033# US (San Jose) +16468769923,,181523033# US (New York) Dial by your location +1 669 900 6833 US (San Jose) +1 646 876 9923 US (New York) Meeting ID: 181 523 033 Find your local number: https://zoom.us/u/abOe7d3zx9 When: Every 2 weeks from 10am to 11am on Wednesday from Wed Feb 6 to Wed Dec 18 except Wed Jun 26 10am Central Time - Chicago (changed) Calendar: rust-vmm at lists.opendev.org Who: * claire at openstack.org - organizer * rust-vmm at lists.opendev.org Event details: https://www.google.com/calendar/event?action=VIEW&eid=Xzg5MTNhYzlqOHAxazJiOWs2c3EzNGI5azhrcGplYjlvOGNxajhiOWg2bDM0OGNhMzhkMGpnaDlrNnMgcnVzdC12bW1AbGlzdHMub3BlbmRldi5vcmc&tok=MjAjY2xhaXJlQG9wZW5zdGFjay5vcmcwMzNmZjVkY2Y1ZjRkMTM3NjVjNzQzODRlZDZjNzM5YTU2YjE3MDI1&ctz=America%2FChicago&hl=en&es=0 Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account rust-vmm at lists.opendev.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/calendar Size: 2596 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: invite.ics Type: application/ics Size: 2664 bytes Desc: not available URL: From james at openstack.org Wed Jun 26 17:11:25 2019 From: james at openstack.org (James Cole) Date: Wed, 26 Jun 2019 10:11:25 -0700 Subject: [Rust-VMM] Rust-VMM Logo Concepts In-Reply-To: References: <833B249E-F8C0-41BA-AC04-1CFEC93C844F@openstack.org> Message-ID: <9246F076-5CDB-4B3F-B2ED-22D7A1A31144@openstack.org> Hi again everyone, It looks like a lot of you like the logo idea—awesome! This was a challenging one, so I’m glad the concept seems to make sense. I’ve uploaded the files to Dropbox in a number of formats for both web and print. Anyone should be able to access the folder, but feel free to download them and store them somewhere more publicly accessible. Logo Files: https://www.dropbox.com/sh/oo0fm6wqy5sov8x/AABzZHNdIfDXlACVFNXzLQXQa?dl=0 Thank you everyone for your thoughts and feedback throughout the process! I had fun working on this one. Thanks! James Cole Graphic Designer OpenStack Foundation > On Jun 19, 2019, at 11:05 AM, James Cole wrote: > > Hi everyone, > > Thanks again for all your feedback on the last round of logo ideas. As someone in a non-technical role, your expert perspectives have been really helpful when designing. Before going too far down any rabbit trails, I wanted to update you on some logo progress. > > After our last email exchange, I decided to scrap a majority of my concepts because some were too similar to Ubuntu’s mark and others were a little too generic. While the epicyclic gear idea generally seemed to have the most potential, gear icons have come to represent very unspecific things like system settings or unrelated things like bicycle shops and manufacturing. A gear might also introduce confusion between Rust-VMM and the Rust programming language, which uses an R inside a gear as its primary symbol. It seemed like a worthwhile exercise to try something different. > > One problem with any iconographic representation of this project is that the functionality is too complex to distill into a simple visual symbol. I emailed Andreea Florescu for some advice and further explanation about the project, and she suggested thinking about Rust-VMM as a sort of collection of puzzle pieces. > > After a lot of iterations, I came up with an R icon that is constructed from puzzle pieces. It is simple, easily recognizable, and doesn’t depend on the functionality of the project to make conceptual sense. I’ve mocked it up in a few different ways to show how it could live on a shirt, sticker, and as a GitHub avatar. > > I would love to get your feedback on idea in the attached PDF and if you think something like this could work. The PDF is also available online here. Please let me know your thoughts. > > Thank you! > > James Cole > Graphic Designer > OpenStack Foundation > > > >> On Mar 19, 2019, at 4:29 PM, James Cole > wrote: >> >> Greetings Rust-VMM Team, >> >> >> My name is James Cole and I’m a Graphic Designer with the OpenStack Foundation. We’ve been working on some logo concepts for Rust-VMM and wanted to share them with you. I’ve attached a PDF to this message, or you can view the document online here . >> >> From your earlier brainstorm, it looked like a popular visual concept centered around the use of an epicyclic gear to illustrate the idea of systems within a system. Page 1 of the PDF shows a few examples of epicyclic gears from around the web and Page 2 shows a simplified epicyclic gear we created in a triangular configuration. >> >> Page 3 shows some of the more illustratively complex ideas for icons, although you’ll noticed detail can get lost at small sizes. Page 4 shows some additional variations and configurations of the triangular epicyclic gear idea. >> >> Pages 5 and 6 are mostly there to show how some of the icons can work beside the name, although we haven’t really dug into typography yet. >> >> I’d love to get your thoughts on this stuff and see if you’d be interested in pursuing any of these ideas further. I’ll be checking this thread for your feedback over the next few days before making changes or exploring more colors and typography. >> >> Thanks! Looking forward to hearing what you think! >> >> >> James Cole >> Graphic Designer >> OpenStack Foundation >> >> > > _______________________________________________ > Rust-vmm mailing list > Rust-vmm at lists.opendev.org > http://lists.opendev.org/cgi-bin/mailman/listinfo/rust-vmm -------------- next part -------------- An HTML attachment was scrubbed... URL: From fandree at amazon.com Thu Jun 27 11:25:22 2019 From: fandree at amazon.com (Florescu, Andreea) Date: Thu, 27 Jun 2019 11:25:22 +0000 Subject: [Rust-VMM] Next rust-vmm meet-up In-Reply-To: <1558963516923.22009@amazon.com> References: <1558963516923.22009@amazon.com> Message-ID: <1561634721561.11725@amazon.com> Hey everyone, Just a reminder to respond to the doodle regarding the date of the next meet-up. I will send an update with the result by tomorrow EOD. Regards, Andreea ________________________________ From: Florescu, Andreea Sent: Monday, May 27, 2019 4:25 PM To: rust-vmm ML Subject: Next rust-vmm meet-up Hey everyone, About a month ago a few of us met during PTG [1] where we discussed about the design of various rust-vmm components, testing as well as some community topics. You can check the full meeting notes in the email thread [2]. While we were there we also talked about setting up another meetup this year. One apparently popular option was to locate this event in Bucharest, during the autumn. Therefore, on behalf of the local AWS Dev Center, I am happy to extend an invitation to all of you, for a 3 days hacking session. AWS will provide the workspace for all attendees (either in or around our offices). My personal preference would be to have a meetup more focused on the coding. Ideally we would get together and write some code for new components, review the code, discuss about designing crates and similar activities. I am open to other suggestions as well, but I think we could benefit from a more hands-on session. Can you please take 1 minute to complete the form [3] so we can get a rough idea of how many people are able to join and also come up with a week when most of us can attend? We can settled on the actual dates once we know roughly what week is the best option for everyone. [1] https://www.openstack.org/ptg/ [2] http://lists.opendev.org/pipermail/rust-vmm/2019-May/000200.html [3] https://docs.google.com/forms/d/1rw89Bdigh7QxHXY3vvucemrA5oNOmFC59F4DBtqMLEA Amazon Development Center (Romania) S.R.L. registered office: 27A Sf. Lazar Street, UBC5, floor 2, Iasi, Iasi County, 700045, Romania. Registered in Romania. Registration number J22/2621/2005. -------------- next part -------------- An HTML attachment was scrubbed... URL: