 reason something that you would like to assume that you're interested in and then also as I said before we have an official talk on on Thursday which we call defining a roadmap and during that it would be really cool if we could find out where we are going to go but I think before we can find out where we're going to go I think it's important to establish where we are right now so let me start this off and say that VCS PKG was founded because people like Manoj used very complex setups version control setups and distributed version control setups to manage their packages to the point where it was absolutely unusable in 2006 I think at some point in time I decided that this arch stuff is that was food that was not anything to do with that well I really appreciated what Manoj was doing and I thought it was great because in the end it was total overkill but I don't want to discredit Manoj's work on this it was something that was scalable to every single package size you would maintain changes in branches and you would use a version control system to do what many of us have been doing in files and using the Debian archive as a version control system because as a matter of fact it is but we just keep the last four revisions or last three revisions it doesn't have depth archive diff implemented for instance so I thought I thought he had a great idea and I wanted to spread that idea I wanted to say look people like why don't you all all do it like this and so I looked at this arch thing I was like ah it's not that complicated you just have to kind of like understand the weak process and do it and I did an IRC session at one point in time in 2006 where my goal was to explain how you would do a package upgrade a new version release with arch with two feature branches and then push it to the archive is there anyone here who has participated in that discussion on IRC all right well I'm really glad that my fingers are actually still there because that discussion took three and a half hours it was it was completely mad and that was partly because marked but also partly because the complexity of the entire process of using feature branches of using version control system beyond what CVS and SVN gave you at this point in time and just hadn't trickled through people have not really thought about it and I can't blame them because you have to be more sophisticated you want to look at art nowadays we have a lot of different contenders that are doing the same principles a lot better there's BZR there's git there's darks there's you name it and and my my thought was look we can we can do exactly what we were trying to do version control used for devian packaging and not just to actually create a package but to maintain the package in a scalable way but when I looked around and there were a lot of people that were using it there was Monash there was Guido for instance who is the maintainer and author of a git build package who was doing very funky stuff that I'm doing a great job and doing a great job and I looked at his work and I looked at some other people who were doing the same stuff and I was like okay this is this is really cool because we're all doing the right thing but then I was like if we're really starting to do it right now then maybe we could find one way in which we can unify it find one workflow that fits everyone so that we can actually harvest the fruits of this more complex approach and make use of it and around that time I also talked to people in fedora and people in gen 2 and I figured out for instance fedora was doing pretty much exactly the same stuff they were at that point in time trying to use svn and kind of like making they didn't really look at args they were trying to use svn but then they switched to mercurial I think and ubuntu came and had this idea about source list uploads and the super mirror and bzr and they had pretty much the same ideas with bzr loon and I figured look they're a number of different version control systems and they're a number of different distributions and as a matter of fact I think someone sledge-studded in his talk we're all doing the same thing right we're all taking upstream software and we're modifying it and then we're presenting into our users and the modification part is slightly different but not very different between the distributions everyone has to do some sort of linux specific changes fedora and debian could cooperate on those and ubuntu and debian I mean the changes that we make that are specific to the debian style or dev packages you could really just profit from each other and in order to be able to do that in a way that would make it conducive to everyone we would need one approach that made it possible using distributed version control systems and maybe let me jump to the end and I don't want to talk a lot longer but I really want to hear from you guys what we're doing maybe at the end the sort of thing that I envision is that it'll be so easy to say look this problem that we're having right here or this feature that's not that's not thing has a mystic wing let's think optimistically this feature that fedora has implemented is something really cool for instance that with mdadm the rate maintainer I mean they do properly event driven assembly which my package doesn't do yet and I look at that and I'm just like I really really really want to use that but I can't because it's so complicated and they're using a completely different version control system if in an ideal world they were using something that was compatible with my workflow then I could really just say I'd love to implement this myself because I'm a hacker but I don't have any time so just click here and there comes the patch and it's integrated and tracked it's not just a patch that I asked the fedora person to give me but it's a patch that five years from now will still be the same patch and if they made changes and if I made changes and if susan made changes we can all profit from that so that's sort of the vision that I have and starting from devian I think we're in the position to go that road I have heard people in devian say why would you ever want to do that because those are the other distributions and we're devian we don't need to do that but slightly you know like slightly correct and slightly not correct and everything it it's a time saver in the end so I think it's a it's we are in a position where devian being a conservative this to distribution that prefers to take six years I think that's sort of the average time span of the step on that she used it in this talk six years is our average just development time for a feature we take our time but then we do it right and so this is the effort that I would like to start I would like to figure out what it is that we need to do with version patrol systems in order to maintain maintain packages and how can we get there and how can we make it such that other distributions are actually interested and join us in this approach and one of the reasons that I'm happy that there are very many different people around for instance get build package Guido and Manas unfortunately isn't here but I pretty much have his approach but there are other people um Stefan are you here Stefan Glendu there you go I'm sorry so many people um you you previously told me about an approach that that used quilt and they're really or somebody told me an approach that used quilt and then fit it back into the version patrol system and that first glance I would look at it and I was like my god like why would you do that but in the end you look at it and you're just like that's really cool and right now I'm not in the position to say this is the right way to do it and I don't think we will really ever be able to do that after all we're Debbie and we're all about choice but there are so many different ideas and I'd like to make those ideas come together so before we can define a roadmap on Thursday on what it is that we should actually be doing at some point in time so that we can produce some output so that we can actually take a step forward I'd like to figure out what people are doing and where you think the challenges are so maybe one of you has any input or any questions on or would like to voice a concern or I have the regular concern with importing upstream sources into our repositories because it didn't happen just once that upstream fucked up with some license stuff and took a picture from some site or audio file which they don't have the license for and when you put it in you have to rewrite history and which as everyone knows is pain that's why I personally don't feel too good if the workflow that you want to push or the workflow that we or agree upon would mean that we have upstream source directly in our repositories I think you're overestimating the problem I don't think so First of all the only problem you the real problem you need to write is something you cannot distribute at all so if it's something which is not the EXTAD EFSG3 it's fine to have it in history because okay it's not the EXTAD EFSG3 but it's not in the archive either so that's a couple of observations Well the second No you're still distributing it if you put it into your ECS Yeah but it's fine as long as it's not being legal for you to stay with it and the seventh point we're going to have the actual DNR which is going to have the very same problem Exit Is there any cases where anybody who's been sent more letters over Wrangling things that were in the VCS history but hasn't been deleted I'm confident I would say no I think if this is you know this is a fact about most of the distributed version control systems all of them have this same property that it's really hard to delete things in the pre-history and I think for that reason we probably know about it if there were people going around saying you have to delete this file from your history because it's copyright we would have heard about that I don't think this happened So it did happen to one of the up springs in package games and it's not just this one exactly especially in this area where you are looking for special artwork or audio files and stuff you very often stumble into such problems but I think I'm just distinguishing two situations the first situation is that off-screen or some key commits a revision that contains some unistrual visual thing right and that I agree happens on the top but normally what happens next is that somebody notices and you say VCS RM VCS commit and then as far as you're concerned you make the problem go away and the question I want to ask and I think the answer no is after you've done that and you push the revision and there are no branch heads on your site anymore that point to this file and the only way to find the file is say you know get gone find the thing yada yada yada has anybody actually sent any lawyer that's and say you have to remove this from history and I don't think it really happens probably not but I don't want to have this time bomb sitting in my VCS repository but you could still extract I think that's what he means is that you could still extract it and I'm sure that there could be lawyers that are not going to be happy with the first time this happens we rewrite the history of that and alter it I don't want to name a special German lawyer that is very well known for doing exactly that things well okay but as Ian said we can at least in with distributed version control nowadays it's possible to say we will actually rewrite the history and remove all traces of that I don't think I agree with this but he's on IRC and he wants to say it's an issue right when it's all very well said it's an issue but you know come within if they're on IRC they've got an internet connection they should be able to google up the case where it's actually happened because I don't think it has happened I don't think any could be a better threat you know nobody has been made to rewrite their history by a lawyer yet and it's possible that it might happen in a very small number of cases but I don't think that this is a problem that we need to address we can cross that way when we come to it well we had in the history cases where upstream was asked to rename its packages because of because of big companies insisting on their names for for for products which sounded very similar to products still they didn't ask to rename the packaging past releases that's correct that's one of the things I mean right now we have Debbie and Lenny out and we happen to find out that there is a package in there that has an image which is copyrighted what are we actually going to do I mean I choose Stable Release Manager like can we actually something else the name is a different issue because it disappears from current usage relatively quickly and that's what they're after right in the end of the name copyright content in a source code repository does not disappear it is permanently there and once it's there if unless you delete it from the source code repository it's still accessible to anybody and the point asking you to remove it is to make it inaccessible so yeah I I believe that it is a much bigger issue than the issue of I think as long as we're showing a big effort to remove such as they have exactly the same problem because they are and they they say that they are not distributing copyright protected material but that they are documenting the web at a certain point in time and and as far as I know they have been able to block off all legal threats because of mirroring and displaying copyright protected files but I think that before I mean and I think that the that the function of a of a version control system is very similar and could be argued with very strong position that you are doing the same thing like a web archive well I think before we get into too much of a legal discussion I mean naturally there are other forums for that it is a valid point and and I think it's we've already seen that there are a lot of different positions on it but in the end maybe none of us are the lawyer I think that the problem is that we don't need to ask the audience we don't need to answer this question by arguing about what some thought would think the law would be if some case came up right this being a this situation has been like this and the distributive version control systems have been around for some years now and we should be able to just look and see whether in practice other people have had this problem and if people have not had this problem then we can carry on and if they have had this problem then we need to take off and after all I mean this is the point that you Ian earlier on said after all if we actually get to the point where there's a lawyer's letter at Steve's mailbox and says look DPL you have to like do something about that and we remove it and they are not happy with that that's still not a point where they consume this and my understanding of the law um if you are actually trying to do it but you haven't like you don't have any malicious intent that's not necessarily something that's going to get you in front of court again if there is still a problem with somebody who is savvy enough to operate the version control system able to extract that copyrighted information then we will just have to rewrite the history and but I think we should worry about that at that point in time when it comes um is this an acceptable way forward I mean does it not does it does it give you a perspective such that we don't have to stop cold at before even even thinking about it because on the other hand um you can always say that I mean Packers games for instance I think it's an interesting sub project because you do have artwork a lot of it and there's probably a lot more hidden copyright issues than than with code because also the authors aren't necessarily aware of copyright for artwork as much as the coders may be sure but we're not we're not going to be able to educate everyone but it's something that if you're working for package games you may just have to be extra careful but the technical solution that we can argue about from a version control perspective is not necessarily something that is that the problem is not inherent in the version control approach I think the problem is inherent in the fact that there is a there is sort of like permanent storage like once you've done something um it's really hard to get rid of that I mean look at Google look at Web Archive look at everything that problem is always going to be there and we're just going to have to deal with it so if that's okay then I'd say let's move away from the legal issues and let's let's have a look at what we're doing at this point in time and where we would like to go is are there people who do you want to say I'm wondering whether the goal of finding common workflow is the proper goal what I mean that David is kind of peculiar in the even in the distribution market because we are a lot about diversity so while the goodness reasons are why Fedora has whatever why not solution and whatever else we have six or seven different bcs which are all quite popular I mean even at the most player we are a lot of them and you know we care about leaving the possibility of having a bit different bcs similarly why in the beginning I didn't know how to use a distributed bsa was looking through the proper way of doing things now we are at the point where we have quite a lot of knowledge on how to use these systems and the proper way for me of using gifts or whatever from a thing a package can be the best one for me but another guy can have another best way of doing that which is not actually which is not mine so I'm wondering whether we are really looking for the workflow or whether alternative we're looking for an interface with which we can communicate between different workflows and tools so this is kind of a provocative principle you know but anyway you didn't know whether we should look for a deep workflow there's one about interface is very important I agree with you that the maintainer particularly needs to be able to choose their own workflow however there are a lot of people in Debian and this has become a more rewarding case who spend a lot of their time doing nm use and whatnot and particularly derive distros and I think in Debian it's important that we support and encourage people to make derive distros and actually all planes do it and at the moment it's not the case that you can do an nm use right in in Ritzville it's not possible to do an nm use and what you actually have to do is learn how to nm use particular package because it's got some particular purpose and one of the things that I think we really need to solve is we need to get back to the situation where you can do an nm use of something without needing to take a course in maintainers workflow well this is this is one of the things I've been recently doing research on Debian adoption behavior and one of the things that one of the gems I'll spill it now but this is one of the things that I wanted to talk about on Thursday one of the gems is to say exactly that we can't or we should not standardize processes we should standardize the interfaces and we already have a lot of interfaces standardized because in the end we have the package build package and it is the way that everybody builds the packages so that is one interface and that's where we have to get to now for another distro that might be a different interface but there are so-called adaptive versions you can use R yeah but Manos isn't here I still build a lot of packages by running Debian rules by hand and that still works but no R doesn't produce the packages that the archive tours like to process well okay and then the archive is a different one the archive is the Debian rule spot I mean we get to the point where we have upstream we have package we have new version we have package we have sort of maintenance of the package and then we always have to have some sort of output which is like distro go build and that interface is going to be pretty much similar all across the distros whether it's rpm build or whether it's the package build package or whether you want to do it with that they'll be in rules directly that's one interface and I guess this is an important point I mean I don't think we are going to find the one workflow and especially not because one of the things that VCS package is all about is saying like let's not get into distro into dvcs religious wars even though you know a lot of it is currently about get there seems to be a lot of drive behind that but that doesn't mean that we have to look only at that or that we have to that we can forget about the capabilities of other version control systems there's no point in saying git rebase minus I has to become a part of this work that's just going to cut out a couple of people right now you were just laughing Stefan I think because this is part of your workflow isn't it maybe this is something that that can be addressed you know maybe this is something that can be represented in a different way but is it it is the interfaces that we need to define and and between the interfaces they are sort of common patterns I mean I find myself when I think about this I find myself always returning to that book of four the gamma whatever design patterns book that many of us have probably had to study in computer science courses which is abstractions in computer programming and they have adapters and they have different patterns that are happening between interfaces basically and we are every distro creates patches in one way or another whether we and in devian munch them all together into a div.gz file or whether we use devian patches and quilt or whether we use dpatch it's creating patches so that's a sort of common pattern why and and most of the patches are going to be associated to some bug report or maybe there's there's there should be the possibility of saying this patch belongs to this bug report so this is how the big picture kind of forms for me it's like I really would prefer to be able to create a patch maintain the patch have the bug report automatically be notified about the patch have the patch not necessarily be duplicated in the bug report but referred to the one patch in the regime control system and so on and so forth um it is a lot about interfaces and these interfaces are not the thing you can power what common concepts are that the interfaces need to talk about exactly yeah common concepts patterns right patches very and that's always the central thing there's a notion of what works currently called up moment which is where you connect to the devian archive um there's we have long maintain of roaches which we think obviously we call them unused but they're like they're like silly little forms I don't know that other districts have those too there are a couple of those concepts now and that those need to I think this is this is one thing that we'll definitely be talking about in terms of the roadmap like he finds something like a commons document something that can establish a baseline on which we can discuss um maybe it's not the one workflow but maybe this is sort of a meta workflow that that has different components and you can piece them together any way you want but if we can make it such that in the end you still have some sort of standardized like a patch is a patch all over the place and it because we're using distributed version control systems I can take that patch and actually track it not just copy it I think that would be a great benefit but on the other hand I mean this is definitely part of the idealism of vcs pkg it's not to say let's take Manor's way and force you all to do that although I really do embrace this way but they are they're already at this point with Manor so we are hitting points where we don't know what to do anymore as long as we don't have to follow his gpg practices or mine um but like one of the central discussions for instance with patches is should each patch be pristine pristine whatever you call it um in such a way that you can apply each of the patches separately and then you have the comfort resolution when you integrate all the patches or is is it a patch series where you can't take the end patch and just apply it separately I mean these things are things that we haven't resolved or haven't talked about but those are the kind of issues that that we should be talking about I guess there I think you should get away from thinking about file formats because our problem is that we don't we don't understand really what the problem is and so we don't understand what the concepts are that we need to represent and if we start thinking about file formats and protocols and specific provisional processes I mean that's all very useful stuff and people bring their own workflow to the table but we really need to understand what the actual objects are and how we manipulate them what the abstract concepts are and then see if we can come up with some kind of subset of this that can represent enough that everybody can do what they want which is an interesting point because now you're arguing basically that we should be working top down we should be finding the sort of like metal workflow that explains everything and then we can like charge the visit art and the dirt people filling it in and that's a very difficult approach to take because in the end you might be running up exactly against problems that are just not soluble but on the other hand the bottom-up approach which is manner sway and good build package and and and this approach and this approach all like sort of like taking the tools and and doing little things with it and then coming up with a big picture is a lot sort of emergent and it's a lot more powerful and and to to unify those two is it's really really difficult but we're facing it all over the place I mean that Stephen language I was talking about that as well he was he was saying like bottom up top down now at some point in time we do have to meet in the middle but I agree that interfaces and general concepts which I call the patterns that's pretty much the same thing that's that's something that has to be fine so I guess I'll add that to the roadmap a lot of you people who haven't put up their hands earlier when I when I asked who have you been involved in BC as PKG are there are there any like hopes that you have one of the guys on your mind was just the film the IFC is involved in the notorious one of the one of the guys on the IFC is involved in the notorious okay okay but notorious is not necessarily packaging it's a nice way of hosting but what is the charge and it all runs one accountant you don't need to create accounts for yeah this is the first I've heard of it but it sounds very exciting I mean caught up in the energy that you're talking about here and I'm sitting down doing an interview and being able to look at someone's patch history and see what the hell they were doing when they came up with this crazy patch instead of having to dissect it from the gift that you see it's a very useful approach I mean how many of you guys are doing packaging in the first place is that pretty much yeah I have touched the package yeah and how many of you are separating packages already using the patch or belt that's a little bit more than half I'd say I've had to use some kind of version of the process not counting the debut archive or CVS religious question I wanted to to sort of bring up which is going to be our family and we do we okay so we understand that we can't make it to VCS but if we say it has to work with SVM we might find ourselves trying to do something much more difficult than if we'd say it must be deep if you look at the VCS package whole page I've tried to sneak in that D in front of VCS every single time I use the acronym so essentially I mean SVM is very very popular and it it needs to be supported in many ways but to be honest I haven't lost hope that SVM is going to actually support this stuff a little better at some point in time well and also I mean thinking that the archive of the main is we are all implicitly more or less streaming some dvcs well what's the what's the difference between the two it's not that that one is SVM and that one has this sort of like centralized approach it's not even that the others are distributed it's really in terms of like how do you track content it is that the question of what does it mean to create a branch and what does it make a touch and modern version control systems the ones that I've named a couple of times before they all you they all look at it in terms of content and not in terms of changes and SVM is a very change set oriented approach now I don't actually know very much about dark side absolutely dark is very chase and mathematically proven to be right and all this kind of stuff well but but it can still track content to the point where you can have like a common ancestor and then you can have two people for 20 years working on two separate branches and then you can tell darks to merge them and it will not it might have a problem because of conflict and everything but it will not actually bar that let's assume that it won't that I don't really know but assuming into memory and assuming that kind of stuff but I mean that those are technical details and that there is a need for darks to be able to do that it'll it'll start growing that feature but on the other hand if you do that with CVS or you do that with SVM and you are going to run into problems because they don't have that that constant of content that's being tracked so in in some way yes I think that SVM is it's really hard to to keep that in mind but on the other hand if we I don't I'm not even but is this is this more about how we use the virtual systems to that it seems to me that one of our goals about this is more about come up with common interchangeable ones that easily share our change to the different distributions and whether it's what virtual trust is made in you doesn't matter as long as we have enough training you know to have an easy way to treat these changes well it does matter because what ultimately we want to do is we want to I think the only way we're going to get into this is if we make it possible to share with other you know supposedly you're working on then right you're going to need to have a cure right and so that you're going to need to be able to have your curial patch queue in devian and you're already able to be able to pull from zen upstream so because because that's the way that everybody expects now later I mean if you step outside the distro context where we're all you know using the archive and diffs and things and it's all going to come from the 1970s if you come out and you know into the current century you know except maybe like it's good it's coasting patches maybe they're saying here's my bra all from there right but you're the individual person will tend to choose a virtual system they produce and that's not necessarily going to pull that you're probably going to pull that one to access there that's not how it works the way it works is you use the version which also stands for upstream using or if upstream using using sdn this is the story about you getting back up from that's a different issue this is everybody but but but red hat if you want red hat and and deviant to share patches and they're both tracking the same stuff that's coming from upstream and upstream are also taking some of the patches back up this is exactly the use case in the scenario these whole distributed virtual processes designed for and let's let's separate a couple of the issues that are um now for discussion here because I think if we want to talk about them all at the same time we're not going to get anywhere now let's just start with here is and kind of go back to form from from the back to the start I hope I remember all that is that red hat does stuff with mercurial and we prefer git and I think we're going to get anywhere like to be able to exchange and track change sets or commits between mercurial and git at this point at least I don't think that should be our goal but if somebody wants to do that then somebody should do that it's more that if you have zen then maybe you can agree with fedora and red hat that you should be all doing it and git or that you should be doing it and mercurial at this sort of project level um now with any muse it means that you might have this git project here and you might have this visit our project here and then in mercurial project and you don't really want to learn three different burden control systems just in order to be able to do your job so now we come back to that idea of having some sort of abstraction a command that implements the common patterns and then figures out which version control system it is that is being used now can i come up at this one dimension and plug a friend of mine's program there's a program called vcs which does what it's name space pollution but no it's not a version of drops it's what it is and it's the program that figures out which version of drops it's what it does the right room for you when you can tell your friend that my program that tries to do this sort of stuff which is unreleased and I haven't really gotten any more he's also called vcs so now we have a problem but it's sort of a standard name I've seen your hand let me just make one more point which is the going backward which is um this is something that came up in the discussion with uh with you about the workflow I don't actually know if I had had the discussion with you or whether you were just the one that was referred to have that idea about um sort of having the representation not be in a version control system but have it be in both patches and when you want to work on something you import the cool patches and then you use the version control system to work and have all the features of the control system but in the end you you put out the patches again and one of the people in that discussion said look I'm not going to create feature branches I mean I'm not developing software as a package I don't need to create a whole branch for something even though it might be cheap but like heck you know like in the end I'm going to have seven different branches and every single time I'm going to make a change I'm going to have to ask myself which branch should this go on that's too complicated and I don't think we even have to go this far we don't even have to say feature branches are part of the workflow so if we instead can find a way in which the changes are represented such that they're interchangeable and and the version control system that we want to use can use those patches then we get back to the point of representation not necessarily file formats but sort of the concept of being able to have a standardized way of representing a change and then then we could get version control system agnostic at that point and Quilt is a good step in that direction but I don't know if it's the right one I mean this is this is stuff to be discussed and you do you want to reply to this in here okay for that we should agree if a patch should apply another patch or if a patch set up will be on its own and to exchange between projects like Fedora and DSB or Debian or even to other yeah that's like the question of the step model patches in the series and separate patches on the other hand so far I think at some point in time someone on the meeting just asked like for a case where this was really like a problem where there was a big difference between the two and I mean to everyone here in the room it's quite obvious right like there are conflicts come on there will be conflicts at some point in time but then like is this actually really a problem I mean are we going to resolve the conflict once here and expect our users of patches to do the thousand times for every single time that they use it or do we just do it every single time that we have to use it how many times are there actually going to be conflicts I don't know depends on your feature branches I guess yeah if one feature depends on another feature obviously but so maybe you should be able to do that what's going to happen is upstream take your patch right how do they do that well if upstream are in the modern world they pull your feature branch and then if both upstream and the maintainer are in the newer world but especially upstream if they do that if they do that and you're using and everybody is using the same version processor then you don't have to notice that this is coming but not everyone is going to use the same variant processor so we need to sort of find a way this is one of the crucial questions are we trying to support workflow where we choose the different versions of system drops it's not the only problem even if they are using the same version of system upstream maybe look at your patch which is functionally fine that they they spot that you didn't follow our naming convention and they change some viral names and then again they cannot pull or maybe they pull and they have a patch and when you pull you get that you retire your own feature branch and so on I mean it's not just a fast forward using it on your own you will need to to work on that you had you had a question oh yeah I was just trying to mention that there's an increasing number of there's increasing support between different distributed version systems for each other's protocols and formats that seems to be getting to become to be becoming less of a problem LBT on IRC also suggests differentiating between feature effects and also the basic unit of operation of the patch I mean at present the quote is knowledge it does only they're not everything is a patch they're not there's no distinction between each direction well this is something that I thought could be handled with namespaces but that's that's the clarity and sort of that's not a rule but that's sort of just a guideline that you agree to I mean I use Git a lot and Git allows you to use a slash in the name of a branch so I can say my devian slash docs branch or my upstream fixes slash man page typos branch that gives me a sort of impression that someone who uses a file system that this is sort of like a name space right it's a upstream slash man page fixes is something that is destined to go upstream but this is convention this is something that that but this is also something that you know it might make sense to just agree upon but interdvcs interdistribution yeah the feature versus fix right and then variation is going to have a different flow because you're more likely to take fixes right and this is this is part of the sort of like bottom up thing again that we want to do I mean we could we could go ahead and like define a taxonomy of these different namespaces and then impose it on everyone and you know send thugs around and beat everyone over the head who is not doing it properly and probably fail with this approach because we're volunteers and we don't like to be told what we're doing um on the other hand if we actually can figure out what everyone needs and then come up with a proposal that suits everyone and then actually condense it as soon as you build up a sort of inertia of a standard then people are going to be like okay I prefer this to be called you know and I prefer British English spelling on this but fine I'll go with the American English spelling or something like that because there's a benefit in using it but at this point we haven't even gotten to to be able to say what are the different namespaces that we need does it make sense to differentiate between Linux and VSD on the namespace level for instance does it make sense to differentiate between Ubuntu and Debian does it make sense to have a different differentiation between rpms and depth file formats there are a lot of different ones but this is this is definitely an open question and I'm hoping that um here at depthcon obviously it's kind of difficult to um to to ask people from other distributions we almost had a couple of people over but um and they were actually scheduling problems um to talk about it but at lca for instance we talked a little bit about this and and came in in some sort of like understanding but didn't actually manage to produce any output at this because the ideas are new and everybody wants to think about it which is why I think a roadmap where maybe the first step could be to define what you know what what is it that what are the different types of patches that we want to track which goes back to everything's coming um patch or feature patch and fix patch and Debian I think this is a very hairy we should be thinking not about what the purpose of a patch is that's that's something that people can work out for themselves um we should be thinking about the data flow of patches which patches going where what's it against how do we share it how do we review it how do we commit it or what you just said which patch is going where so that's sort of the purpose of a patch I mean I'm not saying the purpose of this patch is only features a patch a patch doesn't by itself go somewhere right always whenever you submit a patch somebody there's a there's a like typically an email right when you say this is what it is here's a you know maybe that's actually a bubble ball or something like that the patch has meted up no no the email that you use to submit a patch is not metadata for the patch right you put it upside down what we've got here is an interaction between people with the patch as a kind of like parcel they hand it around but maybe we don't want that sort of interaction maybe we don't want to interact with people I mean there's this inherent problem with interact we can interact with people with the door of people on one package right now but like damn that person just went to vacation and it's gone for three weeks and now we're stuck we can't we can't continue working but if you if that person was following the same sort of convention in the version control system that we are we don't need to talk to them I mean I'm not saying this is the goal that we should strive for but we should definitely try to avoid creating bottlenecks at this stage but your red herring comment is absolutely correct because um maybe I'm maybe what I just said about like all these different dimensions what you should differentiate between patches maybe that's completely over engineered and maybe it's maybe a patch itself doesn't have a purpose but only the time when the patch is used or accessed by another person then there is a purpose so when I go and look at red hats package and decide which patches I want to take at that point I'm making a personal technical decision about maybe a political decision or so about which of these things I want and that's not controlled by the person who broke the patch that's controlled by the person who's taking and that's why when submit a patch you include an email it's so that you can you know if you push the patch you have to explain to the person who's going to take it why they should take it well there's there are a certain subset of patches that will get applied upstream and hopefully it all trickles down and upsets your your own tracking of that pattern sure you know I feel like we wouldn't have to deal with patches at all aren't we thinking too much about patches we're thinking about modifications we want to like mbam you want to track the future like block assemblies you're not necessarily interested in the patch itself you're interested in the description the back number upstream you're interested in the patch series name that's what you want to track longer isn't it so I think that's why it's important to patch plus the icon metadata but the information you have and that's what you need to have to track to get your future but you might be several of them you have to track the full features so in my opinion this isn't even about version well it is about you need more control system to track this efficiently in a way but it's more about it's changing these modifications between distributions to what you want to do is that something you basically do not work is that so you're talking about like let's say you have a patch and then you have an introduction to that patch whether that's going to be an email or whether that is stored in the world or whether that's the kit commit message or whatever um a certain number of like fields right but fixed field and and contributors field and whatever it is that you might want to track um that's I think that's one important thing that would make sense to standardize because there are a lot of people now using version control systems to fix bugs and there are at least as many different approaches to track which bug is currently being fixed whether it's called devian space buck colon than the buck number or dead buck colon than the buck number where what I've seen what I really like personally is um buck colon and then dead bucks colon slash slash and then the number or something like that you know like different um ways of representing the information that that should be associated with this patch but not necessarily um it doesn't have to be like mandatory information it's information that is there that you can take and so everybody can stuff additional stuff onto that patch um buck numbers and so on and so forth and make it grow so I agree this is this is the sort of one of the points that we should agree on on the other hand what I would really like to be able to do is let's say suzer fixes this bug in mda dm for me and I pull the patch and I'm all happy because I managed to like get it out in half an hour and Friday night and I'm off into the mountain and then on Monday suzer finds that they actually screwed up but you know it only causes complete data loss in one tenth of a case or something like that but I don't know about that you know because I don't actually track the patch that they that's what I mean you will track what it is yeah I definitely want to be you get some kind of central point which knows about all the pages and all the distributions and those this patch is like this well I will have the same name like future so and and it's usually modified this patch you know if I buy something well whether that's a central entity I mean now we're getting into the the uh super mirror idea which you know it's a worthy cost I think but um I also I also raised that one point in time one of the concerns about launch pad that it's not distributed that um I don't I don't know whether that is I mean then you have a central entity that decides that you know those 15 distributions have worthwhile buck tractors but those 27 over there I've never heard of them but no I don't mean centralized by for every distribution but more for everybody has the possibility to set something up to do this so maybe that distribution that distribution that distribution control itself you can suit with redhead or you can suit with gen two or you can suit with Susan but you don't have to and they can stay more so if it's confusing to make this patch on friday if at that point they give it a name their name specs which other people can fight but essentially they publish it and then later when they are dated on monday they somehow update it in the same place whatever name that you pulled on friday you know there's a possibility that some crumb job could go and text that and say we're making saying they updated this action here's the change message do you want to do anything about this but that's not the pull not push not not have like some sort of central entity where you have to like check your path in and then it gets approved and then like it's pushed out to all the distributions you know I that's not going to work we're trying to obsolete upstream or into or or take a lot of work off well now we have we have a couple of packages where there is no upstream anymore we have a couple of packages where upstream simply disagrees with one of the things that baby and does and we will have to keep this patch forever but then fedora doesn't really care about that patch so there is this sort of differentiation that I want to make but yes if on monday you come back and then you either go and sit down and say let's see what the world has done over this weekend and you say sort of like mr pull or mr update which is this multi repository tool by joey has pulls in all your changes and then you go like oh suzer have found this cool data corruption bug and just upload a new package myself now as well and the sort of pull approach I think makes a lot more sense and so that you can also choose you can say look I really really appreciate fedora and I really appreciate gen2 but let's say suzer doesn't work because I don't like you know whatever it is um it needs to be your own decision I wonder how many upstreams there are that either don't want our patches or that are sort of dead are there any numbers about that so it's not going to be maybe investing too much power into something that just affects a very little amount of packages in real that's a it's a valid point I don't have any numbers on that does anyone of you know I was talking about the data extractions from and slot cam on all the pages and it was like 40 million slok added by them so I think so it's really not a small amount about them in these cases we don't really know whether that maybe a maintainer is simply not pushing upstream or whether upstream is actually dead or this is definitely something that that should be figured out or could be figured out but it's about a point of course if this is a small number then then no we don't actually have to invest a lot of time on it on the other hand I think all those all the serious big programs have patches that ought to be upstream yeah and many cases those are the same patches that fedora wants to exactly and then they have to sort of like level underneath upstream to make work easier for them not to have to include depth and that kind of stuff and then James I agree that I think the the case where we have a dead upstream or an effective fork in the distros is not the common case so it shouldn't be what we optimize for but I think that the same things fall out if we have the the distribution processes more similar to the upstream processes so taking a patch from another distribution looks just like taking a patch from upstream then it makes the collaboration easier while while allowing you to do the effective fork kind of thing but not encouraging it let's say well for instance I mean postflix is a software that is a well maintained it's working perfectly well and it's used on pretty much every single distro now there are patches in debian that vets of enema has basically said I'm this looks good but I'm not going to put it in until you can tell me that this works well across all of Linux because you may be debian but I don't really care give me data you know make make fedora use it and so on if at this point in time you have to sort of try and go right you have the upstream here and then you have all the distros there and if you can have this level where you can have cross distro exchange that is so simple that you can literally you know like click without using a mouse that kind of thing and having the patches is bad generally unless they're unless they're static unless they're stuck in the package that's generally a bad thing so you can if it's just easy just to create the patch and stick it in the package and get it moving upstream even if it doesn't go straight in then then that's going to be a useful thing because I'm maintaining you see the ISE current and there's this first starter text that pops up and it will start for the first time and don't have a conflict by yet and we patch it into go connect to ISE dvn org and go to hdvn for infinite support and the same goes for you come to the patch it to their likes of course and so this comes also to your namespace question there is a need for dvn and separate people to make space in this case well on the one hand I mean that everybody should be able to decide themselves what they want to patch but it would be nice to be able to say look like worlds these are deviant only patches don't even bother looking yeah whether it makes sense to have that or not this is this is one thing that should be definitely addressed to tag the patches somehow these are private patches that don't most most probably don't make any sense by any other distribution which would be us help very not a very much amount to be able to get the patches that you're going to have back to us if they do take their patches properly we don't have to go through all of them and see what makes sense to have two or three more to what I have in dvn right so how long does it take for you to read the 60 character description into these patches like um so like whether it's worth to sit with every single update because they might they still have this branch that they need to maintain and it might or might not with every single update they do contain another patch that might or might not make sense for me right that's hidden somewhere probably there isn't that the patches aren't tagged by a bunch of us whether you want the problem is that you're making the same decision on the same patch over and over again if you only had to make that decision once and you could tell some computer somewhere look I just don't want the ability to help message patch and then you never saw it again until you know unless you actually went to looking you know can I have a fullness patch including ones I'm rejected earlier then then the number then the amount of work you have to do is every time a goon to introduce a new patch once you have to decide where you like it and that's probably more reliable than having a goon to tag the patch in a way that means that sometimes you don't see it because the ability to maintain a broke some crappy thing in the world feed well then you know what you could do is you could say well this is a good purpose but I don't like the implementation and then the system would automatically tell you when they changed it right but if it's if it's like a branding patch then Debbie and it's probably not going to want to see it if it just said Debbie into Ubuntu then you're probably never going to want to say that patch but then if we fold in like a grammar fix into the same patch then you can probably just play must for merging two distinct patches into into one patch file because you know the Ubuntu the Ubuntu developer who does that should just say well this is applicable to Debbie and so I will go and push it to you know say I've got this grammar fix I think you should really take it because it affects Debbie into like this shouldn't be a replacement for developers doing the right thing it shouldn't be I've I've put it in the I've put my patch in the namespace which means Debbie and might see it at some point so I don't have to forward the patch it's the same thing with the with the mailing to the derivatives keyword in the pts that shouldn't be a replacement for attaching the patch to a relevant bug report in the bts because that's the way we should submit patches yeah I think Ubuntu is a bit of a special case because Ubuntu is a Debbie derivative they have a much bigger responsibility to tell Debbie about stuff they do than the Dora do Debbie right but one thing that would be nice is if you could if something would automatically tell you every time Fedora invent a new patch for their you know Fedora can't be expected to bound Debbie but there's no reason why some Debbie in the sheet you couldn't be occasionally polling the Fedora repository and saying oh yes I see there's a new patch here it would save you a little email with the paragraph of the description and then if you decided you know there was some brand name patch there's some stupid thing you'd ignore it and if you liked it you'd say oh how about the patch maybe commit it maybe track it yeah but ideally without 27 different implementations where's the funnel yeah we could probably do that I mean we we actually we have something in Ubuntu could harvest which watches for it's designed to watch for low hanging fruit because we we have a bit of a problem with people who attach a patch to a bug report in Ubuntu and because there's no one caring specifically for that package it just gets ignored but like there's a patch there that's like it could be 10 minutes work for someone just to make a little improvement to and send it upstream but so we we have something we first watches the patches in launch pad and it also pulls for patches and other distributions so I I think we could probably turn that into mailing the BTS as well if if you desire but then then we get back to the point that I think Ian also raised earlier that now you have one implementation for launch pad and one implementation for their bugs and one implementation for bugs is allowing one implementation yeah sorry I wasn't proposing that as a long-term solution right sorry I went a little off topic but I feel we could we could help Debbie into watch other people's patches but yeah sorry I don't mean we should have us taking care of everybody's patches it's just that maybe we could get to the point where we have some sort of like basic patch entity or modification entity or whatever you want to call it the standard way to go to some other district would find out what their patches were and pull them and find out when they've been updated and identify you have to identify the pattern you have to identify what the patches are you need to be able to track when they're different from the last time and all that kind of stuff and ideally maybe have that patch be identifiable so that if you take it and then add your own metadata and then somebody else takes your patch and also pulls from Fedora like a wunzu for instance pulls for both and then the patches emerged and then right and then the bunch of developer has to you know you know if they're identical good if they're not identical then they have to like yeah or something and they probably can't have this the change is the change is identical I mean right um maybe but they might not if the change is not identical then they have to right but in the way then a version process is exactly then this is I guess why we're back to very control systems whether the version control system is the right tool for that but I I do I do agree with the comment that this is upstream this is they they're the ones who you know you should be you know if you're a maintainer for a package then you're subscribed to the bugs on that on the upstream project and when Fedora create a patch they should be attaching it to a bug in the upstream bug report so fair enough let me just take that one step further um now let's say you're on that on that Saturday afternoon when it's raining you're home and your wife and the kids are at the zoo now it's not raining beautiful and like your wife and the kids are at the zoo and you have it's semi so you know outside right you have three hours in which you can do whatever you want and you decide to do any use you have three packages that you would like to fix and this one is skip oh yeah yeah you're going to be like and and upstreams are like that as well and you're going to be like okay I just wasted two hours during three different version controls no you've you've just you've just described like a bunch of development so I'm very very keen to work on this stuff we you know we touch all these things it's quilting and then the next one's detached because you're touching so let me tell you how I I work for a bit different come on for two years and let me tell you how this works you get the source code you are sick the thing you just unpacked into a separate build directory you try to build it if it builds excellent that's that's you know half an hour safe already then you edit some file randomly but not in the build directory and every time you change anything you are sick and you build only everything that's the only way to make an interview to a gaming package without having to spend half an hour or an hour or two hours reading incomprehensible old versions of cps and a file is to try and figure out why it's on firing this over here in this package isn't that or the other right and every well that means a bit worse for this than most others because our you just improve to the point where you know I would say to be honest I don't care if I have to learn four version of systems that's easy right there's only six version of the system that anybody's likely to use and if I have to know all of them that's fine I don't have to want to have to learn six different old obsolete versions of of cps or strange pre-debate things that might be copied into the package directory and now they've got unpacked untarble and it'll be in but every package is different and it makes the impossible so maybe interview is very much too levy and specific if we focus on changes and then we say like I really should be putting that change upstream yeah but to continue my point sorry I was just saying that we should make it we should make it the easy the the obvious the easy thing the impossible thing to not do to just push these changes to the upstream bug tracker rather than inventing an entirely separate like infrastructure for doing all this it should be based around the upstream project so that you by default you create a patch and it gets attached to like to go to go a bit too far you just create a package automatically attached to a book about an upstream and all the distribution developers subscribe to it so they immediately become aware of the patch existing but upstream don't have a bug tracker well yeah right it's all really lucky upstream you know i mean i work now my day job i work for zen upstream and we got a bug tracker it's it's excellent it's a lovely high pot nobody reads it right so you know if you follow bugs in the zen bug tracker well sure okay so there are projects like this but let now let's say we have this project we have zen and you decide i can't work with that now you're going to take your depth in bug tracker or whatever it is and your own version controls we make it work and that if you make it work in such a way that um this is something that accounts for everyone that that even fedora could use and you write an email to them and go like hey guys this sucks right doesn't it um let's just use this um you know like as a proposal you are not going to possibly not going to force them to use the living bug tracker for fedora maintenance but maybe you can have your like in um like in uh repository bug tracking like sill or or bugs everywhere that was um it's sort of like standardized approach where you can account for the fact that upstream is useless and you would like to feed it back but you can't so you have to stop like that one step shorter i think this this notion of trying to deal with upstream bug trackers if you bug trackers at all is is a bit of a great error i think we should be not thinking too hard about it it's useful to be able to link things to bug reports maybe um automatically send out your bug tracker about it maybe um but what we really want is a sort of federated system where i choose who i'm looking at and who i'm pulling from who i get notifications about and that's done by software run for me by my infrastructure team or by my polo or whatever yeah but doesn't that doesn't that that encourage effective folks that you you just have to don't care about anyone else if you don't want to i well thank you for you what it does is it means that the person who's receiving the patch you're after all is probably keen to have it we need to make that easier the problem that we have at the moment in this area is that we can't find here then you can't find fedora's patches easily and see what they're about and track them and all that kind of stuff and if we could do that there was a way for us to at least find out what fedora's patches were then we wouldn't you know you don't want to go diving around like that we just want to we just want to code it i suppose then does this approach with uh defining a common workflow really get us any further to receiving fedora patches i mean we can change our way of doing things but we can't change it for the fedora people for us who the people for right head and who acts as of the and i'm i'm not sure if this approach really will get us that cooperation more easily but i think there are two dimensions to it on the one hand there is this case where we have potentially have to interact with multiple packages within deviant and we would like to have a sort of like more uniform approach so that we don't have to deal with different systems and every single step and we can actually deal with separate packages i mean ask for the security team they would probably really like being able to do the same thing for all packages um that's one dimension and the other dimension is that going and saying and offering to fedora is sort of like cooperation and it's not that it's not that we are defining this as the way and i'm saying look fedora use it or don't it's more like we would like to figure out what does fedora do and what do we do and for me kind of come together and i've talked to a bunch of fedora people and everyone who is involved in fedora is that um attempts to to use distributed version control systems and they are thinking very much in this along the same lines they think that the patch management is essential and needs to be that patches need to be trackable and they're they're all ears for you know like i mean fedora is not like you're debbie in now i'm not going to talk to go away or something like that there might be some other districts that are like that but fedora definitely isn't if we can find a way together that is conducive to everyone and then to sort of have it there i mean if you as a maintainer decide you don't want to use it i mean it's your own freaking fault don't use it it's fine there are a bunch of uh base packages we happen to have a distribution sure and it would just be made easier i mean in the end well in a way we already have this it's kind of 1970s and we ain't located but there are patches that are diffs there are email lists that let you know that there's a new diff out there and there's mailman archives with url's for the long term record of those diffs and that's a push approach right well you you subscribe to the mailing list and you get the push or you pull from the url in the mailing list archive um and everybody uses that at some at some level that is something that's common well i mean it's not a bunch of people who don't identify reliably and automatically whether some particular change is a new change or an update for an old change or an inversion of a change and it's obviously no but it's it would be possible to build such a system on top of that it would be possible but you know that's just a question of what infrastructure do we use all we need is a protocol that lets us automatically determine whether this branch that we have here is now you know for example whether the fedora thing that we pulled last week is now the same update and let the fedora people say have they taken so they can look at our repository and see whether we've taken that change so that you know they can talk to us about it or you know there's also a reason why we want to know how they're taking this change on the one hand i completely agree with you this are are there and this has been working forever but on the other hand six seven years ago we didn't have any usable distributed version control systems and now we have them and in some ways the entire development cycle is changing and i'm just wondering if there's not like a way in which we could serve on that way and make it easier but on the other hand an important part that i that has been coming up over and over again is we can't really over engineer anything i mean we shouldn't right we could make this as complex as possible but then a we're not going to be able to sell it to anyone else and b it's going to fail all over the place and c it's actually going to take longer to learn than four different distributed version control systems in one afternoon so the question of is this something that's worthwhile doing and what's the scope of what we're doing and what the solution should be is an important one i that's the feeling that lunch it doesn't do it doesn't do very well at patches at the moment it does well at bugs but not at patches and the only reason why it does well at bugs is because there's an adapter for the debbing bug tracker and there's an adapter for bug zilla and there's an adapter for this bug tracker and while that works that doesn't necessarily scale to the point where i mean if like let's say the kid kernel starts to use bugs everywhere or is still we're just in repository bug tracking and very cool by the way and hopefully something that we will also be doing at some point in time then if the package that you want to be maintaining uses one of those you're at the mercy of the launchpad people or you have to run your own instance and say look here's my new adapter and i'm making it happen now let's wait three years and it's in a stable release and now i can actually make it happen it's not scalable in that way whereas if you have an approach that that sort of like standardizes the change and i'm not i'm trying to say like let's keep this keep it simple but no simpler right um if you have that change then you don't actually need this level of abstraction any then you don't actually need to have adapters for the different parts but i think i think there's i think there's something you're right to have an adapter so long as we don't need that end square right if you're right if we had to write a parser for sr games and a parser for debbing source archives and a parser for git trees and a parser for mercurial trees you know you write 10 of those things and that would be that if you need to write a converter for every one of these three we are they never keep that set keep it decentralized at the same time or it's to be very large but probably just have some things we can we can learn from because it's been doing this sort of thing it had the idea for bugs when it started that it should be tracking things in multiple places because they they exist in different systems and you want to know when something's updated over here so you can update it over here so there's probably things we can learn but perhaps the design isn't one we should consider well baby and has a tool like that as well um we can track um launch pad and bugzilla bugs and actually have automated messages sent to our bug tracker and to the upstream bug tracker about changes to the individual bug reports but i mean now we're back at the end squared part because we've we've implemented bugzilla and you've implemented bugzilla and yeah and this doesn't scale i don't know if it's feasible if we can find a format that will actually be um the one thing that everybody would like to use and that that's compatible with everyone's workflow but on the other hand um if there's if we if we manage to come up with something that is suitable to all the needs then it's just gonna you know the people are going to start using it one other thing that i'd like to take years which is amazing that our current system doesn't support which is the ability to find the source code for a package so we've got the lintian lap which has all by his own pack so it doesn't have patches in the bottom the reason there's no patches in the bottom which is to run the program to apply the patches and we need a system where you can get source code and do you know lintian lab like stuff or other kind of research automated source code scanning and all that kind of thing without without having to understand how the package works or run some kind of program is that the package version 3 format well that has to be The DS-18 is going to implement this in the future. It's going to have something like source system in it, with all of what is currently stable, testing, and answering, having unpacked the whole source of every package, with all the patches applied that are currently in the million and 50 cents. I hope they're going to use GIN for that. I hope they're going to use GIN for that. I hope they're actually integrated with the snapshot that they've been done, or because it's essentially the same thing. It should be doable, yeah. Right, but if you pick some package where the maintainer has done a couple of carpools and a pile of diff GZs inside, right? I mean, there are plenty of packages like that. And, you know, you look at the source tree, and what you get is two carpools and a pile of diffs, and you think, that's not the source code, right? I can't run my C code analyser on that. Right, but this involves running the package in order to have situations where you don't want to run the package. But you don't know what point in the build would happen. I mean, the thing is those packages are totally idiosyncratic. They exist in a weird other planner or something. Well, I don't know if you should have all of them but I'll patch it to quite a bit. No, that's not how, that's not necessarily what you're going to build. That'd be something which impacts one tarboard and builds that, and then deletes it, and then impacts the second tarboard and builds that. Right. All right. Well, I can do a short recap unless there are a couple of other comments. I think there were some, yeah, James. I have another side aim for this work, or at least the work I'm doing, is to make some of the tools we have and some of the things you have to go through a little bit more sane and a little bit more like the things that the rest of the development world does outside of Debian and outside of district development. I don't know if you've ever tried to walk a very good developer through their first Debian patch. You've got to download the source code. Right. Now you want to apply a patch. Now you've got to work out which patch system this package uses. And it's just things like this. I think we should try and not continue to, we should not add to this kind of madness. While we can't solve patch systems and things like that necessarily in one, with one tool, then we shouldn't add to it. And we should build on top of existing development practices rather than going in a completely different direction. Because I think it would be very useful to distribute developers, if upstream developers were at least able to step into district development without having to learn an entirely new toolset. You would find a critical patch in a version that they know you ship and they provide you with a patch which you can instantly upload to security or whatever it needs to be where the transition from upstream development to district development is not a huge chasm in between. It's just you're targeting a slightly different platform rather than tripping over yourself trying to learn all these new tools. I think also this goes for users. We've got a lot of very technical users who are excluded from making changes to their own systems often by the utter pain of doing what happens when they need you. And essentially, if you're not fully up on devian development and you want to make some change to your devian system, you might as well get the upstream source to go through that because that would be much less painful. And only the resulting thing won't quite work with your devian system in quite the right way. Am I correct in saying that we're getting back to the interface's question? I mean, if we manage to define an interface for what it needs to modify a devian package, then no, we might not be able to change all the DBS users and all the tar ball with their own little patch system that rolls inside devian rules make statements. We're not going to be able to convert them at one point in time, but if there is a sort of interface that simply says this is what that modification looks like. And we're pretty damn close in terms of that because we have devian patches and the sort of understanding that we put a diff in there and that diff gets applied. And that sounds pretty good. Except if it's quilt. Except if it's quilt. So, there's still... Are you talking about the series file now? Yeah, you have to add it to the series file but not if it's not quilt. There's actually a wishlist file you can sell. Maybe. I think we can get a lot of this by just building on top of distributed virtual control tools because a lot of the things will become the same then, but I'd just be wary of building distribution-specific tools on top. And while interfaces are important, incredibly important, and it would be good if there weren't 150 million tools for providing a patch in that set interface so that we could just say if you want to modify everything package, start here. If you want to get into devian development, start there, but you'll probably end up where you might find something which suits you better. But if the interfaces are defined and there are 150 tools in between, use any. Yeah, but use any is a pain to people getting started. You want to say use this one. You want to be able to tell upstream here is the one-screen wiki page that tells you how to do it. And it's not a wiki page of pick any of these one wiki pages. It's just the thing of here are 150 equally good ways of achieving the thing you want to do. And people go ah! You might consider them equally good, but I have no idea what you want to pick. If you can just go Yeah, it's part of it. But if we can all come through this process, we can come to the agreement where we can just go here's a good way to get started. That's what you need. You don't have to say this is the way which will solve every single problem here's go this way. You might hit some problems later on in which case you can switch, but you'll know enough by that point to know where you should go next. Yeah, and if you define the interfaces I think that's when those 150 tools can easily evolve. Because you are defining that this is what a tool has to do. And whether it's implemented in Ruby or graphically, with a graphical user interface or whether it requires you as long as it gets from A to B and A and B are defined, that's what it does. You can't define the process. You can say this is the recommended way of doing it if you don't have another preference. But if you do have another preference well, here are 149 to choose from. Well, think about particularly the upstream or end user workflow the most obvious workflow for an upstream or end user which is how why it made a change. And there should be one way of doing that and what we come up with should work should be possible for Red Hat to improve something that looks almost identical except maybe the Ruby has a different beginning. And that's the workflow that I personally like to use as well. I just kind of like to concentrate on the change and then all the other stuff around that is kind of like, like, I mean it's a big goal of it. It would be good to know what these interface are. And it doesn't have to get you to a perfect situation as well because these people aren't these people aren't going to be modifying Debian directly. We don't have to make sure that the tools like ensure that they get a perfect patch which doesn't break and anyone uses them. They're going to be going to review they just need to be told do this and then submit the review and it will be a painless process because we'll be able to review the patch and either tell you what to do or get it in. Well, I'll try to recap pay attention because if I miss something you get to point out what I missed but I think we raised about four very important points or at least that's what I took out of this. First of all, the thing about the interfaces I think we've all reached an agreement that we can't really define the workflow but what we can do is define the interfaces that's a stupid term right now but define what the concepts are and that actually leads me to the second point one of the things that we were talking about is this sort of common pattern concepts what exactly does it mean to be a patch or are we talking about patches, are we talking about modifications we should get a clear understanding of what the vocabulary is that we're dealing with so that we have a baseline to work on. Another point that was raised then was basically we had one question that went into the direction of are we doing over design too much are we trying to achieve too much is it really realistic what we're trying to do how many conflicts are we actually going to do are we going to face throughout the lifetime of the package how many packages are actually divergent from upstream or where upstream is dead does it really make sense for us to look at an infrastructure that that detaches us from upstream or should we really encourage work with upstream that was one of the things and the other one was two dimensions that we were looking at inter-distro and intra-distro dimension trying to figure out a way that is consistent a consistent way of making changes and maintaining a package within Debbie and then a question of whether that should also apply across distros and possibly across the version control system I don't think we actually reached a big consensus in that one other than the fact that we might need to start small and when Zach was still here one of the questions he asked was about the one workflow and possibly have a tool that sort of implements it I think that's a notable goal a nice idea but I think we're going to get there anytime soon to have this sort of like packaging tool that you just say create new patch and then it does everything automatically independently of what distro you're on and what version control system but I think it's a nice idea it's a good maybe like idealistic goal that we can strive for but in order to get there we need to be able to define what the different needs are that we need to address and the last point that we were talking about just now was sort of it ties into that earlier point the sort of standardization to make it easier for people to just approach a package and be able to use it without having to learn the tools but I think that point is sort of overarching because we have different distributions we have different version control systems any solution that we can come up with if we agree that it should not dictate a version control system or require everyone to run that in then obviously it needs to be some form of abstraction but I guess it's for me the most important point is certainly about the interfaces and that also includes the definition of what we think is metadata or what is the purpose of a patch maybe the context of the patch like is it the person polling that determines the context of the patch or do we actually already determine somewhat of the context of a patch as the publisher do we say this is a specific patch you don't actually want to look at it something like that so these are all the different points that I gathered from the discussion is there anything that I left out you want to be able to write them down because I guess well I we did have the legal discussion at the beginning but I kind of tied that in with the question of whether we are over engineering I thought it was interesting that the other point you raised was the sort of the second time the second point you raised you argued that actually you were wondering whether this was not too much effort because maybe the upstreams are all there and cooperative and maybe we're just not seeing that but for me that was sort of in a little bit of a contrast on the one hand like wondering what this is really necessary to do and on the other hand putting up for discussion which I thought was a worthwhile discussion the question of whether this is something that we should this version control system is something that we should pursue given that it might get us into the danger that we have copyrighted material somewhere in the history and can't get rid of it I fused those two together because for me also the question of is this really a danger is this something that we have to assess and then we probably have to assess at some point in time but do we have to incorporate it into the solution that we find at this point in time so there's a lot of that what exactly are we trying to do how much of it are we trying to do that sort of overarching method question which we didn't resolve today and I didn't really expect that and we can all resolve that on Thursday when we redefine the roadmap but and then there were a couple of other much more specific technical tasks the interfaces, the data definition the concepts and I thought those were very valuable and I think on that basis we should be able to say like this is something that we have to do first and then once we have that then we can take the next step and possibly move in this direction and in all cases there are a really existing solution good workflows that people can use I just think it doesn't hurt to think about what happens next and how can we actually make our lives easier because in the end I really would prefer not to spend so much time on packaging I like to write the patches, I like to change the code and make them testing I even like that run it and you go like yes it works great exactly, the zoo but I really rather not have to maintain feature branches it's not one of the top priority things in my life at least alright, well thanks all for showing up it was a pretty long discussion, I don't have hours