The development infrastructure of the TYPO3 project
Gebert, Steffen
What tools are needed to run an open-source project? Have you ever asked, what tools an open-source project needs? This talk gives you the answer from a TYPO3 perspective and presents the toolchain. Topics covered: web site extension repository redmine project hosting gerrit code review / git server pootle translation documentation rendering using ReST fudforum forums + mailing lists + nntp (all in sync) jenkins ci bigbluebutton conference server ietherpad collaborative writing ... We're happy to share our experiences and configuration!
 Good afternoon everybody. The next talk is the Development Infrastructure of the Type 3 Project by Stefan Gebert. So thanks for the introduction and thanks for listening to my talk and I'm going to tell you in the next couple of minutes a bit how Type 3s developed and of course what Type 3 is if you don't know it. So just to give you a know with you what you can expect from this talk you will learn how to set up a project infrastructure. Unfortunately the time is a bit short to do that. Maybe to see a perfect development infrastructure in the open source ecosphere. Well I think we're pretty good but we are by far not perfect so you will gain some impressions I think. But at least you will learn how people in an other open source project work and you can see our infrastructure that's built from 100% open source software. Maybe you find some inspiration for your project and maybe we can just get in touch together and yet discuss some things and say why don't you use this tool are we using that and I already got in touch with MediaViki guys so that would be really nice to have more connections to other open source projects. So us in this case is admin at typos3.org and most of our infrastructure is public somewhere in Git repos. In doubt if you have interest in something just ask us we are happy to share with you. Some words about myself. I used to be a Type 3 CMS core developer from 2010 until like a month ago where decided to focus more on the infrastructure work in the server admin registration team and in my day to day job I'm a PhD student in computer science in Wurzburg in the center of Germany. That's my email address and my Twitter handle if you want to get in touch with me. I'm very happy to hear from you. Due to the time constraints we might not be able to answer questions. The slides are already on slide share.net. And I also added some comments to them. So what's typos3? The most well known product of the typos3 project is typos3 CMS. It's a content management system on PHP basis, has more than 5 million downloads and it was started in 1997 so it has a big code base and a long time of development. And our community also brought two new products. One is PHP framework, typos3 flow and if this sounds interesting to you there was a talk by the lead developer Robert Lemke. I guess you can watch it in the videos after this conference. And also there's typos3 NEOs, a new content management system which is currently in alpha state based on typos3 flow. So about the persons of typos3. Types3 is community driven open source. There is, that was the wrong key, I'm sorry. That was Twitter. I'm very sorry for that. Types3 is community driven open source. There's no company behind only the typos3 association for financial support. But it's not about paid work. It's more about enabling costs to bring people to code sprints, et cetera. We have core teams with like 10 to 25 people who have to commit access and a lot of contributors. So while preparing this talk I saw the bit what requirements does an open source project have. And I identified these categories. One is collaboration and communication. The other one is source code and versioning. Then quality assurance and testing and documentation and translation. And the following I will present you the solutions we're using for these tasks. So you might also ask why are you using your own infrastructure and why don't you use GitHub? Some points about this. Of course often people think about just migrating to GitHub. But one reason would be we have been there before there was GitHub. In the beginning when Types3 was smaller, sourcefarch was used for CVS hosting. It started to be hacked. Sometimes it was unreliable. So yeah, in the subversion times everything was started on own infrastructure. The most important point I think is that we own our data in the times of Git. It's not so critical because everybody has the copy of the source code. But things like all the issues which are in the issue tracker are really worth some time and work. And we were also able to just switch the issue tracker like one year ago because of we have access to all data. And we have an own account management with all the teams. That wouldn't be just so easy to migrate to totally different platforms where we don't have back end access to. And the other thing is that we want to provide a central place for the whole community. Nevertheless, to admit it, it costs, sorry, we open towards other services which are freely available and we use them for not so critical things too. And one thing to admit, of course, this costs some efforts to have an own infrastructure. So the first point, communication and collaboration in type of three. Many things are communicated through mailing list and decided also through them. And they are used since 2003 and it took 10 years to build a human accessible, for the younger people, accessible interface which is forum which was launched last Monday. And it's based on FAT forum and provides a bidirectional synchronization of mailing lists and use groups in the forum. So we can now also link to mailing lists, threads, etc. So that's a pretty nice software. And that was pretty important for us to finally set such an interface up because the decisions take place in the list and this is the transparency that the type of three, let's say, deciders bring towards the other world and people that don't read it, they feel offended because they say, what the shit have you been deciding there and they don't see the discussion before. So that was important. And on the other hand, we're trying to really avoid internal discussions. So behind closed doors or in internal lists try to communicate things clearly. Nevertheless, we often still fail at this, unfortunately. So another thing for collaboration is our Forge platform on Forge.Type3.org. We have a red mine running there and this offers project space for more than 2,400 projects. So it's not for the top level products but also for community extensions which are the plug-ins for Type 3 CMS and also for other teams like design team or the event team, they all have their collaboration space there. And one interesting feature, one important feature, I would say, is a membership listing for the different teams because when you say, I want to contribute to this part of Type 3, who's responsible for that? With whom should I get in touch? So the good thing with the red mine is that it lists just all the memberships for the different projects and you can just go there and see that guys are responsible and I can get in touch with them and ask them what I can do for them. And it's the issue tracker for all the projects and that's a tiny rend or so. We are not so extremely happy with the red mine as issue tracker. The search is a bit limited and especially when you are not so familiar with it. So if you have ideas how to improve red mine search, we are really open towards that. Other features are like, like wikis per project, repository browser, news, time tracking, et cetera. Sears code and versioning, that's the next topic. We're using Git since mid-2000s and for one product and other products since the beginning of 2011. We're using a special flavor of Git. I will come to that very soon. One disadvantage still because of us admins having limited time, there's not yet official Git support for all community extensions so many of them are still limited to subversion and we are about to change that hopefully within the next few weeks. So search code and versioning was pretty short. Quality assurance and testing covers this topic now a bit again through code reviews. So title three is doing code reviews and the motivation behind that is that unfortunately bugs do exist. It's pretty sad. We are ensuring our code quality through peer review. So every change that has to go in there which is not totally trivial has to be peer reviewed by at least two other people. Discussing a code improves it. So when it's easy that you improve a suggested code change, then it leads to just a better quality instead of saying, okay, we merge it and afterwards we make it clean and so that doesn't work usually. And so we're doing the reviews before the merge. When we do it, once we have done it, others, it never worked really. And the good thing also when you're reviewing stuff from other people, you learn from them. You learn how they code and they can say, why don't you use just this method? It's way cleaner or way faster and so on. And although these reviews make the development transparent to the outside world, people can just go there and say and see why it was implemented this way maybe or why it was changed or not changed. And which brings us back to the special flavor of Git is that we're using the Garret code review software for these code reviews. And Garret is also our Git server. Just to give you some small impression how Garret looks like, you can go to review.tibel3.org and you just see a list of all the pending patches, who the author is and to watch project, it refers to. Once you zoom in into such an issue, you see again the owner and to which branch and the state. So it's still in review. You see the commit message and you see the votings by different people. And yeah, you need some positive votings to be able to really merge that change. There are also some more nice things. You have directly a diff view online in Garret and you can comment on single lines and say please do it this way or do it that way and people can communicate and then just upload a new patch set. If Garret is interesting to you and we are by far not the only project using Garret, I have a second talk here at 1514 and you're invited to just come back there and see in detail how Garret works. So we're also doing continuous integration and we of course have running a Jenkins server which does, yeah, the thing which are just the usual tools for PHP projects and an interesting thing is that Garret automatically votes in Garret 1. There is a violation of the coding guidelines, et cetera. But we don't do unit tests in Jenkins. But I come to that later. Then we have metrics.Typle3.org, a big sonar installation with 5600 projects. So all the core projects plus the extensions which are listed there and that presents your code metrics like cyclomatic complexity, et cetera, lines per method, and so on. So we have Travis also as continuous integration software. Travis is a hosted service so we don't have it on our own infrastructure and it's built for the open source community and, yeah, well, what does Travis other than Jenkins? It still just executes tests. But it does it in a very interesting way. First it fetches code from GitHub. Only from GitHub. That's a bit problematic because, yeah, as I said, we're hosting our own Git server so we are replicating just to GitHub. And Travis also supports, yeah, plenty of languages so it's not limited to PHP. So Travis CI just spins up virtual machines to run your unit tests. So you always have a clean environment. You don't have headaches because your virtual machine got hacked or so by unit tests and it runs them in different environments. That's interesting thing. For example, you could say, I want PHP 5.2 to 5.4 in different databases that builds up this matrix of test combinations. And Travis runs all of them. And how would you as a single developer find out that this combination fails? Travis does that for you and it launches all different versions that you're saying it should test and then it reports back if all pass or what fails. Documentation and translation in type 3. To translate type 3 and the extensions we're having PUTL installed. PUTL is a Python based project and we're using Xlib format like two years ago or so for the translations. And every night language packages are built out of the translations which are entered into PUTL and people can go into the type 3 installation and say fetch translations and then these packages are downloaded. PUTL is actually pretty nice. It also offers for everybody to suggest translations. So it's not a single team that does all the translations but everybody can just come here with a type 3.org account, log in and suggest the translation and team members can really set this translation active and everybody can just suggest new translations. Documentation in an open source project. Well, it was a raw point for a long time. Probably not the only reason but one reason. Sorry. Feel free to, we're using restructured text. Feel free to watch the slides online. It's a really nice format. It's built for Python initially and I'm out there for questions. Nice that you attended. Please see through my slides and also the comments online. Thanks for attending.
 Good afternoon everybody. The next talk is the Development Infrastructure of the Type  3 Project by Stefan Gebert. So thanks for the introduction and thanks for listening to  my talk and I'm going to tell you in the next couple of minutes a bit how Type 3s developed  and of course what Type 3 is if you don't know it. So just to give you a know with you  what you can expect from this talk you will learn how to set up a project infrastructure.  Unfortunately the time is a bit short to do that. Maybe to see a perfect development  infrastructure in the open source ecosphere. Well I think we're pretty good but we are  by far not perfect so you will gain some impressions I think. But at least you will  learn how people in an other open source project work and you can see our infrastructure  that's built from 100% open source software. Maybe you find some inspiration for your project  and maybe we can just get in touch together and yet discuss some things and say why don't  you use this tool are we using that and I already got in touch with MediaViki guys so  that would be really nice to have more connections to other open source projects. So us in this  case is admin at typos3.org and most of our infrastructure is public somewhere in Git  repos. In doubt if you have interest in something just ask us we are happy to share with you.  Some words about myself. I used to be a Type 3 CMS core developer from 2010 until like  a month ago where decided to focus more on the infrastructure work in the server admin  registration team and in my day to day job I'm a PhD student in computer science in  Wurzburg in the center of Germany. That's my email address and my Twitter handle if  you want to get in touch with me. I'm very happy to hear from you. Due to the time constraints  we might not be able to answer questions. The slides are already on slide share.net.  And I also added some comments to them. So what's typos3? The most well known product  of the typos3 project is typos3 CMS. It's a content management system on PHP basis,  has more than 5 million downloads and it was started in 1997 so it has a big code base  and a long time of development. And our community also brought two new products. One is PHP  framework, typos3 flow and if this sounds interesting to you there was a talk by the  lead developer Robert Lemke. I guess you can watch it in the videos after this conference.  And also there's typos3 NEOs, a new content management system which is currently in alpha  state based on typos3 flow. So about the persons of typos3. Types3 is community driven open  source. There is, that was the wrong key, I'm sorry. That was Twitter. I'm very sorry  for that. Types3 is community driven open source. There's no company behind only the  typos3 association for financial support. But it's not about paid work. It's more about  enabling costs to bring people to code sprints, et cetera. We have core teams with like 10  to 25 people who have to commit access and a lot of contributors. So while preparing  this talk I saw the bit what requirements does an open source project have. And I identified  these categories. One is collaboration and communication. The other one is source code  and versioning. Then quality assurance and testing and documentation and translation.  And the following I will present you the solutions we're using for these tasks. So you might  also ask why are you using your own infrastructure and why don't you use GitHub? Some points  about this. Of course often people think about just migrating to GitHub. But one reason would  be we have been there before there was GitHub. In the beginning when Types3 was smaller,  sourcefarch was used for CVS hosting. It started to be hacked. Sometimes it was unreliable.  So yeah, in the subversion times everything was started on own infrastructure. The most  important point I think is that we own our data in the times of Git. It's not so critical  because everybody has the copy of the source code. But things like all the issues which  are in the issue tracker are really worth some time and work. And we were also able  to just switch the issue tracker like one year ago because of we have access to all  data. And we have an own account management with all the teams. That wouldn't be just  so easy to migrate to totally different platforms where we don't have back end access to. And  the other thing is that we want to provide a central place for the whole community. Nevertheless,  to admit it, it costs, sorry, we open towards other services which are freely available and  we use them for not so critical things too. And one thing to admit, of course, this costs  some efforts to have an own infrastructure. So the first point, communication and collaboration  in type of three. Many things are communicated through mailing list and decided also through  them. And they are used since 2003 and it took 10 years to build a human accessible,  for the younger people, accessible interface which is forum which was launched last Monday.  And it's based on FAT forum and provides a bidirectional synchronization of mailing  lists and use groups in the forum. So we can now also link to mailing lists, threads, etc.  So that's a pretty nice software. And that was pretty important for us to finally set  such an interface up because the decisions take place in the list and this is the transparency  that the type of three, let's say, deciders bring towards the other world and people that  don't read it, they feel offended because they say, what the shit have you been deciding  there and they don't see the discussion before. So that was important. And on the other hand,  we're trying to really avoid internal discussions. So behind closed doors or in internal lists  try to communicate things clearly. Nevertheless, we often still fail at this, unfortunately.  So another thing for collaboration is our Forge platform on Forge.Type3.org. We have  a red mine running there and this offers project space for more than 2,400 projects. So it's  not for the top level products but also for community extensions which are the plug-ins  for Type 3 CMS and also for other teams like design team or the event team, they all have  their collaboration space there. And one interesting feature, one important feature, I would say,  is a membership listing for the different teams because when you say, I want to contribute  to this part of Type 3, who's responsible for that? With whom should I get in touch?  So the good thing with the red mine is that it lists just all the memberships for the  different projects and you can just go there and see that guys are responsible and I can  get in touch with them and ask them what I can do for them. And it's the issue tracker  for all the projects and that's a tiny rend or so. We are not so extremely happy with the  red mine as issue tracker. The search is a bit limited and especially when you are not  so familiar with it. So if you have ideas how to improve red mine search, we are really  open towards that. Other features are like, like wikis per project, repository browser,  news, time tracking, et cetera. Sears code and versioning, that's the next topic. We're  using Git since mid-2000s and for one product and other products since the beginning of  2011. We're using a special flavor of Git. I will come to that very soon. One disadvantage  still because of us admins having limited time, there's not yet official Git support  for all community extensions so many of them are still limited to subversion and we are  about to change that hopefully within the next few weeks. So search code and versioning  was pretty short. Quality assurance and testing covers this topic now a bit again through code  reviews. So title three is doing code reviews and the motivation behind that is that unfortunately  bugs do exist. It's pretty sad. We are ensuring our code quality through peer review. So every  change that has to go in there which is not totally trivial has to be peer reviewed by  at least two other people. Discussing a code improves it. So when it's easy that you improve  a suggested code change, then it leads to just a better quality instead of saying, okay,  we merge it and afterwards we make it clean and so that doesn't work usually. And so we're  doing the reviews before the merge. When we do it, once we have done it, others, it never  worked really. And the good thing also when you're reviewing stuff from other people,  you learn from them. You learn how they code and they can say, why don't you use just this  method? It's way cleaner or way faster and so on. And although these reviews make the  development transparent to the outside world, people can just go there and say and see why  it was implemented this way maybe or why it was changed or not changed. And which brings  us back to the special flavor of Git is that we're using the Garret code review software  for these code reviews. And Garret is also our Git server. Just to give you some small  impression how Garret looks like, you can go to review.tibel3.org and you just see a  list of all the pending patches, who the author is and to watch project, it refers to. Once  you zoom in into such an issue, you see again the owner and to which branch and the state.  So it's still in review. You see the commit message and you see the votings by different  people. And yeah, you need some positive votings to be able to really merge that change. There  are also some more nice things. You have directly a diff view online in Garret and you can comment  on single lines and say please do it this way or do it that way and people can communicate  and then just upload a new patch set. If Garret is interesting to you and we are by far not  the only project using Garret, I have a second talk here at 1514 and you're invited to just  come back there and see in detail how Garret works. So we're also doing continuous integration  and we of course have running a Jenkins server which does, yeah, the thing which are just  the usual tools for PHP projects and an interesting thing is that Garret automatically votes in  Garret 1. There is a violation of the coding guidelines, et cetera. But we don't do unit  tests in Jenkins. But I come to that later. Then we have metrics.Typle3.org, a big sonar  installation with 5600 projects. So all the core projects plus the extensions which are  listed there and that presents your code metrics like cyclomatic complexity, et cetera, lines  per method, and so on. So we have Travis also as continuous integration software. Travis  is a hosted service so we don't have it on our own infrastructure and it's built for  the open source community and, yeah, well, what does Travis other than Jenkins? It still  just executes tests. But it does it in a very interesting way. First it fetches code from  GitHub. Only from GitHub. That's a bit problematic because, yeah, as I said, we're hosting our  own Git server so we are replicating just to GitHub. And Travis also supports, yeah,  plenty of languages so it's not limited to PHP. So Travis CI just spins up virtual machines  to run your unit tests. So you always have a clean environment. You don't have headaches  because your virtual machine got hacked or so by unit tests and it runs them in different  environments. That's interesting thing. For example, you could say, I want PHP 5.2 to  5.4 in different databases that builds up this matrix of test combinations. And Travis  runs all of them. And how would you as a single developer find out that this combination fails?  Travis does that for you and it launches all different versions that you're saying it should  test and then it reports back if all pass or what fails. Documentation and translation  in type 3. To translate type 3 and the extensions we're having PUTL installed. PUTL is a Python  based project and we're using Xlib format like two years ago or so for the translations.  And every night language packages are built out of the translations which are entered  into PUTL and people can go into the type 3 installation and say fetch translations and  then these packages are downloaded. PUTL is actually pretty nice. It also offers for everybody  to suggest translations. So it's not a single team that does all the translations but everybody  can just come here with a type 3.org account, log in and suggest the translation and team  members can really set this translation active and everybody can just suggest new translations.  Documentation in an open source project. Well, it was a raw point for a long time. Probably  not the only reason but one reason. Sorry. Feel free to, we're using restructured text.  Feel free to watch the slides online. It's a really nice format. It's built for Python  initially and I'm out there for questions. Nice that you attended. Please see through  my slides and also the comments online. Thanks for attending.
