 So, welcome everybody, we are not so many people here, but I hope for an active discussion because it's called Roundtable, we are one round room and we want to discuss everything. I just want to give a very short historic overview about the science. You see, we had a mailing list in the beginning and it evolved to something where people are really discussing and working in 2007 and don't care about the names, I'm way too active in this list. These are the list of people who are really working, Stefan and Sylvester, Sylvester is here and there are other people who are working on Deviant Science and more or less packages. Here's a list of the people discussing packaging issues, so we have some active crews since 2008 here and I really hope that these bars stay here solid for every so we will not lose people and increase a little bit. Then there is another group called packaging Skycomp, which was by chance more or less not really competing but in parallel but we try to make it connect to Deviant Science and you see we are working on this, people are now working in Deviant Science, so to avoid confusion. The x-axis is wrong, definitely wrong, it should be, I don't know why, this is 2011 but the others, I'm sorry, take this as the x-axis, I don't know why it's wrong. This is a scientist, he has detected the fault, so this is where these people discussing, so we try to avoid confusion inside Deviant Science, this should be connected in the Deviant Science team. So these are the uploaders, so what is really uploaded by Deviant Science team, you see we have some increase and in my opinion this is quite a good sign that Deviant is featuring a lot of scientific packages and we want to make sure that every scientist is well equipped with solving Deviant and here in comparison the Deviant Psychome team uploads, which is a little bit decreasing and we think we join soon. So there is some interaction between Pekake Skycomb, but I think it's nearly finished and is kind of friendly takeover, whatever. So we want to do in Deviant Science, what do you want to continue or want me to I can chat about this one. So what we would like to do now is to highlight that Deviant has a lot of scientific packages, so it is something that we haven't been very good at, I have many people who are coming to see me on a daily basis and asking me so what do you think about scientific Linux and so they've got a very good visibility over the internet and the Linux world because everybody thinks that scientific Linux is shipping a lot of scientific packages, which is not the case. Basically CentOS plus MPI and a few others. While in Deviant we have plenty of scientific packages, so one thing that I would like to work during the next few months before the next day at Conf is basically do some advertising to show that we have plenty of scientific packages, that we have plenty of application and so on. So this is one of the things I would like to discuss today, how we can make this happen and so on, so maybe create a website and highlight that more stronger use of Deviant Blends and so on. In this field also we would like to talk about two things, basically make sure that the Deviant Blend list of scientific packages is up to date, because for now it's not the case, so you can find many scientific packages in the archive which are not reference on the on Blend. And the other way around is to use Blend as a list of what we should package next. We have been packaging a lot of software and we would like, I'm sure there are plenty to package, so which one we should have in the archive which are really necessary on a daily basis for scientists. Now we have, I take this one. We have prepared a list from last year's Deviant Science workshop with open topics. I was not, I did not join this workshop because I was not in New York, but I created this wiki page which is listing basically five topics and my suggestion would be we keep on talking these open topics and if you have no better suggestion we start with the first one which is about the BipTec files. There are three options discussed or there were three options discussed. We want to keep the references for certain scientific programs and these references are currently spread over in part in the copyright file, what I think is wrong because it's not copyright information. Then we have some Bip files in Deviant Bip which are strictly BipTec files which has some advantage because you can cite them quite easily and we have the Deviant upstream metadata YAML approach which was started by Charles Plessy and the idea is to collect every data, every metadata of a package in one file, have it in a common format and have the upstream or the reference information inside this format and you could easily draw a script on it to put it into a BipTec file or something else. So this I think this is the first topic we can discuss. What is your opinion of you where should we put those references? It was just to ask I may have missed the point but what's the problem or what we want to do with BipTec files? Okay the problem is you have some scientific software which is written by a scientist and he has published a paper basic on the software and it should be documented to get it quoted and it would even make the author of the software more happy about Deviant because he gets some extra reward. Yeah okay but we should agree on a common format to make it usable. So any opinions? So I guess I don't really have strong opinions about what first of all I think the initiative is a good idea. I think probably nobody really thinks it's a stupid initiative but I don't also. As far as the format it seems like at least for me BipTec is the sort of least common denominator format and if we want to use something else then there have to be some advantages to that so I don't know somebody here has talked with Charles or as followed this and can relate. The advantage of the upstream meta data Yama is in my opinion the first one it is propagated to UDD so we have and every meta information in the universal data database and I am using this data out of UDD to build the task pages and so we can propagate this reference information very very easily to the task pages. So it is a good idea to have it there. It is not so good if you want to do some citations right if you put it into BipTec input and there would be some script needed to just convert it. I don't know either of the formats but you're emphasizing the upstream meta data as it can do something else. It sounds to me like couldn't isn't it a simple question of making a filter for the Bip data or is it a complex format to extract from? I understand that Yama is the original one like similar to Jason but older than that and so but the Bip format which is specific to these references that we need. So it's not a great format but it's certainly parsable. We have several parsers in the archive and it is popular among scientists and scholars of and students of various kinds yes. So it's a natural it's a I would say it has the advantage that it's human-authorable whereas in my opinion Yama is not really human authorable for most humans. It is about extract this topic then I keep on answering this one because we use the text in BipTec format as a field names in Yama so it's one-to-one relation so this is not more complex. I'm actually wondering what exact kind of information you want to put in there for example if there's an R implementation using a specific algorithm having a paper listed there which explains the algorithm or is it some paper actually for example using the software? Currently we use it for a published paper how the algorithm algorithm works but I think there's no restriction if you if there is a publication which is somehow connected to the software it makes sense to put it there. So if I understand it correctly it's usually information which is somewhere in the documentation does not centralised and maybe not in the correct or in one format because if somebody actually publishes a paper I guess it is somewhere in the read me or any other documentation. No it's about some remote documental some remote paper which is not inside not necessarily inside the package it is just published on NCBI or wherever and not it could even be that it's the content of this paper is only accessible for for people who subscribe some something. Are you interested or are you pushing for this bit format being out I used outside of the Debian Science project in some context it would probably make sense to cite things in other packages which are not part of the Debian Science project because they use an interesting algorithm or something and I think nobody else is aware of this at least I didn't hear of it any time. Well nobody is forbidden to use this format in this packaging. You don't have to be a member of Debian Science or you need to know this Debian Science project it's just an effort if there are any references which are relevant then it makes sense to have a common format and anybody can use it. Instead of using just another metadata format why not we use something like RDF to describe different kind of packages. RDF I was mentioning why we don't want to use a metadata format that it's already known and specified out there like RDF to collect information about different resources that we use. Who knows RDF please rise your hand. Who knows RDF format. We just could add this. In this case I would really really vote to use upstream metadata and use a converter to either BipTech or RDF. This format is generic for any metadata of a package not only for references and I think if you have a generic format which works also for references and then we convert it it might be more flexible. Sounds lovely. How is the upstream metadata format governed or who is designing the structures so that it's reliable that it's uniform how to convert from this format to the resource description framework which is aiming at being a universal format to describing the whole world. I'm not really sure if there is a DEP about this upstream metadata YAML but at least there's a wiki page you should check it and we try or Charles tries and I think it's a good idea to to make use this Debian byte so that you have like you have a Debian rules file you have a Debian copyright file you have this Debian upstream metadata YAML file this is the idea to not overload for instance the copyright the control file just clarify I'm not against I'm questioning it because there has been a process for the copyright file it has taken some years and we have figured out what is sensible there based on a lot of it was actually trying to to see it out things that already was written in policy but just trying to make it machine readable that was not a process to what should be in there and how it was very tiny piece of it this to me sounds like the yoga file of the Debian so I'm curious about is there already a process similar to the one for copyright files for that file to handle this to me yoga file and my answer is I'm not really sure if there is a DEP process I'm not sure I know there's yeah yeah but it there's a wiki page you can go to Debian wiki.debian.org upstream metadata YAML and there is description what should be in and what's the intention of it so and there are in in the Debian me team we have 30 or 40 of them for those packages which which basically is the references the the home page the author's name is it's a little bit duplicated but yeah it's basically the content where I I'm using it there are other suggestions on on the wiki page I do not remember by heart okay anybody else did somebody notes on this copy we did I was I will show the copy thing we have this this on Debian copy dot Debian dot net this file where you can include and perhaps make some notes to to make it easier afterwards to remember what we discussed so we have not really consensus but do we want to there's a content there yeah we can agree that Debian slash copyright is not the right place for references I think this this is everybody agrees we can also agree that there will be huge amounts of screaming if we try and add more fields to deviant slash control even though in some sense it belongs references belong there as much as home pages do it is sense home pages are upstream metadata right they should be in some sense in the same place as references but okay so there's two things we can agree you get a lot of friends in the embedded devices a corner which get want to get rid of the home pages and overload of this information but actually we found reference information in the long descriptions of deviant control file and we want to get rid of this because it's not formatted and you cannot get it and it belongs also not there so frankly I don't see any strong case for anything but big tech if it's convertible to big tech in theory it's the same but in practice it's more difficult for users that I presume will overwhelmingly use latex so my idea would would be to have some time of post script file which could be used by dh I just guessing dh science install whatever and if it finds upstream metadata yamal it converts the reference context to user share science pip texts whatever we define and then you to get it and you have it and rdf if it makes sense and it is used by any any program I think this might be sensible okay so all I care about it is that the user finds big tech that's really important so we want to make the user find all references on the commonplace this should be the goal okay so I was always thinking about what we can we make deviant science more visible or even I learned that we have a lot of physicists or a lot of mathematicians shouldn't they try to make their task a little bit more fine grained to make the initial idea of deviant science was we have a large umbrella for all scientists because there's not enough manpower behind those specific topics I would really like to see some kind of leaders of those sub-projects because I think debi shem is working quite good that did not really adopted this this blandish idea and what they accepted that I did it for them and we have debi and gis which do the geographical information systems debi and biology is more or less covered by debi and made and so I would love to see some people who care for for other sciences in a more specific way even if I do not want to to get rid of debi and science but but I think we could grow some children now what do you think about this is there anybody who likes to run a specific plant I'm not so sure that the team is so big and active and that it makes sense to split I mean I don't know if it how that would work from a logistical point of view but my feeling is that the deviant science team maybe hasn't even reached critical mass in terms of for example it's a much different setting but what I'm doing as I sit here and not take notes is working on some package pearl stuff and if I compare the ability to bring new packages in and mentor them and get them to become debian developers which I think is part of what we want to do I think we're not there yet so I I mean I'm not opposed to marketing ideas but I think we should also think about keeping some unity and critical mass in the team yeah it's definitely a question of critical mass and I but my experience was I was starting deviant mid when I was quite alone and I took about three years until I got two or three more but now we have I think because the deviant mid team existed we had about eight to ten more developers than without this so it is yeah I don't think it's dangerous if you if there's somebody who would announce and it doesn't fly we doesn't lose so much so but we we can in principle we can only win if somebody spends a little bit of time it's my opinion I cannot force anybody so but if nobody else rises and said well I want to do it then we could go to the next topic yeah this is also it's probably probably the same like references yeah and this is also one topic which was brought up in the the biology world we have three deviant developers in a very large medical institute in in Great Britain and they don't use deviant mid and I ask them why and they answered well the problem is every single user wants to pin on a very specific versions because he can only with this version reproduce his scientific results I admit I don't really like this attempt because I thought the data are broken or the programs are broken if you can't reduce reproduce it but if the user wants the system as it is what should we do do you have any idea we yeah snapshots but it says there I mean that's only the only sensible thing I can see for people to use grab your packages from there not install everything from there but grab those specific packages from there we can we can we can help our odd users like that but I don't I don't see the sensibility of debian serving the purpose of maintaining broken things of odd versions like that it's not designed to be an historical archive of working with the past of the individual packages okay well I wanted to to say we have apt pinning if they want to keep to a specific version and so he was saying this needs it to be uploaded at least once to dabion well if they use uh dabion science then they won't use a version that that we have skipped so I don't see that as a big problem but we can also try to upload every upstream version it's not not useful uh but yeah teach them apt pinning yeah no what I meant is basically if a user wants a specific version which never been into the archive he cannot switch to this one and I do not agree all the time that it means the software I broke and for example with Fortran compiler doing if you switch from a version to another you can get some different result because of the compiler so it's not only a problem of the final software it's a world chain yeah and on the other hand I mean for people packaging these these these things if anyone is interested in in experiences in in maintaining multiple branches of things but but no don't laugh I mean seriously if if anyone is interested in this and I I have a little bit of experience in in doing with with the sugar the sugar packaging is maintained for too many versions at the moment yeah it's not cleaned up but but I have done that for for a couple of years so it's not that hard if upstream is alive with as maintaining these is treating them as still alive branches I was thinking that they were not I was assuming it was upstream is moving on then no I was not laughing since this was a bad idea it is just it's a huge work when you have when you are maintaining tons of package and if you have to maintain a few different version it is a lot of work but I understand the point and I already know some people who are doing that on the daily basis but it's still a lot of work and it's not rewarding as a as a package or to do that so I'm monopolizing the mic a bit but so two points one just a kind of snarky remark which is that expecting the same results from floating point computations is nonsense but there's nothing we as Debian can do about that misconception but the less snarky remark is it sounds a bit okay so versions that have never been in the archive are one thing but in some sense you need to think about forward ports of old versions to newer desktops of course the same scientist who wants this exact version of the Fortran compiler wants to run ice weasel 5.0 so we can use google plus so sorry so this is I think a new concept within Debian and I'm not sure if it's worth supporting but it's a it's a would be a service to the community I suppose if the demand is there well there are also different kinds of different versions there are small incremental bug fixes that probably we shouldn't bother about actively maintaining and there are major releases so and in that I think I think we should we should we should strive to make major releases are co-installable well for example so I'm thinking of the way I packaged Isabelle I didn't upload it to Debian because of because of stream didn't want me to but that's not an issue and everything was in directories with the major version name in it so the different incompatible major versions would be would be co-installable and then we don't even need snapshot we don't even need really pinning it's just the different packages in the archive when it makes sense please I think one solution to this would be producing static packages by some manner or being able to do that without problems because if you have an installation use it and then upgrade upgrade upgrade usually the old version works on but the problem is if you have a new install once a specific version from like two years ago you have a pain in the arse getting the actual libraries so producing a stable a static version of that version actually wanted would be a solution I guess but not a really nice one we're really opening a can of worms here you do not want the static version if it's linked against lip png which is later on have security fixes on the other hand when you're saying that you want something static is it really at the application or is it the underlying libraries that you wanted to fix it you didn't know but you just realized that it worked with the old environment okay so saying that you want the old environment of this but you want the new environment of another part of your system is just the can of worms so there's there's there's several suggestions for this and I'm pretty sure if we if we follow any of them then we will learn both how few users are really using this because they will they will not trust us because there will be fewer eyeballs on these specialty things and and and on the other hand we also learn if it was the library they really wanted or it was the old version of if it was a forward port or if it was there's there's many ways to go and it's we're getting fewer and fewer users so I don't I think it generally I mean the the maintainers of each specific package might might might might learn or might know better feel better if it if it's relevant I I tried out with sugar which is not a Debian science package but I tried with sugar because it seemed as if there was a large community from a version that was that upstream was deriving from but they still wanted to maintain all of South America was still using the old branch okay and then later on I learned that the next branches was not really used so it turns out that I need may not need to shut them down and still maintain the old worst that's specific to this one package making full think thinking in full infrastructures for Debian for this thing I don't I don't see that as as sensible it's it's becoming too narrow so finally I think even if we would find the way to support this but I'm not sure we we find only very few users and it's probably not worth the effort all this stuff what about we teach people how to use virtual machines I mean with KVM and I mean so many machines are capable of running virtual machines really well now and you should have a virtual machine that you run your experiments on and make a backup of that virtual machine and when you want to run it again pull it out of the cupboard and boot the virtual machine I think that's yeah probably it's a good idea did somebody know that this on the please anybody put put note on the the goby thank you so the idea of last year it was to add more tags to the package that we've got so I'm not very familiar with this part into Debian so I don't know if some people want to explain more how we could do that in the archive in the package we've got and if people are interested or not okay we can skip this one does everybody know depth text depth text depth text okay so I should explain what depth text are so this is here and Rico Zini will speak here he's the inventor of depth text to make some yeah 10 minutes left to make to make it easy to to find packages in Debian for instance you can ask depth text give me all packages which are have a graphical interface and doing image processing for instance a scope yes it's at the scope and I would really love if everybody would go to depth text dot debian dot net and have a look because it makes quite some sense to have all the scientific packages uh text for in principle it is a quite a duplication of work what we have done in the tasks it is it's a competing concept but the concept is so less known because you have to trust the users to invert it the tasks we can do it manually ourselves and that's why they are there and the depth text is is much more flexible but um it it depends a bit on the people to to work together and which which of reason it not happened if not even 50 percent in the room know about this concept um I would really like to to that we discussed on the mailing list later what text makes sense for scientific scientific software and that we enforce people to go there and to do the tacking alternative approach that those few that is interested in this and see this as being super cool on one of them um maybe subvert the this other approach and they make it use the depth text mechanism uh because no it's not needed that you rely on the users you can run your own repository of depth text so we could I would perfectly agree that we could probably create our task files from the depth text database it would probably work and then we could work on this approach but because what about making what about making tags from the task files is is that a sensible concept it might work if if if these the tags and the tasks match and for for um Debian science they don't match because we have not fine-grained tasks in uh Debian mid we have fine-grained enough tasks um I think the I think the the tags will always be more detailed than the tasks so I would go the other way around maybe because tags contain implementation language and uh whether it's a graphical UI or not which I don't see encoding in tags no you you won you won I see depth text is more generic than uh it's more generic there's more uh more uses multi-purpose than than the other so but let's not get into details of that now I think in principle I agree with Jonas about this but I think if we we should proceed now and we we have only five minutes left if there's any topic left yeah so we we had a discussion on Debian science a few weeks ago so the idea was at first that we have two main English we have Debian science and Debian maintainer and the first idea was to use Debian science for users and Debian science maintainer for packages so about 20 people say yeah it should be a good idea and at some point Hadam Poel came with uh with the arguments that uh people who are users usually go on the mailing list of the software they are using and not on Debian so uh at some point they say okay he's right so maybe we should say okay the way we are using it now is fine or maybe we should say okay Debian science should be for users and not for packaging question I think because of the packaging question users are leaving the mailing list so we have more geeks on the mailing list than users and maybe we want to get more feedback from the real users of the software so it's a tricky question for me user-oriented question so it's not very interesting for us I don't have any data because you have to check on the mailing on the mailing list we subscribe and you don't know exactly who it is and you don't know if they are at a level of uh or are they are skilled in computer science and no it was just a test so maybe at some point we can make user of Debian science talk about software and using the software not about packaging them it's not that I don't care about the users it's that it's it's so tricky to figure out what is the best way to serve the users by being at one point so there's no ambiguity about where are the cool people the people really knowing stuff or is it better to split it up so you don't scare them off by being too cool and asking about way advanced stuff that you don't are not interested in and the only real way to figure it out as I see it is to look into the future of what happened if we did this what happened if you do that I don't have the the ability to jump between these multiple realities something I finally think we cannot force you though to discuss this topic there and this stuff over there so it was just to kind try to create a community into Debian and not outside because you can keep it okay to make concrete suggestion of mine I believe in staying at the same place to to keep a critical because of the issue of critical mass again but I don't know specifically for Debian science if you ever already have the two critical mass if you are scaring people off that if that's the issue here as a if I was not a packageer I think I would be scared of asking question on the mailing list where I see very technical question happening all the time and it's why I think most of the normal user are not using the mailing list to ask some question like I want to do this kind of computation which library I should I use because on the mailing list most of the question are very technical but but I'm just thinking that wouldn't you still have the technical questions on the mailing list would you then tell people to not be too smart in their way of asking questions because you want to invite I'm afraid to mix the two things the user question and the packaging question and plus the idea why I wanted to split them for what it can work on IRC there has been quite some consensus on the fact that splitting mailing list for users and for packages is better than not and they're suggesting that in package multimedia they've done so and apparently they had good results okay just to thank you for the feedback who was doing the feedback oh don't know it's too abrupt cut and somebody is thanks to art greetings to the people outside yeah so here is some URL so if you want to have a look into the policy and what we are trying to do to figure out and so on so you will find everything and Rico can you imagine half of the people don't know that tax in this room I think we have finished anyways although we can give a five-minute short introduction to DevTex now if you like here's a mic so hi what are we talking about debut science round table okay hi DevTex these categories for packages and because normally with I mean without DevTex you only have sections which in your case you have one section science and that's not much and tasks but they're not quite they're not package information as such they're more like to install groups packages whereas DevTex allowed to have more than one name the package and they are old and we have like more than 600 different categories available and they're grouped by what we call facets a facet is a point of view from which you look at the archive so we have one facet which is what's the role of the software in the archive and so it can be a program a library documentation a plugin and so on and we have another one that's what's the interface of the package and so x11 command line and so on and then we can it gets even more specific so there's a package for the field of science or research or well field of knowledge and so it could be medicine physics or literature history and so on and then we even experimented making field specific facets like we have an experimental facet called biology which has tags that I do not remember because I'm not a biologist and so that specific groups of users can have can find words belonging to their field in the classification I think that's about the is it simple or can it be made simple okay for user for people who are working in certain areas to add more specific classification for that area for example for software in maths okay you say some were added but maybe users can have the need to add some more some more specific is could this make possible yes in order to add a new tag you join the dev in the well the dev tags the well mailing list which is not much about developments but everything that takes but you can change the name of a list after it made it and propose new time it's as simple as that if it fits in a new facet sorry if it fits in an existing facet the only requirement is that there are at least certain packages in the archive that would have it there's no point in having one tag for two packages it's not representative of that being of anything in that being if you want a new facet there may be a bit more discussion like we'll see if it makes sense if it overlaps with existing facets but ideas are absolutely welcome a facet should be sort of uniform um it should it is a point of view from which you look at the archive it's something that should conceptually make sense as an idea and it's not like you can't take the existing sections in devian and make a facet section it wouldn't have much sense it would kind of overlap with other things there's not much point in doing that but if it's something uniform we try to think in the field of uh research to have one about research work so something for doing research for publishing research for bibliography um so kind of the work to have a facet to represent the workflow of academic work um yeah we had ideas like that and why not okay thank you very much