 Eu segui a página da Wikipédia, então, ontem, eu e a Cristian updated a página da Wikipédia com os nossos resultados para o próximo release e depois vamos seguir isso, procurando as coisas que você já fez e as coisas que você precisa fazer não todas elas precisam ser feitas por o release então não parece tão ruim e depois que fazemos isso, podemos voltar porque são os pontos que você está perdendo Então, as coisas que já fizemos para os interpreteiros, você está capaz de retirar todo um pedaço de ouro do arquivo Então agora temos apenas o Ruby 2.1, que é a última upstream Eu acho que são muito bons para o Jesse Eu acho que o package do interpreteiro é muito melhor Eu não acho que há mais um pedaço de ouro específico A upstream também está muito salvo hoje, então isso é bom Nós também fizemos certeza de que as upgrades do WISI não rompam porque no WISI nós ainda nos permitimos mudar o interpreteiro usando um pedaço de ouro, e isso parece ser muito perigoso e muito perigoso Então nós removemos a opção de fazer isso e também Há algumas opções de técnico alternativo no package do Ruby, para fazer sure que o usuário do Ruby é sempre o que queremos ser e então as upgrades funcionam então nós decidimos como fazer sure que mesmo se você não tem o package do Ruby e você tem algo que o usuário do Ruby quando você upgrade, você tem as regras, os packages em lugar e tudo isso funciona Então isso é pronto No package do Ruby, nós... O interpreteiro, em algum momento, foi uma discussão, eu acho, com o Marga sobre não forçar o removimento das opções do Ruby 1.8 Sim, isso é pronto Então, se você tem o Ruby 1.8, isso não vai ser removido e você vai ficar removido Então isso vai ficar aí, não vai funcionar com qualquer coisa que se for provada, mas isso vai ficar aí Eu esperava que isso iria se retirar Não, ele foi retirado da archívina já Se você está... Mas você não foi removido Sim, sim, isso vai ficar aí se você tiver Se você tiver exclusivamente instalado e não ter a alternativa dependência do Ruby metapackage Então, você só vai ficar aí Então, no package dentro, nós só removimos Foi muito bom o trabalho do Cedric A integração de testes de auto package Então todos nossos packages agora Freshly created packages Have auto package test integration by default And for new packages, very easy Just running DH make Ruby On the existing package You need to add the missing files And maybe we'll be able to Run the auto package test for every package Even without a new source uploads So, I'm going to figure out how to do that With the auto package test maintainers So, even though we want to do source uploads anyway To make sure everything is in place We would be able to benefit from automated tests All the time, more 500 packages for free So, I'm probably going to do that And on the coordination side We both tasks done by Cedric So, thank you very much Cedric for listening So, we are having more or less monthly meetings On IRC for having progress And looking over painting stuff and discussing And that's being very helpful We also had a team sprinting January in Paris Very nice as well It was co-located with the Paris MiniDebcon Very nice And we probably want to do that again Because it's so useful That's where we figure out how the upgrade stuff was going to work So, that's a lot of stuff And now the stuff we still need to do On the interpreter side I had an idea to make RubyGent integration Make RubyGent install to the home directory by the foe If the user doesn't have permission to write To slash vise, slash lib, slash gems, whatever So, that's... We will go back to these items I just mentioned them very quick We need to figure out What to do for multi-arch So, the dependency change that makes All an arcany packages We have to have the right flags there To make sure it works with multi-arch We need to check upstream support for Ruby 2.1 And make sure we are good for the lifetime of Jesse I would like to have feedback on an experiment I posted on email a few days ago Called Ruby standalone Which is a way of installing the Ruby interpreter from Debian And being able to use that without any of the Debian packages So, if your upstream Has versions that are... If your upstream project You want to sell a web application like GitLab Discourse You cannot satisfy the dependency with Debian You can just use that thing to Use the interpreter from Debian But the package from RubyGent We need to decide whether we want to backport Ruby 2.1 too easy Or if in general we want to keep Backports of the latest interpreter for the latest table And how to do that without breaking everything And if it's useful if people want to have Backport of the latest Head commit for upstream interpreter There also to do items on the Alternative interpreters I didn't see much movement on this front To be honest, so I don't know if something's gonna happen there My impression is that Rubinho seems to be compatible with most things But he just didn't caught up Maybe because MRI is doing much better In... With the non-Japanese developers So people are getting inside the core team More easily And it seems to be working Even people who work on Rubinho are there So... And then there's something like Rubinho's 2.0 That's like changing everything Like being handled like an experiment So... I was working on Rubinho's packaging To be honest, I'm not very interested anymore And for JRubi, I have no idea About finishing a transition to a new Ruby policy We have to Finish the last few packages I think it's very few, right? Mostly non-team packages Have the transition I think it's mostly because we don't have Real... Ok So... And that brings us to the next point Which is updating the Ruby policy package I mean, in the context of the Auto package test Development That specification is going to move to the devian policy And also, I think we should probably do the same All this Like, the pill policy is already there So we should probably do that as well And on the packaging side A couple of... Yeah, we have to like the fake Auto package test integration To make sure we can have auto package test support Even before uploading the 500 soft packages We maintain There's a lot of bugs to fix on gentleness And most of them are good We want to start contributing Most of the service is not hard To do items The git repository is probably very outdated And also a solution for Automatically build and ship developer docs I think Per was working on that I'm not sure on the status On the coordination Organizing a periodic sprint So, Cedric had a last night a note here If you want to do the next one Close to the dev confUK Or the mini dev confUK Or Foslin And code review I'm not sure what this means I have been in some discussions That come here That they want to use for code review And I see that On actual access We regularly do some sort of code review Because we have many people in team That kind of code review And the customers Would need to get it to help us do that I personally don't do any code reviews On actual access But people have been good In the dev network He doesn't work so well for the dev packaging Because it's quite difficult Because it's always a bunch I'm not sure it's the best tool But maybe we can use it Just document it exactly Or we need to use it It's quite interesting Yeah There are a bunch of outreach actions here Like doing PR Basically Creating a task cell test for Ruby development We still didn't have anyone doing that And a bunch of things about documentation Basically we circuit maintaining documentation So we have Ok, so yeah We went over the list Now we can Do we discuss the easy things first? Or the hard things first? There was a little bit of feedback from IRC Both to you I don't know what to say That Ruby use Not master package Because it was split into many gems Right There was that Then somebody also asked To speak closer to a microphone And he replied in IRC And he said that Before the jessi freeze Would be cool Before the jessi freeze That's a little bit difficult The meeting that comes up is in October November So that's right on top of the freeze So yeah, about the Maybe we can discuss that first Sorry It is We just don't have speakers But it's on for the stream So I'm wondering if it sends the right message To organize a sprint in November In the freeze In November I'm not sure the status Of the Ruby team But we are It's fine I don't think we are too bad Even the size The launching We are actually missing So for our seed bags Mostly the launching we are missing Is like grades And it's not on the list Can you comment on the status first? Yes So Reios 4 is on a state point testing We are just missing one package In the new queue To make sure the smoke test For Reios pass Back to back And it's not even a Very important package Like a documentation But it's required By the default gen file I should probably talk to Paul Here to see if he wants to do more New processing During the outcome But then If you need a specific package You can just go to women Explain why it's important Okay When that's in Then Reios 4 is The full stack is completely fine Another good news Last night I was able to make Red Mine work with Reios 4 So we need I think 3 or 4 packages In the new queue And new upstream versions Of other 3 or 4 packages But Red Mine is working So Yeah, then we I think Red Mine is the main dependency Reios dependency we have Revest dependency So we should be fine By the time of the freeze Yeah, so then for the sprint But then also Yeah, I think I think we have to look at The maintenance dashboard See the volume Of RC bugs And if there's lots of them Maybe it's useful to have a sprint Even if it's close to the sprint To the freeze I was wondering if we I was wondering if we I was wondering if we Couldn't just Do some kind of What to make it With the GEMs prepared Websites I think there's one for half packages That comes from aircraft To data packages And maybe that's something that Would work quite well To generate Data files with all GEMs Of course some of them will be broken We require manual tuning That would be a nice way To Enforce To push them To generate The data alternatives To the GEMs Yeah, there was something doing that In the past I think Gunnar Did a blog post on something related to that I think it was some company That had a service for that But I think they disappeared Yeah, me and your ride They were trying to do the whole Well, it was not yet The GEMs But the previous iteration Yeah, maybe six years ago Yeah Yeah, I think we Yeah, that's something that seems to be doable If that works, does that work? I can't hear anything Cool Yeah I'm going to sell the members Ok Yes Sorry, no, thinking about this idea By Lucas, if we start doing Automated GEM to them website It may even be set in a A DEB Like in a repository way As an after repository Yeah, yeah I mean, maybe on demand Do you request one GEM and it gets other Well, that's it I think the Ruby GEMs are pretty big We don't want to do everything Most of crap there And also, you know, different versions Yeah, we don't want to convert All of the Ruby GEMs And also, you know Different applications are going to have You know, many different Version requirements for Ruby GEMs We would also have to Maybe do all the versions So that gets even worse And also, I don't know How frequently we should like Look at everything And maybe throw some packages Out of the archive Because that upstream Or superseded or not recommended Because I think we have a bunch Of leaf libraries That actually we could just ditch Probably is too After free, also I don't know Yeah, I think that's a general problem Does anybody know how other teams do that? I mean, spotting Dead-up teams Just someone doing their work All the time I don't think there's a Non-manual way to do that Yeah, well, there are several metrics We could take to help us Decide on that For example, looking at Crossing that with last upload times I mean, that can start pointing to Well, something maybe Not surely So, should we go to the list now? Okay So, James Tao to home directory If the user is not root So, the only We in Christian discussions And the only problem that seems to happen It's not really a problem But it's an issue Makes us different from other OSes So, Fedora does that by default Since some time already So, if you are not root And you do James Tao It will install to your home directory by default But Can you explain what happens with Bandler? So, the main concern Is basically Bandler Which On other OSes Except like Fedora, probably Notices that you're not root And if you cannot write Into the system jam directory It will spawn sudo for you And it will see if that works And if it doesn't Then it will give you a nice error message That says you need to install Into a non-system location And you need to do that I think Most of the Like Rails, tutorials And whatever on the internet That you can just run Bandl install something And then you will end up with The jams in the system location And the jams stop files In use local bin So everything will be in your path afterwards And I think that would break I've always used Bandler with the I think it's like vendor Flag The one that puts every Dependency in a single repository E then we make that the default And problem solved I mean the idea that these things Call sudo is a bit I hate it Yeah that's actually a fair point I agree that it's You know It's in an ideal world It shouldn't run sudo But You know it's the vain now Didn't they add this sudo thing Exactly because of us No, I think they If everyone else uses their RVM They install to the home directory anyway And we are Probably the ones pushing for Installing to the system location By default I know At least OS X It will default to the system location If you do not use RVM Ok I don't know how many people Use Bandler without using RVM So if you have feedback on that I mean this Also Placing to the question Should we have root standard launch Should we have Ruby backboards Because if nobody is ever using The system interpreter for Doing development work Then We can just stop caring For these things What are you using So my development platform is DBM And I'm producing software That I want to get packaged in DBM Because I don't want to Have to juggle with You know, updating versions all the time So If I can, I'm actually trying to To target stable And if I can't, I'll target packages That I think I can backport That's a very specific position Of someone doing a bit of upstream Ruby development But it's also mainly a DBM developer But I believe It is also A way to not Have so many headaches Yeah, that's what I do too I don't think it's useful to Backport the interpreter But Using So I really don't like AVM Also Because But The bundle With the vendor directory It's like a mini AVM And It's like building a shitload Of stuff In your home So there was a reasonable compromise To me I don't know When you do that Which bundle Does it If there are Packages already installed System-wide Does it duplicate those packages In your Okay So It's for Developed machines We sometimes use Ruby If it's It's possible We take it from the operating system From DBM Or from Sentos But there are plenty applications Still not being fully supported By Ruby 2.1 For instance That's why Very often we compile from scratch Ruby Because it's not really difficult And then we use bundler And we never use Gems From Operating system From DBM We We always Do it on the fly And Even in production For every release We do Bundle install So when we switch Between releases It's really safe Because If I change Ruby version And I release New version of application I want to have The full set Of gems In the application In the new release Of my application Directory And it means that If something breaks I can Really quickly switch back To the Alt release I understand you That you're not using Our bundle So in In our case We have a DBM only infrastructure And we're using Actually The DBM package Right now And Plus a couple of patches For the Garbage collector Which Will be unnecessary In 2.1 As far as I understand So we We're really trying To push the developers Towards using As many System packages As possible As many distribution packages As possible But that's not always The case The use bundler They have locks On specific Gem versions Which is something like Inherently Almost inherently Incompatible With the way We do versioning Right So I think that It's very Very difficult to Provide Like packages That can satisfy everyone And get rid of bundler As far as The Backward is concerned I think it would ease Transition to Jesse So that we could Eventually Start switching To Ruby 2.1 Before upgrading The whole system To Jesse And see that the application works But I don't know If that would be Reason enough For the overhead Of back porting Things I mean For us it would be perfect Because we could Get rid of the Custom patches We have right now In place of the garbage Collector Because they're not needed To one anymore But I'm not sure How many people Would actually Use a Ruby interpreter From back ports right now I mean I could Try the back port I haven't seen What Actually is required For the back port I suppose we have to Make it work with update Alternatives And so on To be compatible With Weasy versions right now I could invest Some forth there Okay Yeah, our idea was to Not Integrative Ruby alternatives And just create The binaries The 2.1 Perfect suffix And then If you want to use That by default You can just create Ruby Because On Weasy Most of the binaries Most of the binaries Is to use User being a Ruby As Shebangline So It's going to use Whatever Ruby you have On your path And since None of the Ruby libraries On Weasy Will support Ruby 2.1 Then everything Will explode For just You are In a better position Because most binaries Already use User being Ruby So they They should use So the The idea of the Backport If we do that To Not provide In the path By default In the path So Maybe we can Provide some directory With the Same links already made That you can add To your path Or call directly If you want But we are not planning To integrate with How easy The alternative Ruby Because Everything Yeah So you said You always use Ruby from source Depends We use A little from scratch For bitnaming Ruby It's just built Everything is built From scratch We don't depend On the operating system It's mostly because We want to be independent Of We are running Different applications Ruby applications And some of them They still use Ruby 1.8 Some of them 1.9 Etc So it's just safer For us For now For instance What I would expect From the From the For Lightning distribution Is just to have Ruby interpreter Like really Well done And different versions So I can switch And I don't care That much about Ruby gems Gems in general Because I can always Use them With bundler rights And I don't know if Other guys use But you do care To have the interpreter From the OS I mean If possible If possible I could use it Yeah Yeah And in development I try to I try to I try to do it Because it's not One part is web development Other part is I mean we Ruby developers We also built Some tools In Ruby So I want to have Ruby In the system From the system Yeah So the idea of Ruby Stand alone Is to be able To install Ruby From the OS And then Even if you have Stuff like Vagrant Or Red Mine Or Anything else That's a Ruby application Packaged by Debian You can still use Your application And your application Won't see Any of the dependencies Of those guys Like Chef brings A lot A whole lot of dependencies And then If you use Ruby Stand alone It will use the Interpreter on the system But that interpreter Will not see All the other Libraries installed So then you have A clean environment For applications And that's That's something I would use Myself If I have For instance to Contribute to some upstream Project that has Completely crazy versions I could use that Because I don't want To be building Ruby from source Every time And then just Have a clean environment There and then use Install whatever Your upstream needs For me to Write a patch Okay Just a final note When we started this Anyway Where I work We're basically running A big Rails application That's our main business So when we Started some years ago We were using Ruby Enterprise Which means Completely out of Tree stuff The fact that we're now Only have a single patch On top of the Debian package Which will also Probably go away With 2.1 I think it's a very Big success For Debian right now And I mean For us I would like to be Able to use only System packages It's Clear for us For the security support And because there's no reason To do duplicate work Actually Work actually I would much prefer To invest my time in Debian Rather than package And maintain things Just for our own use Yeah, that's what We try to do most of the time So we We already have Readymind So everything that Readymind depends on Is there There's people Working on Diaspora So I think Diaspora is quite close To finishing So they have 80% Or 90% Of the Debian package Which is quite a lot Because It was Absurd number of packages And we have Also people working on GitLab I think GitLab should be At 60% Or something So everything That's in the dependency chain Of those applications Is already available Plus The stuff that Chef needs The vagrant needs The puppet needs And all that Kind of stuff So I think we are Que isso vai ser muito legal Eu acho que 5 minutos Há 5 minutos 5 minutos? Wow Ok Naquele momento Chef Se alguém quer usar Chef Ele precisará ajudar As packages Eu acho que são muito Outros E não são só Se você quer usar Chef Eu tentarei Contar o container De novo E de novo 3 anos E de novo Eu acho que Eu acho que precisamos Não, não Eu era o Chef Espera aí Eu era o Chef E foi fácil E funcionava bem Então precisamos fixar isso Ok Se alguém tem Comentos De outros itens Na nossa lista Se alguém quer trabalhar Comentos Especialmente na política Documentação Cham the Dab Eu acho que Cham the Dab Principalmente Em pontos específicos Que as pessoas Justamente tem que olhar O BTS E escolher O Bugs Para trabalhar Eu acho que Nós não temos que decidir Agora no spring Mas nós podemos discutir O que é mais Comentos Eu acho que Muitas outras pessoas Estão procurando isso Por outros itens O plano para o aspecto É para E depois O J.C. Para o 3.0 Sim Isso vai dar Muita pena Sim Mas O aspecto E a dependência de desenvolvimento Talvez Podemos ter as duas versões E Não é ideia Mas É menos pena Se nós temos Um testa de bagagem Ou um testa de bagagem O que é mais? Sim Se você quiser Podemos tentar Rebuildar A mass-rebuildada Com um Podemos tentar Rebuildar a mass-rebuildada De todos os Packages dependendo do aspecto Depois de se upgradear E ver como também O que é mais Porque nós não temos Uma boa estimação agora, certo? Sim Não Não O Lucas me disse Que ainda tinha dinheiro No Amazon Que foi usado para fazer a mass-rebuildada Sim Ok Sim, eu acho que Nós podemos aflorar o aspecto Para experimentar e Rebuildar tudo Eu acho que Nós... Tem algum feedback do IRC? Sim, tem algum feedback do IRC Para o aspecto Katelyn Diz Que... Sim, sim Então Ela fez Um monte de trabalho para Rebuildar o aspecto 3 E Cedric diz Que Ele espera que a mass-rebuildada Basicamente Diz que 50% dos Packages vão falhar Sim E Jonas, antes, disse Que Ele perdeu um Package em GitLab Então, eu acho Se você quer ver GitLab E também precisa ajudar Sim Ok Nós temos 1 minuto para ir Então, vamos abrir a sessão Eu acho que nós tivemos Muito bom feedback Eu não acho que As notas se refletem Mas nós sempre podemos ver E gravar as notas Sim, isso é tudo Então, obrigado a todos E... Vamos Ok, obrigado