The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_0_59.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_60_203.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_204_251.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_252_2351.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_2352_2999.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_3000_3395.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_3396_4523.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_4524_4859.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_4860_9443.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_9444_19307.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_19308_19739.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_19740_23675.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_23676_24191.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_24192_24503.png The_development_infrastructure_of_the_TYPO3_project_cYbMI183lcQ_2_24504_24627.png
Good afternoon everybody. The next talk is the Development Infrastructure of the Type 3 Project by Stefan Gebert. So thanks for the introduction and thanks for listening to my talk and I'm going to tell you in the next couple of minutes a bit how Type 3s developed and of course what Type 3 is if you don't know it. So just to give you a know with you what you can expect from this talk you will learn how to set up a project infrastructure. Unfortunately the time is a bit short to do that. Maybe to see a perfect development infrastructure in the open source ecosphere. Well I think we're pretty good but we are by far not perfect so you will gain some impressions I think. But at least you will learn how people in an other open source project work and you can see our infrastructure that's built from 100% open source software. Maybe you find some inspiration for your project and maybe we can just get in touch together and yet discuss some things and say why don't you use this tool are we using that and I already got in touch with MediaViki guys so that would be really nice to have more connections to other open source projects. So us in this case is admin at typos3.org and most of our infrastructure is public somewhere in Git repos. In doubt if you have interest in something just ask us we are happy to share with you. Some words about myself. I used to be a Type 3 CMS core developer from 2010 until like a month ago where decided to focus more on the infrastructure work in the server admin registration team and in my day to day job I'm a PhD student in computer science in Wurzburg in the center of Germany. That's my email address and my Twitter handle if you want to get in touch with me. I'm very happy to hear from you. Due to the time constraints we might not be able to answer questions. The slides are already on slide share.net. And I also added some comments to them. So what's typos3? The most well known product of the typos3 project is typos3 CMS. It's a content management system on PHP basis, has more than 5 million downloads and it was started in 1997 so it has a big code base and a long time of development. And our community also brought two new products. One is PHP framework, typos3 flow and if this sounds interesting to you there was a talk by the lead developer Robert Lemke. I guess you can watch it in the videos after this conference. And also there's typos3 NEOs, a new content management system which is currently in alpha state based on typos3 flow. So about the persons of typos3. Types3 is community driven open source. There is, that was the wrong key, I'm sorry. That was Twitter. I'm very sorry for that. Types3 is community driven open source. There's no company behind only the typos3 association for financial support. But it's not about paid work. It's more about enabling costs to bring people to code sprints, et cetera. We have core teams with like 10 to 25 people who have to commit access and a lot of contributors. So while preparing this talk I saw the bit what requirements does an open source project have. And I identified these categories. One is collaboration and communication. The other one is source code and versioning. Then quality assurance and testing and documentation and translation. And the following I will present you the solutions we're using for these tasks. So you might also ask why are you using your own infrastructure and why don't you use GitHub? Some points about this. Of course often people think about just migrating to GitHub. But one reason would be we have been there before there was GitHub. In the beginning when Types3 was smaller, sourcefarch was used for CVS hosting. It started to be hacked. Sometimes it was unreliable. So yeah, in the subversion times everything was started on own infrastructure. The most important point I think is that we own our data in the times of Git. It's not so critical because everybody has the copy of the source code. But things like all the issues which are in the issue tracker are really worth some time and work. And we were also able to just switch the issue tracker like one year ago because of we have access to all data. And we have an own account management with all the teams. That wouldn't be just so easy to migrate to totally different platforms where we don't have back end access to. And the other thing is that we want to provide a central place for the whole community. Nevertheless, to admit it, it costs, sorry, we open towards other services which are freely available and we use them for not so critical things too. And one thing to admit, of course, this costs some efforts to have an own infrastructure. So the first point, communication and collaboration in type of three. Many things are communicated through mailing list and decided also through them. And they are used since 2003 and it took 10 years to build a human accessible, for the younger people, accessible interface which is forum which was launched last Monday. And it's based on FAT forum and provides a bidirectional synchronization of mailing lists and use groups in the forum. So we can now also link to mailing lists, threads, etc. So that's a pretty nice software. And that was pretty important for us to finally set such an interface up because the decisions take place in the list and this is the transparency that the type of three, let's say, deciders bring towards the other world and people that don't read it, they feel offended because they say, what the shit have you been deciding there and they don't see the discussion before. So that was important. And on the other hand, we're trying to really avoid internal discussions. So behind closed doors or in internal lists try to communicate things clearly. Nevertheless, we often still fail at this, unfortunately. So another thing for collaboration is our Forge platform on Forge.Type3.org. We have a red mine running there and this offers project space for more than 2,400 projects. So it's not for the top level products but also for community extensions which are the plug-ins for Type 3 CMS and also for other teams like design team or the event team, they all have their collaboration space there. And one interesting feature, one important feature, I would say, is a membership listing for the different teams because when you say, I want to contribute to this part of Type 3, who's responsible for that? With whom should I get in touch? So the good thing with the red mine is that it lists just all the memberships for the different projects and you can just go there and see that guys are responsible and I can get in touch with them and ask them what I can do for them. And it's the issue tracker for all the projects and that's a tiny rend or so. We are not so extremely happy with the red mine as issue tracker. The search is a bit limited and especially when you are not so familiar with it. So if you have ideas how to improve red mine search, we are really open towards that. Other features are like, like wikis per project, repository browser, news, time tracking, et cetera. Sears code and versioning, that's the next topic. We're using Git since mid-2000s and for one product and other products since the beginning of 2011. We're using a special flavor of Git. I will come to that very soon. One disadvantage still because of us admins having limited time, there's not yet official Git support for all community extensions so many of them are still limited to subversion and we are about to change that hopefully within the next few weeks. So search code and versioning was pretty short. Quality assurance and testing covers this topic now a bit again through code reviews. So title three is doing code reviews and the motivation behind that is that unfortunately bugs do exist. It's pretty sad. We are ensuring our code quality through peer review. So every change that has to go in there which is not totally trivial has to be peer reviewed by at least two other people. Discussing a code improves it. So when it's easy that you improve a suggested code change, then it leads to just a better quality instead of saying, okay, we merge it and afterwards we make it clean and so that doesn't work usually. And so we're doing the reviews before the merge. When we do it, once we have done it, others, it never worked really. And the good thing also when you're reviewing stuff from other people, you learn from them. You learn how they code and they can say, why don't you use just this method? It's way cleaner or way faster and so on. And although these reviews make the development transparent to the outside world, people can just go there and say and see why it was implemented this way maybe or why it was changed or not changed. And which brings us back to the special flavor of Git is that we're using the Garret code review software for these code reviews. And Garret is also our Git server. Just to give you some small impression how Garret looks like, you can go to review.tibel3.org and you just see a list of all the pending patches, who the author is and to watch project, it refers to. Once you zoom in into such an issue, you see again the owner and to which branch and the state. So it's still in review. You see the commit message and you see the votings by different people. And yeah, you need some positive votings to be able to really merge that change. There are also some more nice things. You have directly a diff view online in Garret and you can comment on single lines and say please do it this way or do it that way and people can communicate and then just upload a new patch set. If Garret is interesting to you and we are by far not the only project using Garret, I have a second talk here at 1514 and you're invited to just come back there and see in detail how Garret works. So we're also doing continuous integration and we of course have running a Jenkins server which does, yeah, the thing which are just the usual tools for PHP projects and an interesting thing is that Garret automatically votes in Garret 1. There is a violation of the coding guidelines, et cetera. But we don't do unit tests in Jenkins. But I come to that later. Then we have metrics.Typle3.org, a big sonar installation with 5600 projects. So all the core projects plus the extensions which are listed there and that presents your code metrics like cyclomatic complexity, et cetera, lines per method, and so on. So we have Travis also as continuous integration software. Travis is a hosted service so we don't have it on our own infrastructure and it's built for the open source community and, yeah, well, what does Travis other than Jenkins? It still just executes tests. But it does it in a very interesting way. First it fetches code from GitHub. Only from GitHub. That's a bit problematic because, yeah, as I said, we're hosting our own Git server so we are replicating just to GitHub. And Travis also supports, yeah, plenty of languages so it's not limited to PHP. So Travis CI just spins up virtual machines to run your unit tests. So you always have a clean environment. You don't have headaches because your virtual machine got hacked or so by unit tests and it runs them in different environments. That's interesting thing. For example, you could say, I want PHP 5.2 to 5.4 in different databases that builds up this matrix of test combinations. And Travis runs all of them. And how would you as a single developer find out that this combination fails? Travis does that for you and it launches all different versions that you're saying it should test and then it reports back if all pass or what fails. Documentation and translation in type 3. To translate type 3 and the extensions we're having PUTL installed. PUTL is a Python based project and we're using Xlib format like two years ago or so for the translations. And every night language packages are built out of the translations which are entered into PUTL and people can go into the type 3 installation and say fetch translations and then these packages are downloaded. PUTL is actually pretty nice. It also offers for everybody to suggest translations. So it's not a single team that does all the translations but everybody can just come here with a type 3.org account, log in and suggest the translation and team members can really set this translation active and everybody can just suggest new translations. Documentation in an open source project. Well, it was a raw point for a long time. Probably not the only reason but one reason. Sorry. Feel free to, we're using restructured text. Feel free to watch the slides online. It's a really nice format. It's built for Python initially and I'm out there for questions. Nice that you attended. Please see through my slides and also the comments online. Thanks for attending.
know with you what you can expect from this talk happy to share with you. Some words about myself. in the videos after this conference. And also and documentation and translation. And the have an own account management with all the a bidirectional synchronization of mailing lists the Garret code review software for these code not the only project using Garret, I have a hosting our own Git server so we are replicating