Interview with Thierry Carres, Chairman of the OpenStack Technical Committee and Release Manager
We present the fourth of a series of interviews with the technical leaders of the OpenStack project in the Mirantis blog. Our goal is to educate the wider technical community and help people understand how they can contribute to and benefit from the OpenStack project. Naturally, below is the point of view of the interviewee, not of Mirantis.
Below we present an interview with Thierry Carrez, Chairman of the OpenStack Technical Committee and Release Manager.
Mirantis: Tell us about yourself.
')
Thierry Carres: Of course! I turned 40 this year. I live with my wife and two children in a small village in the center of France.
Q: Very nice. Do you notice cultural differences among developers from different parts of the world?
A: Yes, these differences are striking, and one of the tasks of the global community is to form a single entity that overcomes them. In addition, there are differences derived from a variety of professional experience, so it’s not just geography.
Q: Can you give an example? In Eastern Europe, for example, code reviews are perceived as criticism or disapproval - although in reality such reviews are designed to help developers improve the code.
A: There are also problems with the perception of “-1 ″ code evaluation in Japan, for example. Also, developers who come from large companies are afraid to see their name, clearly and permanently indicated, next to the change in the code. This keeps them from fully participating in the developer community. For those developers who started in open source projects or in startups, transparency is not a problem, but an opportunity.
Q: What is your history of working with OpenStack? Why are you interested in participating in the project?
A: I was the technical manager of the Ubuntu Server project at Canonical and worked on the Ubuntu Enterprise Cloud product. When creating OpenStack, I, along with several colleagues from Rackspace, helped organize the project and performed release management functions.
I am particularly interested in promoting a “open innovation” development model: creating a level technical working environment that allows developers across the industry to work together on the design and development of OpenStack. My goal in the project is to make sure that we adhere to this model, contribute to its support and development and prove its success.
Q: How do companies adopt an open innovation model?
A: When working on the principle of open innovation, companies hire developers to work on the project, but do not control the project itself. They direct the priorities and interests of the developers within the project, implicitly, as intermediaries. But, in general, all project participants and leaders among them control the process themselves. Companies are forced to accept a situation in which they must relinquish control in favor of influence.
Q: Many companies use OpenStack, but do not share experiences. Does it need to change? If so, how? Or is it a common practice in an open source project?
A: The Apache license allows companies to take code and not contribute, so this is definitely common practice. However, this is not a good idea. Without investing in a project, you significantly reduce your impact on the technical side. You also run the risk that a new code and additional features violate your recipe for working code. In the end, it's not worth it.
Q: Who determines the principle of building OpenStack - how are decisions made?
A: Our function development process is extremely open. Anyone can suggest a change that is sent to our main staff reviewers for reviewing the code. Considering what has been said (especially for the destructive functions), you increase your chances for a successful test if you have joined the design and development mailing list and participate in our development workshops. Thus, a community can approve a function before it takes too much effort. The decision-making process is a compromise achieved with minimal effort between the developers in the project. For each project we have an elected technical project manager who can make the final decision, but this is required in very rare cases.
Q: What is your responsibility as a technical committee chairman and release manager?
A: The technical committee is the final expression of technical meritocracy in OpenStack. Committee members are elected by members of various projects. His role is to consider new projects that are proposed for development in OpenStack, and solve potential inter-project problems. As chairman of the committee, I am responsible for following up issues submitted by the committee, launching IRC meetings and distributing the results of these meetings to the rest of the community.
Release management has two aspects. The first one (obviously) is to coordinate the releases of various OpenStack projects, but with the automation tools we have, this is very simple. Most of the release management work is managing the six-month release cycles, tracking what is being done, and trying to prevent inter-project interference.
Q: Often people interested in OpenStack comment on the use of IRC. “Why do you use IRC? This has long been outdated. Why don't you use Twitter like everyone else? ”
A: Hmm. Not everyone wants to be tied to a proprietary messaging platform! I have been using IRC for the last 20 years and I think this is the perfect tool for quick online discussions and meeting organization. We have channels dedicated to individual topics and channels of individual teams. This is a public space for communication, it works around the clock. We keep a log of actions, that is, the data does not disappear. We can also use a proxy to connect. This is very common among developers who participate in our open source projects, and most of us use them outside of OpenStack.
Q: You mentioned the six-month release cycles. What is their value?
A: The most obvious value of release cycles is to help release a release. This helps us to move the focus from the development of functions to the critical bug fixes release. This improves the quality of the release. For me, the greatest value of the release cycles is the creation of a rhythm of effort, a specific pulse, which is very important for our virtual and global community in terms of uniting in work on the same project.
Q: Can you describe the release cycle of OpenStack, from brainstorming to implementation and integration?
A: We start with the Design Workshop, where developers who want to work on a specific project during the next cycle, present their ideas and discuss them with other developers. Then begins the implementation, which is artificially divided into three brief “stages” to break the work on the project.
After the third stage of development, we switch to the function freezing mode, in which the focus shifts to correcting the list of critical errors before release. After all critical errors are fixed, we create a release candidate. If no critical bugs are found in the release (in this case, we can fix them and rebuild the new release candidate), all candidates are collected at the time of release to create the final integrated release of OpenStack projects.
Q: What determines the frequency of OpenStack releases?
A: We are trying to have the main branch always available for launch. “Releases” are really just points in time, tags in the repository, which we mark as special cases. Our release cycle is designed to reduce the risk that a critical regression will penetrate our “releases”, so “releases” carry less risk than random basic code fixation. What follows is interesting: we maintain stable branches, where we apply patches to critical bug fixes and vulnerability fixes, and these stable branches are created from release points.
The current release frequency of OpenStack releases is a compromise between our desire to speed up iterations, the ability to hold developer workshops, the need to update documentation after freezing functions, frequency of freezing functions and the availability of resources to support stable branches.
Q: What are the advantages and disadvantages of a three-month release cycle?
A: You can remember that at the beginning of the development of OpenStack, we had a three-month development cycle. Now it usually takes 4 weeks from the moment you stop adding features until you get a working release candidate. With a six-month release cycle, it is possible to freeze functions for a month. In the three-month release cycle, this period is less. Releasing every three months means maintaining twice the number of stable branches. Thus, if more people fix critical errors during the remaining cycle period (not during the function freeze period) and more people help maintain stable branches and security updates, we can definitely move on to the three-month cycle. I like to hold a Developer Workshop at the beginning of each cycle (I think it helps us achieve better results), so I suppose we will have to convince the Foundation to pay twice as much for developers!
Q: How can developers take part if they are forced to miss a workshop or cannot afford a trip to a developers workshop?
A: Participation in the Developer Workshop is by no means a necessary condition for adding code to OpenStack. Discussion can be conducted on mailing lists or in the code verification system. The Developer Workshop is a convenient way to quickly go through the brainstorming and implementation stages, getting early reviews in lively personal discussions.
Q: Is the OpenStack community thinking about following the path of the Ubuntu community with a “online only” developer workshop? Does this work for OpenStack?
A: Ubuntu developer workshops have basically become a feedback gathering exercise where major developers present their work plan for the next few months. For these purposes, the virtual environment is ideal and saves a lot of money. OpenStack developer workshops are used for something else: motivating the global and virtual developer community for the next six months, brainstorming ideas for development, or reducing duplication of effort by communicating with various groups of developers. But the most important reason to keep the participants in private communication is to maintain common sense in the community. Personal meetings are necessary in order to resolve any conflicts that have accumulated over 6 months of virtual communication.
Q: We recently interviewed Monty Taylor , technical project manager for continuous integration. What do you think continuous integration is so important for OpenStack?
A: Continuous integration allows us to trust that the content of the main branch works and does not contain regression. OpenStack is a complex device and you can accidentally break it. I used to deploy a release locally and periodically run several manual tests to make sure that the basic functionality is not broken.
Today’s infrastructure runs thousands of times more tests than I ran before, and so on for every proposed change. Continuous integration allows me to sleep well. Without it, we would not be where we are now.
Q: Are there any areas of the development process that are not yet automated, but will be automated in the future?
A: No, all aspects are automated, although there is room for improvement. Some projects could use more integration tests; your continuous integration is only as good as your tests.
Q: What should developers who want to be involved in writing code for OpenStack bring to the project?
A: Sense of humor. The developers of OpenStack are a community of nice people and we would like it to be like this forever!
Q: What advice would you give to newbies - those developers who want to contribute, and companies that want to build a business around OpenStack?
A: The OpenStack project is what we make of it. Join us, you will not regret!
Q: Thank you, Thierry!
A: Thank you!
Below we present an interview with Thierry Carrez, Chairman of the OpenStack Technical Committee and Release Manager.
Mirantis: Tell us about yourself.
')
Thierry Carres: Of course! I turned 40 this year. I live with my wife and two children in a small village in the center of France.
Q: Very nice. Do you notice cultural differences among developers from different parts of the world?
A: Yes, these differences are striking, and one of the tasks of the global community is to form a single entity that overcomes them. In addition, there are differences derived from a variety of professional experience, so it’s not just geography.
Q: Can you give an example? In Eastern Europe, for example, code reviews are perceived as criticism or disapproval - although in reality such reviews are designed to help developers improve the code.
A: There are also problems with the perception of “-1 ″ code evaluation in Japan, for example. Also, developers who come from large companies are afraid to see their name, clearly and permanently indicated, next to the change in the code. This keeps them from fully participating in the developer community. For those developers who started in open source projects or in startups, transparency is not a problem, but an opportunity.
Q: What is your history of working with OpenStack? Why are you interested in participating in the project?
A: I was the technical manager of the Ubuntu Server project at Canonical and worked on the Ubuntu Enterprise Cloud product. When creating OpenStack, I, along with several colleagues from Rackspace, helped organize the project and performed release management functions.
I am particularly interested in promoting a “open innovation” development model: creating a level technical working environment that allows developers across the industry to work together on the design and development of OpenStack. My goal in the project is to make sure that we adhere to this model, contribute to its support and development and prove its success.
Q: How do companies adopt an open innovation model?
A: When working on the principle of open innovation, companies hire developers to work on the project, but do not control the project itself. They direct the priorities and interests of the developers within the project, implicitly, as intermediaries. But, in general, all project participants and leaders among them control the process themselves. Companies are forced to accept a situation in which they must relinquish control in favor of influence.
Q: Many companies use OpenStack, but do not share experiences. Does it need to change? If so, how? Or is it a common practice in an open source project?
A: The Apache license allows companies to take code and not contribute, so this is definitely common practice. However, this is not a good idea. Without investing in a project, you significantly reduce your impact on the technical side. You also run the risk that a new code and additional features violate your recipe for working code. In the end, it's not worth it.
Q: Who determines the principle of building OpenStack - how are decisions made?
A: Our function development process is extremely open. Anyone can suggest a change that is sent to our main staff reviewers for reviewing the code. Considering what has been said (especially for the destructive functions), you increase your chances for a successful test if you have joined the design and development mailing list and participate in our development workshops. Thus, a community can approve a function before it takes too much effort. The decision-making process is a compromise achieved with minimal effort between the developers in the project. For each project we have an elected technical project manager who can make the final decision, but this is required in very rare cases.
Q: What is your responsibility as a technical committee chairman and release manager?
A: The technical committee is the final expression of technical meritocracy in OpenStack. Committee members are elected by members of various projects. His role is to consider new projects that are proposed for development in OpenStack, and solve potential inter-project problems. As chairman of the committee, I am responsible for following up issues submitted by the committee, launching IRC meetings and distributing the results of these meetings to the rest of the community.
Release management has two aspects. The first one (obviously) is to coordinate the releases of various OpenStack projects, but with the automation tools we have, this is very simple. Most of the release management work is managing the six-month release cycles, tracking what is being done, and trying to prevent inter-project interference.
Q: Often people interested in OpenStack comment on the use of IRC. “Why do you use IRC? This has long been outdated. Why don't you use Twitter like everyone else? ”
A: Hmm. Not everyone wants to be tied to a proprietary messaging platform! I have been using IRC for the last 20 years and I think this is the perfect tool for quick online discussions and meeting organization. We have channels dedicated to individual topics and channels of individual teams. This is a public space for communication, it works around the clock. We keep a log of actions, that is, the data does not disappear. We can also use a proxy to connect. This is very common among developers who participate in our open source projects, and most of us use them outside of OpenStack.
Q: You mentioned the six-month release cycles. What is their value?
A: The most obvious value of release cycles is to help release a release. This helps us to move the focus from the development of functions to the critical bug fixes release. This improves the quality of the release. For me, the greatest value of the release cycles is the creation of a rhythm of effort, a specific pulse, which is very important for our virtual and global community in terms of uniting in work on the same project.
Q: Can you describe the release cycle of OpenStack, from brainstorming to implementation and integration?
A: We start with the Design Workshop, where developers who want to work on a specific project during the next cycle, present their ideas and discuss them with other developers. Then begins the implementation, which is artificially divided into three brief “stages” to break the work on the project.
After the third stage of development, we switch to the function freezing mode, in which the focus shifts to correcting the list of critical errors before release. After all critical errors are fixed, we create a release candidate. If no critical bugs are found in the release (in this case, we can fix them and rebuild the new release candidate), all candidates are collected at the time of release to create the final integrated release of OpenStack projects.
Q: What determines the frequency of OpenStack releases?
A: We are trying to have the main branch always available for launch. “Releases” are really just points in time, tags in the repository, which we mark as special cases. Our release cycle is designed to reduce the risk that a critical regression will penetrate our “releases”, so “releases” carry less risk than random basic code fixation. What follows is interesting: we maintain stable branches, where we apply patches to critical bug fixes and vulnerability fixes, and these stable branches are created from release points.
The current release frequency of OpenStack releases is a compromise between our desire to speed up iterations, the ability to hold developer workshops, the need to update documentation after freezing functions, frequency of freezing functions and the availability of resources to support stable branches.
Q: What are the advantages and disadvantages of a three-month release cycle?
A: You can remember that at the beginning of the development of OpenStack, we had a three-month development cycle. Now it usually takes 4 weeks from the moment you stop adding features until you get a working release candidate. With a six-month release cycle, it is possible to freeze functions for a month. In the three-month release cycle, this period is less. Releasing every three months means maintaining twice the number of stable branches. Thus, if more people fix critical errors during the remaining cycle period (not during the function freeze period) and more people help maintain stable branches and security updates, we can definitely move on to the three-month cycle. I like to hold a Developer Workshop at the beginning of each cycle (I think it helps us achieve better results), so I suppose we will have to convince the Foundation to pay twice as much for developers!
Q: How can developers take part if they are forced to miss a workshop or cannot afford a trip to a developers workshop?
A: Participation in the Developer Workshop is by no means a necessary condition for adding code to OpenStack. Discussion can be conducted on mailing lists or in the code verification system. The Developer Workshop is a convenient way to quickly go through the brainstorming and implementation stages, getting early reviews in lively personal discussions.
Q: Is the OpenStack community thinking about following the path of the Ubuntu community with a “online only” developer workshop? Does this work for OpenStack?
A: Ubuntu developer workshops have basically become a feedback gathering exercise where major developers present their work plan for the next few months. For these purposes, the virtual environment is ideal and saves a lot of money. OpenStack developer workshops are used for something else: motivating the global and virtual developer community for the next six months, brainstorming ideas for development, or reducing duplication of effort by communicating with various groups of developers. But the most important reason to keep the participants in private communication is to maintain common sense in the community. Personal meetings are necessary in order to resolve any conflicts that have accumulated over 6 months of virtual communication.
Q: We recently interviewed Monty Taylor , technical project manager for continuous integration. What do you think continuous integration is so important for OpenStack?
A: Continuous integration allows us to trust that the content of the main branch works and does not contain regression. OpenStack is a complex device and you can accidentally break it. I used to deploy a release locally and periodically run several manual tests to make sure that the basic functionality is not broken.
Today’s infrastructure runs thousands of times more tests than I ran before, and so on for every proposed change. Continuous integration allows me to sleep well. Without it, we would not be where we are now.
Q: Are there any areas of the development process that are not yet automated, but will be automated in the future?
A: No, all aspects are automated, although there is room for improvement. Some projects could use more integration tests; your continuous integration is only as good as your tests.
Q: What should developers who want to be involved in writing code for OpenStack bring to the project?
A: Sense of humor. The developers of OpenStack are a community of nice people and we would like it to be like this forever!
Q: What advice would you give to newbies - those developers who want to contribute, and companies that want to build a business around OpenStack?
A: The OpenStack project is what we make of it. Join us, you will not regret!
Q: Thank you, Thierry!
A: Thank you!
Source: https://habr.com/ru/post/187218/
All Articles