CentOS: Planning for Variants and the Next Chapter
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Singh, Karanbir
CentOS has cemented a reputation as the "community enterprise operating system" - one that provides a reliable rebuild, but is not known for innovation in its own right. With the news that Red Hat and CentOS are joining forces, this is going to change. Here's how CentOS is planning to change, and how other distros can learn from our next phase. This includes our governance changes, and how we'll address several different special interest groups (SIGs) that have different ideas they want to realize with CentOS. It also includes technical changes, and I'll explain how we're going to manage our build system and source control for accepting upstream code and then creating new variants. Most importantly, I'll also be taking questions about the new direction and how we got to this point
 You Okay, how about that? Let me see, is that? Okay, I guess we go to kick off. How many people here know what Santos is? That's half of my talk, no longer needed. How many people here know who or what red hat is? Excellent, that's the second half of my talk done. I'll still try and go through it, since everybody's come. You guys have made all the effort. There's just two constraints that I'm talking under. One is that I have a cold, and I don't know why. I always seem to get a phosdome cold. The second problem, which is a bigger problem, is that I've only had three beers in the last four days. Please bear with me as I try and struggle through the talk. Immediately after the talk, yes. Let me see if this works. I guess most people, if you know about Santos, you've either heard about me or who I am, or either you like me or more likely you don't like me. Just a bit of a brief introduction about me. I started off with Linux back when you still needed 44 floppies, and CD-ROMs were just about making their entrance in. I used Slackware for a while, I used Gen2 for a while, I used Debian for a while. Moved on to Red Hat, I think 4.4, Red Hat 5, 6, 7, 8. I then couldn't really go anywhere from there. I found the Santos project, or other some people from the Santos project found me. I wasn't one of the founders, but I showed up fairly early in the game just to point out how everybody was doing everything wrong. Unfortunately, they punished me by letting me do things. I'm still here, 10 years down the road, still telling people how they're wrong, still hopefully trying to fix stuff. Professionally, I've been a sysadmin, I've been a developer, I've been a manager, I've done data warehousing, I've done cloud operations, please don't hold that against me. I worked for hosting companies again, please don't hold that against me. As of a couple of weeks ago, I'm not entirely sure what I do. My job title is a member of technical staff. I guess that's an easy way for them to put me somewhere and not have to worry about finding me a title that actually means anything. I'm a straighter to the UK, I've been there for about 15 years now, I quite like it, although I prefer Belgian beers. One point I always try and make is that there are two really sides to the CentOS story. There's a CentOS Linux distribution, which I guess most people are familiar with because that's what most people consume, that's what the interface into the project has been. But there's a very real, a very tangible, a very quantifiable entity behind the Linux distribution called the CentOS project. It's hard to see, it's been hard to perceive, it's been hard to quantify because we don't exist as a legal entity or we haven't existed as a legal entity. There hasn't really been a target that people could point at and say, this is the CentOS project or this is the privilege escalation process or whatever. But the entity exists, whether it has been completely voluntary driven by sponsors, driven by donors, people helping us out. And the community of users as well, all of that contributes into being the CentOS project. And it's quite important now, especially in the new context of the Red Hat announcement, that people think about CentOS Linux as being just one of the things that the project does. The Red Hat relationship is something that got announced recently, but if you really think back, the Red Hat relationship has always existed pretty much as long as the CentOS Linux distribution has existed. Let me point it out this way. There are a couple of 10th anniversaries going on at this moment in time. It's been about 10 years since Rally came about, it's been about 10 years since the Fedora project came around. You'd probably see the Fedora guys wearing T-shirts saying 10 years. It's also been about 10 years since the CentOS project started off. You'd almost think there was a coincidence, right? That there was something related in there. And then there is. And the relationship has been focused around what Red Hat is doing with the Red Hat Enterprise Linux product and how they kind of migrated from the traditional or the old school Red Hat Linux to Red Hat Enterprise Linux and how Fedora came up. And I guess since most people are aware of CentOS, you guys know what we do and why we exist, right? So we don't need to kind of go into that. But the important thing is that the relationship has always existed. So early last year when my phone rang one day, I picked up the phone and it was a couple of people from Red Hat legal on the phone on the other side. It was, I was like, hello. What can I do for you? It was a strange relationship. It was a strange conversation to have because although the relationship has always existed, the conversations have always been in the corridors of FOSDOM or corridors of various conferences and events and sometimes conversations on Bugzilla, sometimes conversations on IRC. There hasn't really been a formal conversation with Red Hat. But when the conversation started off, it was easy to see how much of what we were doing sort of lined up with what they were trying to do and how much of what our wish list was shared by a certain set of people within the Red Hat organization as well, which is what led to the whole idea of, hey, maybe we should think about doing this together. Maybe we should think about breaking down some of the firewalls. Maybe we should think about trying to bring Red Hat on board with the Centros project to try and see how they could sponsor, how they could curate the ecosystem in a slightly more sort of professional, in a better managed kind of a process. So there's two things that are important there. Firstly, it was Red Hat as an organization that has come to join the Centros community. Although it's very clear, you know, you should be under no doubt about the fact that they said this is an acquisition. Red Hat has acquired the Centros project. The trademarks that we've registered for Centros are now curated and maintained by the Red Hat legal team. The terms and conditions that we operate under are terms that are set by the Red Hat legal team. So there should be no confusion about the fact that the Centros is very much a part of the Red Hat ecosystem that is curated by the Red Hat nominated people. However, from the community side of things, it is still from the Centros project side of things. So it is very much a case of Red Hat joining the effort rather than Centros folding into what they already had in mind. And what we've done to kind of highlight that is that there's a governance body that has come up, which is primarily composed of the existing Centros core team as it were. And there's an escalation process that has come up that allows pretty much anybody to come in and be a part of that team and basically go from being a user to a contributor to a build person if you want. And if you guys are really interested and motivated, there are opportunities to join the Centros board as well and be a part of the decision making process. So the important thing is that the relationship existed, it always has done, and we've now been able to solidify that. So what is it that has really happened here? A couple of things I've already mentioned, the Centros trademarks have transferred over to Red Hat legal. There are some subtle changes that also have happened around the edges. Centros has by design been built and released out of the EU for a period of time. That changes. This is now very much delivered out of the US. It's delivered out of a Red Hat machine, which is technically and realistically the only change that has really happened within the Centros infrastructure, that there's a machine that is owned by Red Hat that has now become the primary cedar. And there were a couple of conversations on the mailing lists about, hey, does that mean we now subject to US jurisdiction? Does that mean that we now subject to US trade laws? And the interesting thing is that we've always been subject to those. It's just that by building and releasing in the EU, we may have been able to do a bit of an ostrich deal, where if you dig your head far enough into the sand, you don't see the guy who's going to come and beat you up. And I think we've been lucky that the guy just never showed up. People tried that have been where legal situations that came up and things, and we were just lucky that none of them really unfolded into anything too drastic. But yes, we are constrained by what is legal and what isn't legal in the US. And in terms of export control, we have always been a part of our, we've always been subject to the US laws because we've only consumed content that came out of the US anyway. So if you really think about it, we haven't been doing stuff, we haven't been consuming stuff, we haven't been pushing stuff that hasn't otherwise been exported from the US. So we've always been subject to those. It's just that those things are slightly easier to see. The other big thing that has happened is there's a governance body that has come up with a mandate. Sorry, there's a question at the back shore. Yeah, so the question is that Fedora and Rural have terms which specifically forbid you from using them in infrastructure that builds rockets. So I think there are two parts, so there's two ways to analyze that. I highly recommend you write that question, send it to me on an email, and I'll get a lawyer to reply to you so that we can quantify it. I'm not a lawyer and I don't speak for Red Hat when I say this, but I think there are two ways you need to look at that. Firstly, are you violating the GPL by doing so? Secondly, are you using content which is otherwise restricted for export by the US? So not in terms of application, but in terms of content. So if you're not, then that's a guideline that you could use, and based on that you should probably send me an email and I will get a lawyer to reply to you. So you know, privately, this has been one of the fantastic things that has happened here. There are lawyers that I can actually ask questions to and not have to wait six months to a year before I get a reply, because so far we can't afford lawyers, right? And we've been very lucky to have people like Andrew Katz and a couple of guys in the US from the SFLC who've helped us out for a long time. But then you ask somebody a question, he's a lawyer, he's got customers, he's got clients, he's going to work with them first. So six months to a year is usually when we used to expect replies. Now there's a legal team I can actually ask a question to, which is fantastic. A lot of the constraints that we've had to work with in the past as well, things like, hey, do we create a firewall between us and Red Hat? And then how do we extend that firewall to the customers and Red Hat? And then how do we extend that firewall even beyond that to users of CentOS, to the customers of Red Hat, to Red Hat, and to us? A lot of those questions we had to be very pedantic about, we had to be very, very, very, pessimistic about, and a lot of the processes that we had, things like a private QA process, things like, if you find a Red Hat brand somewhere, we would have to go back and purge that brand from everything CentOS, things like that. A lot of those situations are no longer as big a deal as they used to be because we have access to people at Red Hat Legal that we can ask to quantify the issue. So if somebody finds, hey, I found something in here that says that this is the man page for Bash for the Red Hat Enterprise Linux. Does that mean what I'm running is Red Hat Enterprise Linux? We can go back to a legal guy and say, hey, can that question be interpreted to mean what the guy thinks, the question that he's asking? And if they say yes or no, we will take action to that. But in many cases, I think what has happened in conversations with them is a lot of the stuff that we were doing was overly pessimistic. We did not need to be that pessimistic. And I think, I still think that what we did was the right way of doing it because we were able to assure something. We were able to say that, hey, because we've taken these steps, we know that we've tried to protect the users to a certain extent. It may be that what we did was more than what was required. But having done what we did, we were at least sure that we've been able to protect those people against those things. Does that cover the scope of the question that you were asking? Absolutely. So the other thing that is also happening here as a part of the what is that Red Hat actually offered the core contributors as it were to the CentOS project jobs at Red Hat to say. And they made an offer to quite a few people saying, would you guys like to come and work on the CentOS project as a part of your full-time job responsible for the CentOS project? Some of us took it up. I did. I took it up. I thought it was a great opportunity. A couple of the other guys did as well. Some people said no. And the guys who said no have not been penalized. Some people kind of thought it had happened on the mailing list as well that to be a part of the process you had to be on the Red Hat team and that's not true. We've got people on the CentOS board. We've got people in the CentOS QA teams to build, set up the infrastructure teams who don't work for Red Hat, who don't want to work for Red Hat and that's fine. And there is no infrastructure within the project that they don't have access to. There are no terms that they have to work under. There are no contributor license agreements that they've had to agree to. The meritocracy that we've been able to build up over the years for privilege escalation stays in place. So if you join the mailing list and you're able to prove that you're good at what you do and you get invited to be a part of a team where you can do something about it, you're welcome to be a part of the team and not working for Red Hat is not a penalty. So why are we doing this? I think in many ways, in many ways, this is actually a natural progression and I guess the question would be why we didn't do it sooner. We would have liked to have done it sooner but we never knew how to approach Red Hat. So we had to wait for them to make the approach. We had to wait for them to come across and say, would you like to come and do this thing? And the larger problem that we're trying to solve is that the CentOS community exists as a very specific, as a very special group of people. The CentOS community is primarily user-driven rather than developer-driven, which is again unlike a lot of open source projects. The CentOS community is not feature-led. It's more problem-led. More people want to make changes because of problems that they face rather than features that they dreamt of yesterday night. Like, hey, this is a great feature. Maybe I should write some code for it. And if you look through the bug.centos.org site, you will find that there are very few feature-led issues that come up and 99% almost of the stuff that comes up is problem-led. If you look at the conversations that come up on the mailing list, they are problem-led. And that's a great place to be. It means that people are actually using this stuff and they're hoping to fix problems that they actually have in real life rather than a developer-led group who tend to be more aggressive on creating new features, creating more special branches, being able to deliver more value, whatever it is, through code. And I don't hold that against developers. How many people over here consider themselves to be developers? How many of you consider yourself to not be primarily a developer? So here's the point. This is still a majority. It's a very thin majority, I have to admit. It's a lot thinner than I thought it would be, but it's still a majority. And that's an interesting place to be because what happens is that if you're able to now deliver stuff to these people, if you're able to deliver stuff to problem domains that we were in ourselves, then we may be able to actually create value around applications better and faster than a developer-led community would be. Does that kind of make sense? Does anybody have questions around that particular point? Not yet? Yeah? That's a question. Yeah, upstream first. We've always tried to stick to that. Yes. I guess it depends on what you're trying to upstream. If it's somebody on OpenStack, then perhaps they should go further up than Fedora as well. If it's a kernel issue, then perhaps Fedora, whatever. So when is all of this stuff happening? I guess you guys have already seen the announcement. Is there anybody here who doesn't know about the Red Hat-Sentos relationship? So this one person, we must all help him. We must all tell him what has happened here. So last year, early last year, the Red Hat people got in touch with us saying, we understand it's a relationship here. You consume our code. You produce something based on our code. What can we do together? How can we set up a relationship that works in a way that we're just better able to curate the Sentos community at large and be able to expand the scope of what you guys do? And on the 7th of January this year, Red Hat and Sentos announced that we were joining forces. And it's a very interesting term because it's not a partnership. It's not an acquisition as such. It's actually a case of joining forces where the Sentos project carries on doing what we're doing and Red Hat is able to come in as a sponsor to help do more. But there's now a formal relationship that exists between the Sentos project and Red Hat and Sentos Linux and Red Hat Enterprise Linux. Does that make sense? Okay, right. So now everybody knows what's going on. What we tried to do was that when you were working through the mechanics of what was going to happen, a lot of people at Red Hat were very anxious. A lot of people from the Sentos community or the contributor bases who were involved were very anxious to see, hey, what is this going to really mean? Does this mean a mailing list has to be set up? Does it mean something weird has to happen around the edges? What are the processes going to be like? Who's going to be running the systems? Who's going to be running the gate repositories? And how are all of these things going to be happening? Hi, John. I'm actually fine to just stay with this. If you don't. Okay. Should we swap at that point? Or you want to swap now? Yeah, let's do it then. Especially the guys with the legal hats on, especially the guys with the trademarks and the whole community managers, and they were all very keen on saying, hey, we should have process in place. When we go out and announce, we should be able to tell the world that this is how we're going to do what we're going to do. We were very keen from the Sentos side of things that we did not pre-agree to anything. Obviously, it wasn't going to be that clean. We had to agree to being able to do a certain set of things. We had to agree to some of the paperwork being signed and stuff like that. But what we have done is that we've agreed in principle to have conversations around processes. We've agreed on paper to have conversations in the public forums about how we change what we change. We've agreed that Red Hat will bring their people in. We will have open, wide communication channels available to anybody and everybody who wants to participate as we adopt new standards, new systems, new processes around whatever we do. Those conversations are starting off now. Nothing around those conversations is actually decided. So when you see the questions being asked on the Sentos developed, those are genuine questions. There are no pre-decided answers to those questions. Please participate. Please join in. Become a part of the process. And all of those opportunities exist now. And I can't stress enough that most of the stuff that you're about to see, most of the things that you're about to see in terms of the special interest groups, the variants, how the process is going to work, how the engineering is going to work, are all proposals at this stage. Nothing is actually decided. And anybody and everybody is welcome to come along, be a part of the process that decides what we're going to be doing and how we're going to be doing it. One of the big things that's, of course, going to happen is that there were three terms, like which took a committee about a week to decide how to come up with as things do. So the thing was, what are we trying to do? We're trying to be more open. We're trying to be bigger. And we're trying to be more inclusive. That makes sense, right, to everybody. Does that make sense? Not really. Okay, good. Because, yeah, buzzwording doesn't really mean a lot in itself. So what we really want to do is, let me step back a minute and let me quantify something that isn't changing. What isn't changing is that CentOS Linux is not going away. CentOS Linux is rebuilt from rel sources that are released publicly. That is not going to change. That is going to carry on doing what it's going to be doing. We may not get much better, but we will certainly not get any worse. And we may not get much better because the organizations at Red Hat that we're working with are the open source and standards groups. We're not working with the Red Hat engineering guys. We're not working with the RHCL engineering business units. We're not working with the product side of things. We are very much working with the open source and standards group. So we may not have the opportunity to know when rel 7 is coming, for example. But when it does happen, when it does come through, we will actually get the sources at the same time as everybody else does. And the big thing that's going to be facilitating that is that Red Hat is going to stop publishing sources on ftp.redhat.com. And all sources will actually be released through git.centos.org. In a format that is easier to consume, it's easier for more people to come in and participate in. It's easier for people to run their own branches. It's easier for people to run their own variants of the same builds. But the core builds will not go away. So what you consume today as CentOS Linux will stay in place and you'll still be able to consume it just as you do today. So with that, what is not changing in mind, what we are going to try and do is try and become more open and more inclusive. So the plan is that we produce the CentOS Linux base, but we create opportunities for people to come in and create their variants. And this is something which has been happening for a very long time. If you look at the Wipe industry, for example, if you look at the open source communities and in the Wipe ecosystem as it were, there's always been a CentOS rebuild which has carried a Wipe stack on it. Sometimes it's been 2, 3, 4, at this time there may be 100. There's always been repositories of people sort of trying to add functionality to what we do in CentOS. There's always been sort of live CD variants out there. There's always been people doing things like a high performance specific build. There's been a minimal installer, a high performance file system installer. Various projects have been able to take stuff away. I don't know how many people are at the dojo yesterday, but the Morantis guys were there yesterday. And they were talking about how they consume CentOS internally to roll out the open stack platform. And I think there's something like 11 or 12 different open stack installations or open stack distributions which don't do a lot more compared to each other. And they all consume CentOS internally. So one of the things that we want to do is make it possible for those guys to come on board, be a part of the CentOS.org group and be able to consume what we produce while still extending things in interesting kind of ways. And how we want to organize these groups is in terms of special interest groups. It could be one person. It could be 100 people. All you need to do is find a reason for an interest group to exist. And what we say is that while we're open to accepting pretty much anybody and anything, it would be nice if the special interest group is driven by a problem domain. It should be driven by user requirement and not a technical requirement. So for example, we would prefer to have a cloud SIG or a cloud instance SIG rather than a SIG which builds VMware images. Is that quantification kind of clear? So it's like if you want to have a special build of, let's say, open JDK, then you're more likely to have a SIG proposal pushed through if it was because it's needed to run version 76 of Eclipse rather than, hey, I want to do this because I want a newer version or a different version of Java in there. So that's the only thing that we kind of point at that look. Do it from a user perspective. Find a problem domain. Find what issue you're trying to solve. And then we can work on the mechanics required to solve it. And every SIG can target one of four things. You can either have your own repository hosted within centOS.org where you can build your own packages. You can build packages and contribute them into CentOS extras so that they're available to all CentOS users. Or you can take the CentOS distribution and you can build a variant of it. So you say, hey, I want these packages. I don't want those packages. I want these things to be pre-configured. I want those things to be not pre-configured. And you can build a variant. Or you can target something which is based off CentOS. So if, for example, you want to be building an Asterix distribution which changes some fundamental things, then you can still do so. And you can call it, you know, my great Asterix distribution and it's based off CentOS. And that's available to any SIG to target. And SIGs can target multiple things. I know the Cloud SIGs are planning to do multiple things where you can have, so you can have, for example, you'll be able to YAM install OpenStack. But you'll also be able to get a live CD which has OpenStack or CloudStack pre-installed on it. And you'll still be able to get images and things like that. So you can target multiple things. The other big one from the SIGs is that while SIGs are specific, there is a lot of cross-pollination between SIGs. So we've got a SIG coming up, for example, for the Word group where we've got a Zen stack working on CentOS 6. And we've already started having conversations of how the Cloud SIG could work with those guys to consume the Zen for CentOS content under OpenStack to make Zen be a primary partner under OpenStack, right? So you don't stack to KVM for that matter. And that's something that's also encouraged. Let me see if this works. Yeah. So how we're planning to make SIGs work is that a group of people can come together. You can get onto the CentOS development mailing list. You can propose a SIG. The SIG proposal gets in. You get access to build packages. And then as your SIG matures, you get more features. You get more resources. And you can do more things on your own. So when you initially join up, you may have to say, hey, this is my source. This is my spec. What do you think of this? And we will import it for you. If you can prove over two or three months' time that you know what you're doing, we'll just give you direct Git commit access to the main repositories on Git.CentOS.org. Hi, Tanya. I wonder if in the criteria to actually grant that the fact that that SIG should be inclusive, that means other people wanting to actually join that specific development should be about to do that. So that we don't get something which is special proposals for, say, one company or one something and other are allowed to join in. So the question is that Git access should be available to everybody. So I think the plan on how to address that is that we will mirror everything from Git.CentOS.org onto GitHub and onto Git.Orious. And we've been talking to both GitHub.com and the Git.Orious guys to see how we can create those replicas. Because primarily the challenges that the Git repositories for CentOS 5.6 and 7 put together are about 2.3 terabytes at the moment. Sorry. There's a phone somewhere. Let's just ignore that. It's somewhere in my bag. And I'm sorry. So the challenge also becomes that at what point do you acknowledge that a particular user has the authority to represent a user base? Fine. I will actually try and find it. Hang on. That's convenient, isn't it? Let's hope that does not happen again. Right. So the challenge is like if, for example, there's a virtualization group together, then at what time and at what point do you decide that anybody who's come along should have the privileges to change other people's code unless that person has demonstrated either within CentOS or within that community that they know what they're doing. So it's a double-edged kind of a thing. So there is still a slight barrier to entry. But because the GitHub process is inclusive, it works. And because we're going to try and make sure that there's enough people who can do that bridging, we'll try and get to a point where pull requests don't wait, for example, for more than 48 hours. We'll try and make sure that the process is always churning. We might be able to address it in that manner. So as the SIG kind of matures, you get more resources. And it goes all the way from initially having to propose the sources and what you want to do to a point where you get your own Git commit access to a point where you can then start requesting signatures for your packages to a point where you can actually start signing your packages. Within CentOS or DOG, to a point where you can actually start doing your own releases within CentOS or DOG. So you can decide as a SIG that, hey, we need to do a release of the entire OS. And I want to branch it and say, hey, this is going to be the open stack on CentOS. And I want to do a release next Tuesday. You will be able to do that within the tools and the constraints that are available within CentOS or DOG without needing somebody from, let's say, the governance group or the core SIG or something like that to come across and push a button. You'll be able to request it yourself. So the plan is that it goes right all the way from zero to pretty much being able to run your own little micro distribution within CentOS or DOG on your own. It's a good goal to get to. I hope we're able to get there. The processes of how we get there are being discussed right now. So if you want to be a part of it, please jump in and start contributing. Start owning parts of it if you want. The second part of it, and this is something that we have to argue with a lot of people for a very long period of time, is that we wanted to be inclusive content. So content that we push should not be restricted by policy. It should be restricted by licensing, and it should be restricted by copyright terms. So for example, if somebody has a piece of code that they don't want to open source, but they make it available for redistribution, then what we are doing technically is redistribution. And if the community wants to adopt that code, we should be able to adopt it. And it's something that we've been working on for maybe about almost two years, and it's good that having Red Hat on board, we've been able to fast track that process and accept it in. To give you an example of what kind of stuff I'm talking about, it's things like the NVIDIA CUDA drivers, for example. Or perhaps it could be the Intel Compiler Collection Build content, which otherwise isn't open source. But we may be able to talk to those guys, we may be able to get something from them to say, hey, this is fine, send us as a project, you guys are okay to redistribute this. We will carry that content. So it's actually going to be a lot more inclusive than it's ever been before. And the content is restricted by legality and licensing rather than policy. So it shouldn't be, hey, we will only accept code if the name of the project starts with A. That's just silly. Does anybody have any questions around that? Does anybody have any issues or doubts about that? No? Good. Is that a good thing to do, I guess? Is that a bad thing to do? It's good, yeah. So what's happening right now in the six? When we announced the whole thing on the seventh of Jan, I remember having a chat on the sixth with a couple of the other guys saying, I don't really know, the CentOS user base has been extremely passive in the past. I don't really know how this idea is going to go down. But if we were able to get one SIG on board in the first month, and if we were able to do one release, or we were able to deliver one thing within the first two months, that would be a fantastic place to be. It would set a precedent. It would allow us to grow. It would allow us to attract other people into the projects as well. I believe within the first 48 hours, we had 19 SIG proposals. And within the first two weeks, we had formalized on three other SIGs. Yesterday, is anybody here who was at the Dojo yesterday as well? There are a few people. So we actually did delivery. So we built images for OpenStack, for CloudStack, for Eucalyptus, and for OpenNebula, and for Overt, and for Docker, and for LX containers. During a four-hour hackathon, we were able to test them. We were able to stage them for release. And first thing on Monday morning, you'll see the announcements going out for the images that we were able to build. So we've actually achieved our first ballpoint, our release point within, I would say, three weeks, which is a great place to be. The entire tooling that has made this happen has come up in the last two weeks. The entire release process that has come up has come up in the last two weeks. And it's completely inclusive. All of the scripts, all of the code, everything is public. You can go, you can fork it, you can start contributing right now. So this is just like sort of an overview of some of the SIGs that are coming together. The CloudSIG, I think I mentioned that a few times, which has been really good. We've got Eucalyptus, OpenStack, OpenNebula, and CloudStack, and the Overt communities who have all come on board. There are some hard questions that are being floated around at the moment. There are some hard answers that we need to find as to what the value is for multiple cloud infrastructure guys to be working together in one group, or whether the CloudStack guys want to be delivering their own thing, or whether the Eucer guys want to be doing their own thing. And hopefully, given the fact that we're expanding the ecosystem, hopefully given the fact that the SEF guys and the Gluster guys want to run the storage side of things, given the fact that the Zen guys want to come in with the Zen code, given the fact that the Docker guys want to get involved with the Docker containerization stuff, we're able to build enough of an ecosystem that there is value in everybody working together. Every cloud instance that comes up really is a bunch of yum installs, followed by either a puppet run or a chef run or a non-sable run or some sort of configuration management thing, right? Yet, every one of those guys maintains their own version of puppet. They all maintain their own version of chef. They've all got their own packaging around Ansible. They've all got their own playbooks. They've got their own configuration metadata. They all consume Gluster in a slightly different way. They all consume LibWord in a slightly different kind of way. And the real win from working together is going to be if we're able to consolidate some of these things. And I'm hoping we're able to do this more at a developer level rather than a vendor and an association level. But that may be a wishful thinking. We will see. I think six months from now, we'll know exactly where we are. The cloud instance has also been very active. I think I've kind of covered that. We've built a unified image. It's the same image which works across all of those platforms that we've been able to deliver. We're not doing any tracking and updating at the moment because we haven't done the release. Hopefully that will happen on Monday and then becomes a big challenge as to how we keep it updated across various ecosystems. And again, how we do it, when we do it, what the process will be is open for discussion. Please jump right in if that's something that you're interested in. Just a quick run through of some of the other guys. The word sync is coming together. I believe we've got Zen on there. I'm not sure if I'm allowed to commit you to being on there, but I'll go ahead and say that Zen is on there. The storage sync is coming together. We've got the SAF guys working with us. We've got the GlusterFS guys working with us. And the aim is that we deliver a unified repository which contains common metadata. So for example, QEMU needs certain options in place for the SAF backend storage system to work. Gluster needs certain patches to go into QEMU. And what we really want to do is have one QEMU which does both of those and also works with whatever LibWord we end up shipping as a part of the word sync process. Hopefully people will see that as a good way. And the fact that we've got traction from the upstream developers to be able to do this is, I think, a great place to be. We do ship a minimal ISO. I guess, does everybody know about the minimal ISO? And it is, I think it's quite minimal. It doesn't even have open SSH clients. It doesn't have Kron in it, for example. But apparently that's still a very fat ISO. So if there's a sync that has come together with the aim of having a CentOS install base which is only 90 packages or less, and it's only 250 megabytes or less, I wish them all the best of luck. I will be around to do the tooling for them. I will try not contributing too far into that. But it's a problem that they see. If there's a problem they want to solve, they're welcome to do so. We've got the SME guys, the SME server guys, NET server. We've got the clear OS guys who all want to come together and try and see how they can unify, how they can share code about building a common SME home server kind of a thing. It's something that, it's a demographic that I don't really understand very well. But I don't. So I mean, the last time I worked on that scale was probably back in 97, 98. Because, so you see, there are two parts of it, right? Either you work in the IT services industry or you work in the consumer industry. And I think that's the kind of demographic which is more consumer side. And it's just that since the late 90s I worked more on the services side. So it's a demographic that I don't really understand very well. But obviously there's a lot of people who have use for it. A lot of people have utility for it. So, you know, these guys are coming together. And I think it's great because in many ways clear OS has been seen as a competitor to CentOS. The NET server efforts have been seen as a competitor to CentOS. The fact that we can bring these guys in, the fact that we can bring the SME server guys back in to the project. So we all share codes, we can share some of the features, we can share some of the wins as well. I think it's a great place to be. The white guys are coming together. There's a bunch of people around various things, the free PBX guys, the Asterix guys are all working on the stuff. I was talking earlier today to somebody and then a couple of days ago as well about people talking about a super secure version of CentOS. I don't know what that means again. But I think it's a case of, you know, ciphers which they prefer being enabled by default and stuff like that. We have the mechanics in place that allows them to fork pretty much every package, rebuild every package that they want to and run it with that. There's an app hosting sake that is also coming together which is to deliver a very minimal CentOS with an installer that has the ability to arbitrarily add other content into the installer. So if you've got a project, if you've got, let's say, you're writing a piece of software which helps people get rich quick, then you want to ship it on CentOS, then you don't have to rebuild the whole thing. You just download this ISO, you dump your content into a directory, you create a com.src.xml file which has to have a specific name, you MKIS or FS and you have an installer for your software. Which is again, I think, hopefully should get a lot of attraction. And there's a bunch of people coming together around the scientific idea as well about building scientific applications. We've got the Imperial College guys in the UK who've offered to come in and do a lot of software. We've got a couple of government agencies in New Zealand who've actually already been working on a repository with us. It's just easy enough for us to do this as a part of a SIG and that's about 400 different applications in the scientific scale of things. And there's many other conversations going on around the edges as well. So if there's something people are interested in, you guys are interested in, jump right in, the opportunity exists. It's not going to go away but it's nice if you get involved early because then that allows you to have ownership over the processes that we end up adopting. You can be more a part of how we end up shaping up everything else that is going to come further down. There is one special SIG though that is also coming up called the Centros Core SIG. And this represents what used to be the old Centros project. The people in the Core SIG are the people who were a part of the Build Europe and the core admin team of what used to exist in Centros earlier. There's been a few changes but by and large the mandate for the Core SIG is to deliver the Centros Linux distribution. So these are the guys who are going to be focusing on that. The opportunities for privilege, escalation into the Core SIG are just the same as any other SIG. So there's no differences in that. But the Core SIG also does certain other things like we'll be responsible for running the infrastructure, making sure we don't get hacked, making sure the website is updated. So who's seeing the new website? It's great, isn't it? It only took us like eight years to get there but we did get there finally. And it doesn't hurt your eyes anymore, which is always a good thing. So the Core SIG is responsible for things like the website, we're responsible for running the infrastructure behind the wiki, running the infrastructure behind the bugs instance, running the mirror lists and all of that kind of stuff. Again, all of the code goes public, all of the build scripts are public, all of the metadata around that stuff is public. If you're interested in these sort of things and if you have a minute, I'm happy to do a demo of how we're building Centros 7 as well. That's the Core SIG and it's important because the Core SIG essentially works within the constraints that any other SIG would and they work with any of the privileges that any other SIG would. And it's just that what they do is defined. So while other SIGs can be, oh, we'll do this today, we'll do that tomorrow, the Core SIG is focused on only doing one thing and that is delivering the Centros Linux distribution and then maintaining the infrastructure around it. The point that I want to also make over here, I realized that, or I thought initially that we'd have a lot of people from other distributions coming along to say, what the hell are these guys on about? And I'm not sure if they are. But one of the things that we worked on quite hard, at least I've personally worked on quite hard over the last four to five years is building distribution relationships. And I'm hoping to be able to do that even more. I'm hoping to be able to expand the scope of what we've been able to do in the past. And I'm hoping to sort of fast track a bunch of conversations that have been going on. And an easy example of that is this is interesting new thing that we all love and we all enjoy. It's called UEFI and Secure Boot. It so happened that Centros 6.2 when we shipped it out, did not work on machines which did not have a BIOS failback. So this doesn't mean machines which don't have BIOS support. This is machines that didn't have BIOS failback because we had a partially enabled EFI support in the ISO. We didn't find out until three months after we released it. So that clearly indicates how popular that particular option is. But when we did find out and when we looked at how deep and what the implications were, we were like, there is no way that we would be able to afford the infrastructure or the equipment to be able to prove ourselves. So we went out and spoke to the guys at Intel. I believe the PSG, the professional services group at Intel, the guys who write this specification for the UEFI. And we got the Debian project in because the Debian project was exactly in the same situation. I was able to reach out to the Gen2 project. I was able to bring them in. And they were very happy that somebody was actually talking to them from a different project. We were able to bring a couple of other distributions. I believe the ArcLinux guys are also now using the same infrastructure and I believe the Mint Linux guys are also using a part of the same infrastructure. And we were able to bring a couple of demo machines in. We were able to bring in the development firm words in, hosted in a common area at the OSL in the US. And we've now set up a Google calendar where various different projects can use that infrastructure to prove that their software actually works with UEFI. The next step that I'm hoping to be able to do in April-May timeframe is to solve the secure boot problem as well to see how we as a community of Linux distributions can address that issue and what the scope of that is as well. A second example of this whole cooperation has also been that IBM PowerPC is quite hard to find. Yet everybody wants to target it. And again, in the summer of 2012, we were able to reach out with, as a group basically, of the CentOS project, the Debian project, the Gen2 project. And we were able to reach out to the IBM community outreach guys in the US. We got on about five Power7R2 machines, which are again shared between a bunch of projects, including the Postgres guys now as well. And I think the Gen2 project is also using the same infrastructure that hosted on a common platform that is facilitated by the CentOS project. And I'm really confident that we want to try and accelerate a lot of these projects to bring more resources in, more efforts in. The project that I'm working on right now that I'm hoping to accelerate is to be able to bring ARM infrastructure in as well. We've got something up that is that kind of works. But it's harder to bootstrap on ARM. And I'm hoping to be able to bring ARM 32 and ARM 64, ARM V7 and V8 infrastructure out. We're talking to Boston electronics. We're talking to internet works, penguin computing. We were talking to CalCEDA. Unfortunately, that conversation had a bit of an abrupt ending. Okay, so I'm guessing not a lot of people know that CalCEDA is... How many people here know about CalCEDA? Okay, so a few people. So how many people know that they're in a bit of trouble at the moment? Okay, so everybody does. That's fine. So we're hoping to be able to accelerate a lot of those processes as well. And the second thing that I'm also hoping to be able to do is something I mentioned previously, that we have like the cloud stack guys, we have the open stack guys, we have the open Nebula guys, the eucalyptus guys coming in. It would be fantastic if we could, at a developer level, agree to support a particular version of LibWord for a year, year and a half. That allows other people to target the same pieces of software as well. And therefore, it's not only us who gain, but it's the entire ecosystem around those projects. It's all the other distributions around those projects which also gain from having that resource available. And then finally, our test harnesses that we've been working on quite hard for many years. I mean, we would love to be able to open that up and allow other distributions to be able to use it as well. And we're trying to come up with scenarios as to how somebody might be able to use Deb instead of RPMs, and how we might be able to further abstract that stuff away. And then other people like the Debian projects, for example, could then test their installers using the infrastructure that we have in place, the blade centers that we have in place. I think I'm nearly out of time, so I'm going to leave you with the three words which took me a week to come up with. And does anybody have questions at this point about things? Okay, quite a few. So if you can't get to all the questions, then come and find me at the CentOS table. We're in K Building. Can I take one or two questions, maybe? Yeah. Yeah. So just whoever shouts first and loudest. How will we really bring the third arm center upon the kid that's in there, that will change when we go to like source RPMs and we're not going to go there and work with them, correct? And how will that affect the part B of the question, how will that affect the portal and the cycle? So there are three parts to that question. One is the easiest to answer, which is how does it affect scientific Linux? So the question is that if ftp.redhat.com goes away and the SRPMs go away, then how do people who consume it today get what they want to get, right? So as far as Oracle is concerned, you'll have to ask Oracle. As far as scientific Linux is concerned, we've been talking to them pretty much from day one to see how we could help them, how we could get a better relationship in place. And they have had a bunch of questions we've been able to answer, and I think the ball is firmly and totally in their court. We've made it open like, hey, you can come in and you can do whatever you want, however you want, but do it as a part of the Centros project, do it within an inclusive framework so that there's more people working on the same problem rather than a lot of people working on the same problem in different places and basically duplicating effort. So we're most welcome to come in, take what they want and do whatever else they want. They're most welcome to bring whatever else they want and build it in-house and just be more inclusive. While we take the next question, I'll try and see if I can get a slide up that shows you what the Git repositories will look like. Go on. So the question is about how SIGs will deliver content. So the owners of content delivery is going to be up to the SIG to decide. So they can either have their own repository and they can have a release file which is available within Centros Extras. Yes. But they also have the ability to actually rebuild all of Centros including their applications and deliver an ISO. Excellent. So there's basically some injuries that you're carrying out from your ClareOS days. One more. So I think rather than, okay, why don't you shoot your question? So the question is if you were able to carry on doing what you're doing with Centros Linux today. So as long as you're not violating terms of licenses that the stuff is distributed under, you're fine. And if you're commercializing stuff, then there may be some trademark issues that come in. But I mean, why in large, if you're doing what you're doing today, you should be fine. Right. So that's right. So Centros Linux will exist as it is today. So just quickly, just about the Git repository. So this is kind of like what it's going to look like. Every Git repository will have hard-wired branches. There's nothing in master except for a readme that says there's nothing in master. The C5C67 branches represent the code that is available in there. We have the C5C6 plus stuff. There is C4 for those of you who like to live in pain. What the opportunity that will exist over here is that anybody will be able to log on and create their own branches. You will not be able to write into C5C6C7, but you will be able to create your own branches and you'll be able to track those branches. Within a branch, it'll look kind of like this. Hopefully not with my name on it everywhere. So you basically got every release that comes through as a commit, as a complete commit. And within that, you have the text sources for, I mean, so whatever was in there. Whatever is not in here was represented in a metadata file which looks like this, which has the names of the files, the SHA256 sums, or what the software basically corresponds with, and the content is available on Locosite Cache. So you'll basically still be able to track the content. You'll still be able to track the metadata that comes out of the SRPMs, but you'll be able to consume it as a Git format, so it's easier to use. And there's a script around as well that just basically takes one of these with a name and gives you an SRPM in return. So guys, I'm sure if you have questions, come and find me. I'm going to be at the CentOS table for the rest of the day today and most of tomorrow. And thank you very much for coming along. Thank you.
 You  Okay, how about that?  Let me see, is that?  Okay, I guess we go to kick off.  How many people here know what Santos is?  That's half of my talk, no longer needed.  How many people here know who or what red hat is?  Excellent, that's the second half of my talk done.  I'll still try and go through it, since everybody's come.  You guys have made all the effort.  There's just two constraints that I'm talking under.  One is that I have a cold, and I don't know why.  I always seem to get a phosdome cold.  The second problem, which is a bigger problem, is that I've only had three beers in the last  four days.  Please bear with me as I try and struggle through the talk.  Immediately after the talk, yes.  Let me see if this works.  I guess most people, if you know about Santos, you've either heard about me or who I am,  or either you like me or more likely you don't like me.  Just a bit of a brief introduction about me.  I started off with Linux back when you still needed 44 floppies, and CD-ROMs were just  about making their entrance in.  I used Slackware for a while, I used Gen2 for a while, I used Debian for a while.  Moved on to Red Hat, I think 4.4, Red Hat 5, 6, 7, 8.  I then couldn't really go anywhere from there.  I found the Santos project, or other some people from the Santos project found me.  I wasn't one of the founders, but I showed up fairly early in the game just to point  out how everybody was doing everything wrong.  Unfortunately, they punished me by letting me do things.  I'm still here, 10 years down the road, still telling people how they're wrong, still hopefully  trying to fix stuff.  Professionally, I've been a sysadmin, I've been a developer, I've been a manager, I've  done data warehousing, I've done cloud operations, please don't hold that against me.  I worked for hosting companies again, please don't hold that against me.  As of a couple of weeks ago, I'm not entirely sure what I do.  My job title is a member of technical staff.  I guess that's an easy way for them to put me somewhere and not have to worry about finding  me a title that actually means anything.  I'm a straighter to the UK, I've been there for about 15 years now, I quite like it, although  I prefer Belgian beers.  One point I always try and make is that there are two really sides to the CentOS story.  There's a CentOS Linux distribution, which I guess most people are familiar with because  that's what most people consume, that's what the interface into the project has been.  But there's a very real, a very tangible, a very quantifiable entity behind the Linux  distribution called the CentOS project.  It's hard to see, it's been hard to perceive, it's been hard to quantify because we don't  exist as a legal entity or we haven't existed as a legal entity.  There hasn't really been a target that people could point at and say, this is the CentOS  project or this is the privilege escalation process or whatever.  But the entity exists, whether it has been completely voluntary driven by sponsors, driven  by donors, people helping us out.  And the community of users as well, all of that contributes into being the CentOS project.  And it's quite important now, especially in the new context of the Red Hat announcement,  that people think about CentOS Linux as being just one of the things that the project does.  The Red Hat relationship is something that got announced recently, but if you really  think back, the Red Hat relationship has always existed pretty much as long as the CentOS  Linux distribution has existed.  Let me point it out this way.  There are a couple of 10th anniversaries going on at this moment in time.  It's been about 10 years since Rally came about, it's been about 10 years since the  Fedora project came around.  You'd probably see the Fedora guys wearing T-shirts saying 10 years.  It's also been about 10 years since the CentOS project started off.  You'd almost think there was a coincidence, right?  That there was something related in there.  And then there is.  And the relationship has been focused around what Red Hat is doing with the Red Hat Enterprise  Linux product and how they kind of migrated from the traditional or the old school Red  Hat Linux to Red Hat Enterprise Linux and how Fedora came up.  And I guess since most people are aware of CentOS, you guys know what we do and why we  exist, right?  So we don't need to kind of go into that.  But the important thing is that the relationship has always existed.  So early last year when my phone rang one day, I picked up the phone and it was a couple  of people from Red Hat legal on the phone on the other side.  It was, I was like, hello.  What can I do for you?  It was a strange relationship.  It was a strange conversation to have because although the relationship has always existed,  the conversations have always been in the corridors of FOSDOM or corridors of various  conferences and events and sometimes conversations on Bugzilla, sometimes conversations on IRC.  There hasn't really been a formal conversation with Red Hat.  But when the conversation started off, it was easy to see how much of what we were doing  sort of lined up with what they were trying to do and how much of what our wish list  was shared by a certain set of people within the Red Hat organization as well, which is  what led to the whole idea of, hey, maybe we should think about doing this together.  Maybe we should think about breaking down some of the firewalls.  Maybe we should think about trying to bring Red Hat on board with the Centros project  to try and see how they could sponsor, how they could curate the ecosystem in a slightly  more sort of professional, in a better managed kind of a process.  So there's two things that are important there.  Firstly, it was Red Hat as an organization that has come to join the Centros community.  Although it's very clear, you know, you should be under no doubt about the fact that they  said this is an acquisition.  Red Hat has acquired the Centros project.  The trademarks that we've registered for Centros are now curated and maintained by the Red  Hat legal team.  The terms and conditions that we operate under are terms that are set by the Red Hat legal  team.  So there should be no confusion about the fact that the Centros is very much a part of the  Red Hat ecosystem that is curated by the Red Hat nominated people.  However, from the community side of things, it is still from the Centros project side  of things.  So it is very much a case of Red Hat joining the effort rather than Centros folding into  what they already had in mind.  And what we've done to kind of highlight that is that there's a governance body that has  come up, which is primarily composed of the existing Centros core team as it were.  And there's an escalation process that has come up that allows pretty much anybody to  come in and be a part of that team and basically go from being a user to a contributor to a  build person if you want.  And if you guys are really interested and motivated, there are opportunities to join  the Centros board as well and be a part of the decision making process.  So the important thing is that the relationship existed, it always has done, and we've now  been able to solidify that.  So what is it that has really happened here?  A couple of things I've already mentioned, the Centros trademarks have transferred over  to Red Hat legal.  There are some subtle changes that also have happened around the edges.  Centros has by design been built and released out of the EU for a period of time.  That changes.  This is now very much delivered out of the US.  It's delivered out of a Red Hat machine, which is technically and realistically the only  change that has really happened within the Centros infrastructure, that there's a machine  that is owned by Red Hat that has now become the primary cedar.  And there were a couple of conversations on the mailing lists about, hey, does that mean  we now subject to US jurisdiction?  Does that mean that we now subject to US trade laws?  And the interesting thing is that we've always been subject to those.  It's just that by building and releasing in the EU, we may have been able to do a bit  of an ostrich deal, where if you dig your head far enough into the sand, you don't see  the guy who's going to come and beat you up.  And I think we've been lucky that the guy just never showed up.  People tried that have been where legal situations that came up and things, and we were just  lucky that none of them really unfolded into anything too drastic.  But yes, we are constrained by what is legal and what isn't legal in the US.  And in terms of export control, we have always been a part of our, we've always been subject  to the US laws because we've only consumed content that came out of the US anyway.  So if you really think about it, we haven't been doing stuff, we haven't been consuming  stuff, we haven't been pushing stuff that hasn't otherwise been exported from the US.  So we've always been subject to those.  It's just that those things are slightly easier to see.  The other big thing that has happened is there's a governance body that has come up with a mandate.  Sorry, there's a question at the back shore.  Yeah, so the question is that Fedora and Rural have terms which specifically forbid you from  using them in infrastructure that builds rockets.  So I think there are two parts, so there's two ways to analyze that.  I highly recommend you write that question, send it to me on an email, and I'll get a  lawyer to reply to you so that we can quantify it.  I'm not a lawyer and I don't speak for Red Hat when I say this, but I think there are  two ways you need to look at that.  Firstly, are you violating the GPL by doing so?  Secondly, are you using content which is otherwise restricted for export by the US?  So not in terms of application, but in terms of content.  So if you're not, then that's a guideline that you could use, and based on that you  should probably send me an email and I will get a lawyer to reply to you.  So you know, privately, this has been one of the fantastic things that has happened here.  There are lawyers that I can actually ask questions to and not have to wait six months  to a year before I get a reply, because so far we can't afford lawyers, right?  And we've been very lucky to have people like Andrew Katz and a couple of guys in the US  from the SFLC who've helped us out for a long time.  But then you ask somebody a question, he's a lawyer, he's got customers, he's got clients,  he's going to work with them first.  So six months to a year is usually when we used to expect replies.  Now there's a legal team I can actually ask a question to, which is fantastic.  A lot of the constraints that we've had to work with in the past as well, things like,  hey, do we create a firewall between us and Red Hat?  And then how do we extend that firewall to the customers and Red Hat?  And then how do we extend that firewall even beyond that to users of CentOS, to the customers  of Red Hat, to Red Hat, and to us?  A lot of those questions we had to be very pedantic about, we had to be very, very, very,  pessimistic about, and a lot of the processes that we had, things like a private QA process,  things like, if you find a Red Hat brand somewhere, we would have to go back and purge that brand  from everything CentOS, things like that.  A lot of those situations are no longer as big a deal as they used to be because we have  access to people at Red Hat Legal that we can ask to quantify the issue.  So if somebody finds, hey, I found something in here that says that this is the man page  for Bash for the Red Hat Enterprise Linux.  Does that mean what I'm running is Red Hat Enterprise Linux?  We can go back to a legal guy and say, hey, can that question be interpreted to mean what  the guy thinks, the question that he's asking?  And if they say yes or no, we will take action to that.  But in many cases, I think what has happened in conversations with them is a lot of the  stuff that we were doing was overly pessimistic.  We did not need to be that pessimistic.  And I think, I still think that what we did was the right way of doing it because we were  able to assure something.  We were able to say that, hey, because we've taken these steps, we know that we've tried  to protect the users to a certain extent.  It may be that what we did was more than what was required.  But having done what we did, we were at least sure that we've been able to protect those  people against those things.  Does that cover the scope of the question that you were asking?  Absolutely.  So the other thing that is also happening here as a part of the what is that Red Hat  actually offered the core contributors as it were to the CentOS project jobs at Red Hat  to say.  And they made an offer to quite a few people saying, would you guys like to come and work  on the CentOS project as a part of your full-time job responsible for the CentOS project?  Some of us took it up.  I did.  I took it up.  I thought it was a great opportunity.  A couple of the other guys did as well.  Some people said no.  And the guys who said no have not been penalized.  Some people kind of thought it had happened on the mailing list as well that to be a part  of the process you had to be on the Red Hat team and that's not true.  We've got people on the CentOS board.  We've got people in the CentOS QA teams to build, set up the infrastructure teams who  don't work for Red Hat, who don't want to work for Red Hat and that's fine.  And there is no infrastructure within the project that they don't have access to.  There are no terms that they have to work under.  There are no contributor license agreements that they've had to agree to.  The meritocracy that we've been able to build up over the years for privilege escalation  stays in place.  So if you join the mailing list and you're able to prove that you're good at what you  do and you get invited to be a part of a team where you can do something about it, you're  welcome to be a part of the team and not working for Red Hat is not a penalty.  So why are we doing this?  I think in many ways, in many ways, this is actually a natural progression and I guess  the question would be why we didn't do it sooner.  We would have liked to have done it sooner but we never knew how to approach Red Hat.  So we had to wait for them to make the approach.  We had to wait for them to come across and say, would you like to come and do this thing?  And the larger problem that we're trying to solve is that the CentOS community exists  as a very specific, as a very special group of people.  The CentOS community is primarily user-driven rather than developer-driven, which is again  unlike a lot of open source projects.  The CentOS community is not feature-led.  It's more problem-led.  More people want to make changes because of problems that they face rather than features  that they dreamt of yesterday night.  Like, hey, this is a great feature.  Maybe I should write some code for it.  And if you look through the bug.centos.org site, you will find that there are very few  feature-led issues that come up and 99% almost of the stuff that comes up is problem-led.  If you look at the conversations that come up on the mailing list, they are problem-led.  And that's a great place to be.  It means that people are actually using this stuff and they're hoping to fix problems that  they actually have in real life rather than a developer-led group who tend to be more  aggressive on creating new features, creating more special branches, being able to deliver  more value, whatever it is, through code.  And I don't hold that against developers.  How many people over here consider themselves to be developers?  How many of you consider yourself to not be primarily a developer?  So here's the point.  This is still a majority.  It's a very thin majority, I have to admit.  It's a lot thinner than I thought it would be, but it's still a majority.  And that's an interesting place to be because what happens is that if you're able to now  deliver stuff to these people, if you're able to deliver stuff to problem domains that we  were in ourselves, then we may be able to actually create value around applications  better and faster than a developer-led community would be.  Does that kind of make sense?  Does anybody have questions around that particular point?  Not yet?  Yeah?  That's a question.  Yeah, upstream first.  We've always tried to stick to that.  Yes.  I guess it depends on what you're trying to upstream.  If it's somebody on OpenStack, then perhaps they should go further up than Fedora as well.  If it's a kernel issue, then perhaps Fedora, whatever.  So when is all of this stuff happening?  I guess you guys have already seen the announcement.  Is there anybody here who doesn't know about the Red Hat-Sentos relationship?  So this one person, we must all help him.  We must all tell him what has happened here.  So last year, early last year, the Red Hat people got in touch with us saying, we understand  it's a relationship here.  You consume our code.  You produce something based on our code.  What can we do together?  How can we set up a relationship that works in a way that we're just better able to curate  the Sentos community at large and be able to expand the scope of what you guys do?  And on the 7th of January this year, Red Hat and Sentos announced that we were joining forces.  And it's a very interesting term because it's not a partnership.  It's not an acquisition as such.  It's actually a case of joining forces where the Sentos project carries on doing what we're  doing and Red Hat is able to come in as a sponsor to help do more.  But there's now a formal relationship that exists between the Sentos project and Red  Hat and Sentos Linux and Red Hat Enterprise Linux.  Does that make sense?  Okay, right.  So now everybody knows what's going on.  What we tried to do was that when you were working through the mechanics of what was  going to happen, a lot of people at Red Hat were very anxious.  A lot of people from the Sentos community or the contributor bases who were involved  were very anxious to see, hey, what is this going to really mean?  Does this mean a mailing list has to be set up?  Does it mean something weird has to happen around the edges?  What are the processes going to be like?  Who's going to be running the systems?  Who's going to be running the gate repositories?  And how are all of these things going to be happening?  Hi, John.  I'm actually fine to just stay with this.  If you don't.  Okay.  Should we swap at that point?  Or you want to swap now?  Yeah, let's do it then.  Especially the guys with the legal hats on, especially the guys with the trademarks and  the whole community managers, and they were all very keen on saying, hey, we should have  process in place.  When we go out and announce, we should be able to tell the world that this is how we're  going to do what we're going to do.  We were very keen from the Sentos side of things that we did not pre-agree to anything.  Obviously, it wasn't going to be that clean.  We had to agree to being able to do a certain set of things.  We had to agree to some of the paperwork being signed and stuff like that.  But what we have done is that we've agreed in principle to have conversations around  processes.  We've agreed on paper to have conversations in the public forums about how we change what  we change.  We've agreed that Red Hat will bring their people in.  We will have open, wide communication channels available to anybody and everybody who wants  to participate as we adopt new standards, new systems, new processes around whatever  we do.  Those conversations are starting off now.  Nothing around those conversations is actually decided.  So when you see the questions being asked on the Sentos developed, those are genuine  questions.  There are no pre-decided answers to those questions.  Please participate.  Please join in.  Become a part of the process.  And all of those opportunities exist now.  And I can't stress enough that most of the stuff that you're about to see, most of the  things that you're about to see in terms of the special interest groups, the variants,  how the process is going to work, how the engineering is going to work, are all proposals  at this stage.  Nothing is actually decided.  And anybody and everybody is welcome to come along, be a part of the process that decides  what we're going to be doing and how we're going to be doing it.  One of the big things that's, of course, going to happen is that there were three terms,  like which took a committee about a week to decide how to come up with as things do.  So the thing was, what are we trying to do?  We're trying to be more open.  We're trying to be bigger.  And we're trying to be more inclusive.  That makes sense, right, to everybody.  Does that make sense?  Not really.  Okay, good.  Because, yeah, buzzwording doesn't really mean a lot in itself.  So what we really want to do is, let me step back a minute and let me quantify something  that isn't changing.  What isn't changing is that CentOS Linux is not going away.  CentOS Linux is rebuilt from rel sources that are released publicly.  That is not going to change.  That is going to carry on doing what it's going to be doing.  We may not get much better, but we will certainly not get any worse.  And we may not get much better because the organizations at Red Hat that we're working  with are the open source and standards groups.  We're not working with the Red Hat engineering guys.  We're not working with the RHCL engineering business units.  We're not working with the product side of things.  We are very much working with the open source and standards group.  So we may not have the opportunity to know when rel 7 is coming, for example.  But when it does happen, when it does come through, we will actually get the sources  at the same time as everybody else does.  And the big thing that's going to be facilitating that is that Red Hat is going to stop publishing  sources on ftp.redhat.com.  And all sources will actually be released through git.centos.org.  In a format that is easier to consume, it's easier for more people to come in and participate  in.  It's easier for people to run their own branches.  It's easier for people to run their own variants of the same builds.  But the core builds will not go away.  So what you consume today as CentOS Linux will stay in place and you'll still be able to  consume it just as you do today.  So with that, what is not changing in mind, what we are going to try and do is try and  become more open and more inclusive.  So the plan is that we produce the CentOS Linux base, but we create opportunities for people  to come in and create their variants.  And this is something which has been happening for a very long time.  If you look at the Wipe industry, for example, if you look at the open source communities  and in the Wipe ecosystem as it were, there's always been a CentOS rebuild which has carried  a Wipe stack on it.  Sometimes it's been 2, 3, 4, at this time there may be 100.  There's always been repositories of people sort of trying to add functionality to what  we do in CentOS.  There's always been sort of live CD variants out there.  There's always been people doing things like a high performance specific build.  There's been a minimal installer, a high performance file system installer.  Various projects have been able to take stuff away.  I don't know how many people are at the dojo yesterday, but the Morantis guys were there  yesterday.  And they were talking about how they consume CentOS internally to roll out the open stack  platform.  And I think there's something like 11 or 12 different open stack installations or open  stack distributions which don't do a lot more compared to each other.  And they all consume CentOS internally.  So one of the things that we want to do is make it possible for those guys to come on  board, be a part of the CentOS.org group and be able to consume what we produce while still  extending things in interesting kind of ways.  And how we want to organize these groups is in terms of special interest groups.  It could be one person.  It could be 100 people.  All you need to do is find a reason for an interest group to exist.  And what we say is that while we're open to accepting pretty much anybody and anything,  it would be nice if the special interest group is driven by a problem domain.  It should be driven by user requirement and not a technical requirement.  So for example, we would prefer to have a cloud SIG or a cloud instance SIG rather than  a SIG which builds VMware images.  Is that quantification kind of clear?  So it's like if you want to have a special build of, let's say, open JDK, then you're  more likely to have a SIG proposal pushed through if it was because it's needed to run  version 76 of Eclipse rather than, hey, I want to do this because I want a newer version  or a different version of Java in there.  So that's the only thing that we kind of point at that look.  Do it from a user perspective.  Find a problem domain.  Find what issue you're trying to solve.  And then we can work on the mechanics required to solve it.  And every SIG can target one of four things.  You can either have your own repository hosted within centOS.org where you can build your  own packages.  You can build packages and contribute them into CentOS extras so that they're available  to all CentOS users.  Or you can take the CentOS distribution and you can build a variant of it.  So you say, hey, I want these packages.  I don't want those packages.  I want these things to be pre-configured.  I want those things to be not pre-configured.  And you can build a variant.  Or you can target something which is based off CentOS.  So if, for example, you want to be building an Asterix distribution which changes some  fundamental things, then you can still do so.  And you can call it, you know, my great Asterix distribution and it's based off CentOS.  And that's available to any SIG to target.  And SIGs can target multiple things.  I know the Cloud SIGs are planning to do multiple things where you can have, so you  can have, for example, you'll be able to YAM install OpenStack.  But you'll also be able to get a live CD which has OpenStack or CloudStack pre-installed  on it.  And you'll still be able to get images and things like that.  So you can target multiple things.  The other big one from the SIGs is that while SIGs are specific, there is a lot of cross-pollination  between SIGs.  So we've got a SIG coming up, for example, for the Word group where we've got a Zen  stack working on CentOS 6.  And we've already started having conversations of how the Cloud SIG could work with those  guys to consume the Zen for CentOS content under OpenStack to make Zen be a primary partner  under OpenStack, right?  So you don't stack to KVM for that matter.  And that's something that's also encouraged.  Let me see if this works.  Yeah.  So how we're planning to make SIGs work is that a group of people can come together.  You can get onto the CentOS development mailing list.  You can propose a SIG.  The SIG proposal gets in.  You get access to build packages.  And then as your SIG matures, you get more features.  You get more resources.  And you can do more things on your own.  So when you initially join up, you may have to say, hey, this is my source.  This is my spec.  What do you think of this?  And we will import it for you.  If you can prove over two or three months' time that you know what you're doing, we'll  just give you direct Git commit access to the main repositories on Git.CentOS.org.  Hi, Tanya.  I wonder if in the criteria to actually grant that the fact that that SIG should be inclusive,  that means other people wanting to actually join that specific development should be about  to do that.  So that we don't get something which is special proposals for, say, one company or one something  and other are allowed to join in.  So the question is that Git access should be available to everybody.  So I think the plan on how to address that is that we will mirror everything from Git.CentOS.org  onto GitHub and onto Git.Orious.  And we've been talking to both GitHub.com and the Git.Orious guys to see how we can  create those replicas.  Because primarily the challenges that the Git repositories for CentOS 5.6 and 7 put together  are about 2.3 terabytes at the moment.  Sorry.  There's a phone somewhere.  Let's just ignore that.  It's somewhere in my bag.  And I'm sorry.  So the challenge also becomes that at what point do you acknowledge that a particular user has  the authority to represent a user base?  Fine.  I will actually try and find it.  Hang on.  That's convenient, isn't it?  Let's hope that does not happen again.  Right.  So the challenge is like if, for example, there's a virtualization group together, then at what  time and at what point do you decide that anybody who's come along should have the privileges  to change other people's code unless that person has demonstrated either within CentOS  or within that community that they know what they're doing.  So it's a double-edged kind of a thing.  So there is still a slight barrier to entry.  But because the GitHub process is inclusive, it works.  And because we're going to try and make sure that there's enough people who can do that bridging,  we'll try and get to a point where pull requests don't wait, for example, for more than 48 hours.  We'll try and make sure that the process is always churning.  We might be able to address it in that manner.  So as the SIG kind of matures, you get more resources.  And it goes all the way from initially having to propose the sources and what you want to do to a point  where you get your own Git commit access to a point where you can then start requesting signatures  for your packages to a point where you can actually start signing your packages.  Within CentOS or DOG, to a point where you can actually start doing your own releases within CentOS or DOG.  So you can decide as a SIG that, hey, we need to do a release of the entire OS.  And I want to branch it and say, hey, this is going to be the open stack on CentOS.  And I want to do a release next Tuesday.  You will be able to do that within the tools and the constraints that are available within CentOS or DOG  without needing somebody from, let's say, the governance group or the core SIG or something like that to come across  and push a button.  You'll be able to request it yourself.  So the plan is that it goes right all the way from zero to pretty much being able to run your own little micro distribution  within CentOS or DOG on your own.  It's a good goal to get to.  I hope we're able to get there.  The processes of how we get there are being discussed right now.  So if you want to be a part of it, please jump in and start contributing.  Start owning parts of it if you want.  The second part of it, and this is something that we have to argue with a lot of people for a very long period of time,  is that we wanted to be inclusive content.  So content that we push should not be restricted by policy.  It should be restricted by licensing, and it should be restricted by copyright terms.  So for example, if somebody has a piece of code that they don't want to open source, but they make it available for redistribution,  then what we are doing technically is redistribution.  And if the community wants to adopt that code, we should be able to adopt it.  And it's something that we've been working on for maybe about almost two years,  and it's good that having Red Hat on board, we've been able to fast track that process and accept it in.  To give you an example of what kind of stuff I'm talking about, it's things like the NVIDIA CUDA drivers, for example.  Or perhaps it could be the Intel Compiler Collection Build content, which otherwise isn't open source.  But we may be able to talk to those guys, we may be able to get something from them to say, hey, this is fine,  send us as a project, you guys are okay to redistribute this.  We will carry that content.  So it's actually going to be a lot more inclusive than it's ever been before.  And the content is restricted by legality and licensing rather than policy.  So it shouldn't be, hey, we will only accept code if the name of the project starts with A.  That's just silly.  Does anybody have any questions around that?  Does anybody have any issues or doubts about that?  No? Good.  Is that a good thing to do, I guess?  Is that a bad thing to do?  It's good, yeah.  So what's happening right now in the six?  When we announced the whole thing on the seventh of Jan, I remember having a chat on the sixth with a couple of the other guys saying,  I don't really know, the CentOS user base has been extremely passive in the past.  I don't really know how this idea is going to go down.  But if we were able to get one SIG on board in the first month, and if we were able to do one release,  or we were able to deliver one thing within the first two months, that would be a fantastic place to be.  It would set a precedent.  It would allow us to grow.  It would allow us to attract other people into the projects as well.  I believe within the first 48 hours, we had 19 SIG proposals.  And within the first two weeks, we had formalized on three other SIGs.  Yesterday, is anybody here who was at the Dojo yesterday as well?  There are a few people.  So we actually did delivery.  So we built images for OpenStack, for CloudStack, for Eucalyptus, and for OpenNebula,  and for Overt, and for Docker, and for LX containers.  During a four-hour hackathon, we were able to test them.  We were able to stage them for release.  And first thing on Monday morning, you'll see the announcements going out for the images that we were able to build.  So we've actually achieved our first ballpoint, our release point within, I would say, three weeks, which is a great place to be.  The entire tooling that has made this happen has come up in the last two weeks.  The entire release process that has come up has come up in the last two weeks.  And it's completely inclusive.  All of the scripts, all of the code, everything is public.  You can go, you can fork it, you can start contributing right now.  So this is just like sort of an overview of some of the SIGs that are coming together.  The CloudSIG, I think I mentioned that a few times, which has been really good.  We've got Eucalyptus, OpenStack, OpenNebula, and CloudStack, and the Overt communities who have all come on board.  There are some hard questions that are being floated around at the moment.  There are some hard answers that we need to find as to what the value is for multiple cloud infrastructure guys to be working together in one group,  or whether the CloudStack guys want to be delivering their own thing, or whether the Eucer guys want to be doing their own thing.  And hopefully, given the fact that we're expanding the ecosystem, hopefully given the fact that the SEF guys and the Gluster guys want to run the storage side of things,  given the fact that the Zen guys want to come in with the Zen code,  given the fact that the Docker guys want to get involved with the Docker containerization stuff,  we're able to build enough of an ecosystem that there is value in everybody working together.  Every cloud instance that comes up really is a bunch of yum installs,  followed by either a puppet run or a chef run or a non-sable run or some sort of configuration management thing, right?  Yet, every one of those guys maintains their own version of puppet.  They all maintain their own version of chef.  They've all got their own packaging around Ansible.  They've all got their own playbooks.  They've got their own configuration metadata.  They all consume Gluster in a slightly different way.  They all consume LibWord in a slightly different kind of way.  And the real win from working together is going to be if we're able to consolidate some of these things.  And I'm hoping we're able to do this more at a developer level rather than a vendor and an association level.  But that may be a wishful thinking. We will see.  I think six months from now, we'll know exactly where we are.  The cloud instance has also been very active.  I think I've kind of covered that.  We've built a unified image.  It's the same image which works across all of those platforms that we've been able to deliver.  We're not doing any tracking and updating at the moment because we haven't done the release.  Hopefully that will happen on Monday and then becomes a big challenge as to how we keep it updated across various ecosystems.  And again, how we do it, when we do it, what the process will be is open for discussion.  Please jump right in if that's something that you're interested in.  Just a quick run through of some of the other guys.  The word sync is coming together.  I believe we've got Zen on there.  I'm not sure if I'm allowed to commit you to being on there, but I'll go ahead and say that Zen is on there.  The storage sync is coming together.  We've got the SAF guys working with us.  We've got the GlusterFS guys working with us.  And the aim is that we deliver a unified repository which contains common metadata.  So for example, QEMU needs certain options in place for the SAF backend storage system to work.  Gluster needs certain patches to go into QEMU.  And what we really want to do is have one QEMU which does both of those and also works with whatever LibWord we end up shipping as a part of the word sync process.  Hopefully people will see that as a good way.  And the fact that we've got traction from the upstream developers to be able to do this is, I think, a great place to be.  We do ship a minimal ISO.  I guess, does everybody know about the minimal ISO?  And it is, I think it's quite minimal.  It doesn't even have open SSH clients.  It doesn't have Kron in it, for example.  But apparently that's still a very fat ISO.  So if there's a sync that has come together with the aim of having a CentOS install base which is only 90 packages or less, and it's only 250 megabytes or less, I wish them all the best of luck.  I will be around to do the tooling for them.  I will try not contributing too far into that.  But it's a problem that they see.  If there's a problem they want to solve, they're welcome to do so.  We've got the SME guys, the SME server guys, NET server.  We've got the clear OS guys who all want to come together and try and see how they can unify, how they can share code about building a common SME home server kind of a thing.  It's something that, it's a demographic that I don't really understand very well.  But I don't.  So I mean, the last time I worked on that scale was probably back in 97, 98.  Because, so you see, there are two parts of it, right?  Either you work in the IT services industry or you work in the consumer industry.  And I think that's the kind of demographic which is more consumer side.  And it's just that since the late 90s I worked more on the services side.  So it's a demographic that I don't really understand very well.  But obviously there's a lot of people who have use for it.  A lot of people have utility for it.  So, you know, these guys are coming together.  And I think it's great because in many ways clear OS has been seen as a competitor to CentOS.  The NET server efforts have been seen as a competitor to CentOS.  The fact that we can bring these guys in, the fact that we can bring the SME server guys back in to the project.  So we all share codes, we can share some of the features, we can share some of the wins as well.  I think it's a great place to be.  The white guys are coming together.  There's a bunch of people around various things, the free PBX guys, the Asterix guys are all working on the stuff.  I was talking earlier today to somebody and then a couple of days ago as well about people talking about a super secure version of CentOS.  I don't know what that means again.  But I think it's a case of, you know, ciphers which they prefer being enabled by default and stuff like that.  We have the mechanics in place that allows them to fork pretty much every package, rebuild every package that they want to and run it with that.  There's an app hosting sake that is also coming together which is to deliver a very minimal CentOS with an installer that has the ability to arbitrarily add other content into the installer.  So if you've got a project, if you've got, let's say, you're writing a piece of software which helps people get rich quick,  then you want to ship it on CentOS, then you don't have to rebuild the whole thing.  You just download this ISO, you dump your content into a directory, you create a com.src.xml file which has to have a specific name,  you MKIS or FS and you have an installer for your software.  Which is again, I think, hopefully should get a lot of attraction.  And there's a bunch of people coming together around the scientific idea as well about building scientific applications.  We've got the Imperial College guys in the UK who've offered to come in and do a lot of software.  We've got a couple of government agencies in New Zealand who've actually already been working on a repository with us.  It's just easy enough for us to do this as a part of a SIG and that's about 400 different applications in the scientific scale of things.  And there's many other conversations going on around the edges as well.  So if there's something people are interested in, you guys are interested in, jump right in, the opportunity exists.  It's not going to go away but it's nice if you get involved early because then that allows you to have ownership over the processes that we end up adopting.  You can be more a part of how we end up shaping up everything else that is going to come further down.  There is one special SIG though that is also coming up called the Centros Core SIG.  And this represents what used to be the old Centros project.  The people in the Core SIG are the people who were a part of the Build Europe and the core admin team of what used to exist in Centros earlier.  There's been a few changes but by and large the mandate for the Core SIG is to deliver the Centros Linux distribution.  So these are the guys who are going to be focusing on that.  The opportunities for privilege, escalation into the Core SIG are just the same as any other SIG.  So there's no differences in that.  But the Core SIG also does certain other things like we'll be responsible for running the infrastructure, making sure we don't get hacked, making sure the website is updated.  So who's seeing the new website?  It's great, isn't it?  It only took us like eight years to get there but we did get there finally.  And it doesn't hurt your eyes anymore, which is always a good thing.  So the Core SIG is responsible for things like the website, we're responsible for running the infrastructure behind the wiki, running the infrastructure behind the bugs instance, running the mirror lists and all of that kind of stuff.  Again, all of the code goes public, all of the build scripts are public, all of the metadata around that stuff is public.  If you're interested in these sort of things and if you have a minute, I'm happy to do a demo of how we're building Centros 7 as well.  That's the Core SIG and it's important because the Core SIG essentially works within the constraints that any other SIG would and they work with any of the privileges that any other SIG would.  And it's just that what they do is defined.  So while other SIGs can be, oh, we'll do this today, we'll do that tomorrow, the Core SIG is focused on only doing one thing and that is delivering the Centros Linux distribution and then maintaining the infrastructure around it.  The point that I want to also make over here, I realized that, or I thought initially that we'd have a lot of people from other distributions coming along to say, what the hell are these guys on about?  And I'm not sure if they are.  But one of the things that we worked on quite hard, at least I've personally worked on quite hard over the last four to five years is building distribution relationships.  And I'm hoping to be able to do that even more.  I'm hoping to be able to expand the scope of what we've been able to do in the past.  And I'm hoping to sort of fast track a bunch of conversations that have been going on.  And an easy example of that is this is interesting new thing that we all love and we all enjoy.  It's called UEFI and Secure Boot.  It so happened that Centros 6.2 when we shipped it out, did not work on machines which did not have a BIOS failback.  So this doesn't mean machines which don't have BIOS support.  This is machines that didn't have BIOS failback because we had a partially enabled EFI support in the ISO.  We didn't find out until three months after we released it.  So that clearly indicates how popular that particular option is.  But when we did find out and when we looked at how deep and what the implications were, we were like, there is no way that we would be able to afford the infrastructure or the equipment to be able to prove ourselves.  So we went out and spoke to the guys at Intel.  I believe the PSG, the professional services group at Intel, the guys who write this specification for the UEFI.  And we got the Debian project in because the Debian project was exactly in the same situation.  I was able to reach out to the Gen2 project.  I was able to bring them in.  And they were very happy that somebody was actually talking to them from a different project.  We were able to bring a couple of other distributions.  I believe the ArcLinux guys are also now using the same infrastructure and I believe the Mint Linux guys are also using a part of the same infrastructure.  And we were able to bring a couple of demo machines in.  We were able to bring in the development firm words in, hosted in a common area at the OSL in the US.  And we've now set up a Google calendar where various different projects can use that infrastructure to prove that their software actually works with UEFI.  The next step that I'm hoping to be able to do in April-May timeframe is to solve the secure boot problem as well to see how we as a community of Linux distributions can address that issue and what the scope of that is as well.  A second example of this whole cooperation has also been that IBM PowerPC is quite hard to find.  Yet everybody wants to target it.  And again, in the summer of 2012, we were able to reach out with, as a group basically, of the CentOS project, the Debian project, the Gen2 project.  And we were able to reach out to the IBM community outreach guys in the US.  We got on about five Power7R2 machines, which are again shared between a bunch of projects, including the Postgres guys now as well.  And I think the Gen2 project is also using the same infrastructure that hosted on a common platform that is facilitated by the CentOS project.  And I'm really confident that we want to try and accelerate a lot of these projects to bring more resources in, more efforts in.  The project that I'm working on right now that I'm hoping to accelerate is to be able to bring ARM infrastructure in as well.  We've got something up that is that kind of works.  But it's harder to bootstrap on ARM.  And I'm hoping to be able to bring ARM 32 and ARM 64, ARM V7 and V8 infrastructure out.  We're talking to Boston electronics.  We're talking to internet works, penguin computing.  We were talking to CalCEDA.  Unfortunately, that conversation had a bit of an abrupt ending.  Okay, so I'm guessing not a lot of people know that CalCEDA is...  How many people here know about CalCEDA?  Okay, so a few people.  So how many people know that they're in a bit of trouble at the moment?  Okay, so everybody does. That's fine.  So we're hoping to be able to accelerate a lot of those processes as well.  And the second thing that I'm also hoping to be able to do is something I mentioned previously,  that we have like the cloud stack guys, we have the open stack guys, we have the open Nebula guys, the eucalyptus guys coming in.  It would be fantastic if we could, at a developer level, agree to support a particular version of LibWord for a year, year and a half.  That allows other people to target the same pieces of software as well.  And therefore, it's not only us who gain, but it's the entire ecosystem around those projects.  It's all the other distributions around those projects which also gain from having that resource available.  And then finally, our test harnesses that we've been working on quite hard for many years.  I mean, we would love to be able to open that up and allow other distributions to be able to use it as well.  And we're trying to come up with scenarios as to how somebody might be able to use Deb instead of RPMs,  and how we might be able to further abstract that stuff away.  And then other people like the Debian projects, for example, could then test their installers using the infrastructure that we have in place,  the blade centers that we have in place.  I think I'm nearly out of time, so I'm going to leave you with the three words which took me a week to come up with.  And does anybody have questions at this point about things?  Okay, quite a few.  So if you can't get to all the questions, then come and find me at the CentOS table.  We're in K Building.  Can I take one or two questions, maybe?  Yeah.  Yeah.  So just whoever shouts first and loudest.  How will we really bring the third arm center upon the kid that's in there,  that will change when we go to like source RPMs and we're not going to go there and work with them, correct?  And how will that affect the part B of the question, how will that affect the portal and the cycle?  So there are three parts to that question.  One is the easiest to answer, which is how does it affect scientific Linux?  So the question is that if ftp.redhat.com goes away and the SRPMs go away,  then how do people who consume it today get what they want to get, right?  So as far as Oracle is concerned, you'll have to ask Oracle.  As far as scientific Linux is concerned, we've been talking to them pretty much from day one to see how we could help them,  how we could get a better relationship in place.  And they have had a bunch of questions we've been able to answer,  and I think the ball is firmly and totally in their court.  We've made it open like, hey, you can come in and you can do whatever you want, however you want,  but do it as a part of the Centros project, do it within an inclusive framework  so that there's more people working on the same problem rather than a lot of people working on the same problem in different places  and basically duplicating effort.  So we're most welcome to come in, take what they want and do whatever else they want.  They're most welcome to bring whatever else they want and build it in-house and just be more inclusive.  While we take the next question, I'll try and see if I can get a slide up that shows you what the Git repositories will look like.  Go on.  So the question is about how SIGs will deliver content.  So the owners of content delivery is going to be up to the SIG to decide.  So they can either have their own repository and they can have a release file which is available within Centros Extras.  Yes.  But they also have the ability to actually rebuild all of Centros including their applications and deliver an ISO.  Excellent.  So there's basically some injuries that you're carrying out from your ClareOS days.  One more.  So I think rather than, okay, why don't you shoot your question?  So the question is if you were able to carry on doing what you're doing with Centros Linux today.  So as long as you're not violating terms of licenses that the stuff is distributed under, you're fine.  And if you're commercializing stuff, then there may be some trademark issues that come in.  But I mean, why in large, if you're doing what you're doing today, you should be fine.  Right.  So that's right.  So Centros Linux will exist as it is today.  So just quickly, just about the Git repository.  So this is kind of like what it's going to look like.  Every Git repository will have hard-wired branches.  There's nothing in master except for a readme that says there's nothing in master.  The C5C67 branches represent the code that is available in there.  We have the C5C6 plus stuff.  There is C4 for those of you who like to live in pain.  What the opportunity that will exist over here is that anybody will be able to log on and create their own branches.  You will not be able to write into C5C6C7, but you will be able to create your own branches and you'll be able to track those branches.  Within a branch, it'll look kind of like this.  Hopefully not with my name on it everywhere.  So you basically got every release that comes through as a commit, as a complete commit.  And within that, you have the text sources for, I mean, so whatever was in there.  Whatever is not in here was represented in a metadata file which looks like this,  which has the names of the files, the SHA256 sums, or what the software basically corresponds with,  and the content is available on Locosite Cache.  So you'll basically still be able to track the content.  You'll still be able to track the metadata that comes out of the SRPMs,  but you'll be able to consume it as a Git format, so it's easier to use.  And there's a script around as well that just basically takes one of these with a name and gives you an SRPM in return.  So guys, I'm sure if you have questions, come and find me.  I'm going to be at the CentOS table for the rest of the day today and most of tomorrow.  And thank you very much for coming along. Thank you.
_FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_0_107.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_108_1007.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_1008_1271.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_1272_1403.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_1404_3695.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_3696_12419.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_12420_14435.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_14436_15839.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_15840_18143.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_18144_18767.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_18768_23015.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_23016_25319.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_25320_26159.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_26160_26903.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_26904_27431.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_27432_28223.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_28224_31715.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_31716_34067.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_34068_34139.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_34140_35531.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_35532_39971.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_39972_42083.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_42084_42647.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_42648_45323.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_45324_47231.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_47232_47315.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_47316_47411.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_47412_48143.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_48144_48215.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_48216_50471.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_50472_51395.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_51396_52295.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_52296_52847.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_52848_53255.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_53256_54347.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54348_54395.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54396_54467.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54468_54575.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54576_54719.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54720_54887.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_54888_55007.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_55008_55163.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_55164_55415.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_55416_55475.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_55476_56171.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_56172_56507.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_56508_56555.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_56556_56603.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_56604_57011.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_57012_57155.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_57156_59135.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_59136_59939.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_59940_60035.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_60036_61079.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_61080_62111.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_62112_63383.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_63384_63527.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_63528_64343.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_64344_64427.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_64428_65003.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_65004_65135.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_65136_67643.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_67644_68291.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_68292_68867.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_68868_70295.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_70296_70691.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_70692_70787.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_70788_70991.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_70992_72251.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_72252_74315.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_74316_74399.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_74400_74567.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_74568_74807.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_74808_75707.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_75708_75767.png _FOSDEM_2014__CentOS__Planning_for_Variants_and_the_Next_Chapter_75768_76019.png