 Welcome to this talk or rather non-talk. With ruthless efficiency it's now one o'clock so we're gonna start this presentation. First words first. The presentation listing in the program lists an amount of info about what you're gonna see here, what this is about etc. You know the way programs are written before the conference? Well this is not ready. The things that we wanted to have ready for the conference didn't appear in time, didn't get implemented in time. Some of them have landed but instead of making like a train wreck demo or kind of this is what we have so far we're not gonna do that. We're gonna take an amount of time and opportunity to communicate a number of basic issues, basic precepts, basic concepts and walk through some of the implications and then take time to give me the opportunity to talk with developers and get info about some of the workflows and some of the things that people do, people use to interact with with the developer.blender website and work on a better understanding of what the future workflows what the future precepts or concepts in GT will be. So this is also something you'll see in the presentation. Again okay that that was something I fixed on a different system but this one has the same problem. So what is this if it's not a presentation? It's a small post-mortem of the talk that isn't. Clarification of some terms. This is useful most likely for people who have seen fabricator who know some of the terms that fabricator uses for different concepts within fabricator and why they are not the same over everything in GT especially the word project for example is a very interesting one. A short overview of where we are, what we have and then we'll take a opportunity to connect and listen. The practical upshot of this is that this will take about 15 minutes and not 50 and then we'll take some time to either sit here or outside and basically do an impromptu show and tell session of hey I do this type of thing how would that work or tell me about the process and I'll tell you like okay could you tell me more about how you do that exactly so that we understand more how we will port that over into a new system. Intel driver I'm not gonna say anything more. So the intentions were to give you a show and tell to give a demo that's not happening have all completed features running we have a fair amount of features integrated into GT that we asked the GT support people support devs to actually prepare for us a lot of these have landed but they have not been integrated into one artifact that I can show and tell so I'm not gonna do that. Demonstrate modes of use there are as you know multiple ways of interacting with code fabricator has one idea of this github and others have others I'm not gonna try and do that with something that's not finished because it's just not polished enough. What it is now I will point you to the Git repo that has a fair amount of features that have landed so the development is done on future.project.blender.org there are pull requests from a private repo of one of the developers where you will find more more experimental iterations on some features which you can also explore there is a getty1.dev.blender.org which is a non-stable installation meaning it gets reinstalled every now and then with a new import of all the data with new import of data concepts meaning if we have a way of representing pull requests in a more meaningful way we kind of throw away what we did had before and we put in pull requests in a better way than we had before so if you look at getty1.dev.blender.org you will see something new over time every time you start looking there. Don't start cloning stuff and developing on that even if you get a clone permission because it will not stay there. You can log in on both systems with Blender ID so you don't need to ask for an account that works. Blender conference took a lot of time and development work was a lot more than we thought it would be specifically on the whole if you saw the talk that I gave on Thursday pull requests and the way that fabricator does not have a tight coupling with the reality of what is in git is a challenge has been a real real big challenge to actually say okay if fabricator has a patch but it's not actually a pull request or branch or anything in git how do you deal with that so that development work we found more important but that kind of got more and more time food poisoning got in the way I'll save you the details but basically we are in a place where the import of data is possible we just didn't get to it yet in time for the Blender conference which as I said might not be a bad thing because we're here all face-to-face and now I have time and effort opportunity to actually talk with people and I've done that with a couple already but I'd really like to get as many people as possible that I meet here again I'm not a Blender developer so I do not have intricate knowledge of the source code nor of the development process that any specific module owner or specific developer might follow meaning I have to talk with people to understand what it is that helps them and what it is that you know gets in their way sometimes these are very simple things like UI elements sometimes they're much more important and they have to do with the whole concept of okay where do you go to do what why would you do that because the idea of a forge is that it aids a group of people to coordinate and do a project together and if it gets in the way that is a bad thing so I already had I think eight people yesterday in one small small room with the three chairs where we discussed a number of considerations and issues there are things that we learned from that but I also learned already what could be better now a brief baseline is an order if you are a developer on Blender.org on developer to Blender.org some of these things will sound familiar we have the BF Blender project it is a project it has a repo inside the repo has milestones the milestones lead to work boards which which basically are there to get a milestone finished in time for a release and then there are sub projects that can be part of the main project but we don't use them anymore Blender 2.8 Blender 2.7 were sub projects they were in fabricator as a sub projects but now we do everything mostly with milestones people and members of groups are basically a system-wide concept in fabricator meaning you are a person you have access to most things in fabricator and members of a project are automatically also members of all the sub projects and milestones. Tags in fabricator are an interesting concept tags are the things that you link to an issue or a pull request and they are interestingly enough anything so they're not really considered to be anything specific they can be a project tag they can be a priority tag they can be anything it's just tag it's a tag cloud so they're not really structured as much but the one thing they are not are Git tags so if you speak about tags in fabricator you're almost never talking about Git tags and that's because there's a separation of Git concepts from fabricator and this is mostly to do with the fact that fabricator is kind of agnostic about what kind of code control system is underneath because it has support for SVN the idea of SVN tags might exist but that's not what they're talking about when they're doing tags tags is just a concept within within fabricator in this sense now that's opposite to what Git T does in a number of things Git T like GitHub organizes things under an organization or personal repo so you have an organization have multiple repositories under underneath that organization or you have a personal account which can have multiple repos underneath the milestones and the workboards kind of map the same way as in fabricator so that is preserved and instead of the concept of a sub project you actually have the word project which is just something within a repo that is a project so projects get redefined sub projects don't exist the whole concept of what fabricator does with permissions there's a weird concept in fabricator where you say look we'll make a project we'll subscribe people to that project we'll put them in there and then we'll say this project is a permission project and whoever is part of this project gets permissions in all the projects that take this project as a permission project it's a bit of a convoluted way of doing authorization control in Git T you have the concept of teams very simple very flat way of doing things labels are organization specific meaning if you do anything where you create like organizations next to let's say the blender organization and you make a blender cycles organization then suddenly you have a new label cloud labels are what tags are mostly in in fabricator the issue there is that if we would make a system where we say look you make different organizations for different blender areas you run into the issue that you cannot reuse labels because they mean different things teams are not crossing organizations so you can see how the concept of organizations and teams and labels kind of already work towards a certain organization of how modules module owners repos kind of start to work together now a lot of this will not be very surprising because github is for a lot of people very familiar example of exactly this type of permission and hierarchy system tags are git tags meaning if you see the word tag anywhere inside of git T it means a git tag so that's very important to understand if you look at the fabricator stuff and you see a tag somewhere and it gets ported into git T it's not going to be called a tag anymore and there's a very tight coupling to get this is this has been touched in the previous talk but very very short recap in fabricator it's perfectly possible and allowed and even encouraged maybe to send in a patch from nowhere just to say hey I made a patch somewhere here's the text cut paste post and it lands in fabricator fabricator will present it as an amount of code you can do reviews over it you can put comments over it you can have a whole discussion about it but interestingly enough fabricator does not require you to actually tell you that to tell it where that patch came from like when did you or you do kind of need to tell it when did you make it because you post the patch at a certain time so you know when it landed but it doesn't tell you you're not required to tell fabricator when you checked out the code that you worked on to create the patch could be five years ago you don't know that is not possible in modern git forges they really assume that there's a tight coupling to what you represent and what is physical or what is actually present inside of the git repo and that presents challenges and that's one of the points I talked about earlier like hey how do we represent pull requests and reviews etc because this means that if you want to import data into git from fabricator you actually have to create history that you didn't have because it was not in fabricator so we make synthetic data that actually matches reality these light transitions are so horrible I apologize again so the takeaway so far with a number of explorations we did like iterations of hey what if we do this what if we do that is that big workflow changes are never needed nor desired meaning a fair number of people that I've spoken say look with fabricator there's a lot of things that we don't like so much but the basic way of how we accept things from each other or organize using work boards that is a method which fits the development the development the developmental model of blender well at this moment doesn't mean that it won't change in the future but that fits well but there are some in benefit inevitable changes due to the nature of the coupling a tight coupling to get meaning the way that you can now just make a patch and you know send of a text file and hope it lands somewhere that's not how it works in a future git flow it's just the way it is there is a high amount of self coordination relative to the size of the project so if you look at large projects like with the same kind of scope in code as blender you notice or I noticed that there's much more attention to how people are or are not allowed to be inner group outer group or do the follow like how do you call that so if you do contributions you need to make sure that for example they are free of patents I intellectual property concerns all kinds of stuff like that there are projects that put a lot of emphasis on this for better or worse blender does not do this at at current we might have to for certain things but we also make we have a community of developers that organically over the years have come to understand what is required from each other so there is no real written process for a number of things they are in the heads of people who have been doing this for a long while or have been told by somebody else like hey I typically do this that seems to work for me so as long as there's no new things popping up these project that these processes seem to work well but that means that if you just look at the blender project and the blender development cycle this is something that is different from a lot of other projects out there module coordinators that we have typically have a lot of full say about something meaning even if there is a formal review process within blender to accept new commits or new features there are times when a commit into master is just a default way of doing things if it's clear by the module owners or coordinators that this is going to land well it's committed it doesn't go through a review system necessarily and modules are at times not really large teams modules that consist of two three people at most that do a lot a lot or most of the work and except outside contributions either on a sporadic or on an opportunistic basis seems to be the norm rather than an exception so this is mostly these points are like helicopter view looking at the blender project from an outside perspective a little bit work boards are very heavily leveraged a lot of our coordination a lot of the whole idea of how we interoperate hinges on the concept of work boards and how we can configure those and how we can make them work for a specific team bug fixes bug fixes into LTS so the long times support releases are at times unclear I've heard from multiple people by now that knowing how to get a fixed bug to be accepted or known about so that it can be included in an LTS release or fix up release of something that's the current release is not always a straightforward process seems to work but different people have different ideas of how this actually works so I've had multiple descriptions and it kind of works out in the end but it's not actually clear what it's what it is so that needs to be looked at whatever we do and it's not really dependent on get the transition but it's an interesting observation and then there's triaging the triaging process requires too many steps or too many things that need to be done or set to actually get tried get something from being submitted being triaged and being put into the right queue it takes to more work and more time than it should or could so just very very simple very very basic overview this is almost insulting to most of the people who work with get but if you don't a little recap what do you do typically if you if you start working on a piece of code when you are not already a blender developer and you'd like to do stuff for blender so in the future get world that we live in with get the or anything else the idea is that you fork the code to a personal repo or you you make a branch if you are actually part of the project itself you pull it to local disk you make a branch if you didn't do that on on the on the core branch already or on the core repository already then you do your stuff you add the changes you commit you post a pull request from your branch into something else that gets reviewed and you do an accept and merge now again the review process we do not require for a fair number of things so actually saying we need to do this is not a necessary step that we might want to implement but this is what kind of is a assumed in the way that the get world works there is another one which is something that we haven't had in fabricator yet and which will become a reality which is the fact that we have online edits available in get T meaning the documentation team is actually very happy about this concept being able to navigate to a piece to a file to fix a typo or a translation of something and say look I don't need to check out the whole source code I don't need to go into my personal editor I don't need to do add commit review etc. I just want to fix this typo very quickly so you navigate to the file if you are not part of the org itself you clone it to a personal repo you edit you can either directly commit to master if that's the thing you want to do because it's just a typo it shouldn't break anything or you do a branch create pull request and you do the same type of run around as you do in the previous page so with that in mind what are concepts that didn't make it or what are things that are pretty much right out and this is mostly a slide that I made to calm the nerves of some people who've been seeing this get T thing come closer and not here yet like what is gonna happen how am I gonna do stuff we don't know yet but we also know these are not the things we're gonna get so all Blender sub projects would require a separate repo like let's say we we have a sculpting or modeling thing but we require you to make you know a sub project or a sub module or something and everything has to happen there we're not gonna do that really depends on the type of module the type of work being done the type of things that the team would like to have all Blender sub projects become a sub module repo same thing kind of the same thing all commits require reviews we're not gonna go through that formal review process either all code flows must be the same code flows meaning how do you actually come towards having something which could be mergeable right how do you interoperate how do you talk with each other how do you communicate within a module to say okay this is how we know it's now ready to be pulled into something else and a generic get workflow is required for main projects this we do know meaning having a way to coordinate all the things that we get from different parts of Blender development and to know which need to be included into a release we will have to develop one that works for Blender as a whole so we do know that that is coming it's a bit of an obvious thing but that is the only thing where modules will not be able to have or documentation projects etc will not really be having a full flexibility they will have to be able to hook into something that is for the project as a whole so what do we have we do have a reasonable translation or transposition of current operations that we do within fabric character on to operations that we can do in gitty so we've looked at the number of features that we were missing in gitty and we asked developers at gitty to implement them or find ways of doing them with the tools that we have available so that's where we are we have an understanding of work board usage through interviews with developers yesterday before yesterday and before there and somewhere there's white text on white background overlaid great a way to implement the current workflow is completely possible so we know that that maps well and we have a way of accommodating new methods for basic actions so the upshot of that point is that if we have things that we are currently doing we don't have to translate them one-on-one in the way that we do them right now there are really a lot of ways we can do the same things as we have access to an API which is extendable we have webhooks which are extendable there's support for multiple standard workflows or standard operations like the agit workflow which is another way of interacting with a git forge which we might adopt parts of so that's all things that we do have there's however no demo and I would like to basically say now like okay can we sit down because this is the time that I have where I can actually see the faces that belong to parts of the blender development some of you have been just basically a couple of letters inside blender.chat in the sidebar and typing long stories is really really hard in there so I would like to invite people to actually if you have something to say about developer.blender.org from even from a user perspective I would like to hear from you if you are a developer or even a module owner I would love to hear from you so that's what I'd like to do now with that in with whatever flows from there I will try to make a wrap-up which I'll present in the second week of November on most likely on the code blog as a git-t-diaries item which some of you might have already seen landing on there and that will basically try or attempt to summarize the takeaways that are already presented some of plus new takeaways that I will get from you hopefully today to get a bit of a broader communication towards people like okay this is the shape of what we're going to attempt and what's coming so with that let's do it generic end slide and that's it I don't think there is any other presentation scheduled for the next 30 minutes here so I would