20:00:18 #startmeeting 20:00:18 Meeting started Tue Oct 20 20:00:18 2015 UTC. The chair is boutil. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:34 #chair boutil 20:00:41 :) 20:00:53 Hi everybody, please say hi! 20:00:58 hi! 20:00:59 hi o/ 20:01:00 hi! 20:01:00 hello o/ 20:01:22 Hi 20:01:43 good to see you all! 20:02:14 tnnn, avtobiff: ping 20:02:34 can we have a quick recap of possible topics for today's meeting? 20:02:44 I can try 20:02:57 You'll see I am not very well prepare for that... 20:03:00 - push some people to apply for DM/DD 20:03:01 hi there 20:03:38 - response time for newcomers on the ML 20:04:09 I would like to add: 20:04:14 - next team sprint 20:04:18 2. Policy for answering times on the mailing list 20:04:35 we missed 1. I guess 20:04:37 3. ruby-launchy 20:04:49 1. encourage debiain-ruby members to enter the NM process 20:04:58 sorry, got disconnected 20:05:21 sounds a good list! 20:05:32 if you are following tpot's list, then: 20:05:35 4. next team sprint 20:05:40 let's start with the first item 20:05:54 #topic encourage debiain-ruby members to enter the NM process 20:05:57 I like the first item 20:06:06 ch2500, 20:06:34 #idea we would like to get more people involved in the team go through NM 20:06:37 hi, sorry i am late 20:06:45 avtobiff: np 20:06:46 hi avtobiff 20:06:47 * mose wants to be encouraged 20:07:13 mose: it would be useful to be able to know who are you by inspecting your irc handle :) 20:07:23 :-) 20:07:26 http://mose.com is me 20:07:30 I was just about to suggest we do a self intro.. :) 20:07:40 ruby coder, sysadmin at gandi.net, have to elarn how to package for work 20:07:58 Sorry to interrup, is Per Andersson here? 20:08:03 but I'm usually a rubygems/rvm user 20:08:06 bsc, that is me 20:08:27 got 11 gems on rubygems, minor ones 20:08:27 avtobiff, ah.. ok.. just wanted to meet ya. :) 20:08:48 boutil, should we do a short presentation round? :) 20:09:12 mose: you want to start contributing first; becoming DM/DD is for people who are already involved 20:09:35 makes sense 20:09:36 mose: but you are very welcome. are you in the mailing list? 20:09:39 yes 20:09:48 avtobiff: I would have thought that almost everybody new each other already 20:10:02 but apparently not 20:10:08 "new" 20:10:22 yeah I'm just the new one that nobody knew :) 20:10:29 :) 20:10:37 i am unsure who i know 20:10:44 * tpot is working at HP and interested in packging great apps for Debian 20:10:48 I am unsure who I _am_ 20:11:07 I'm working on pkg-ruby, pkg-go and pkg-java teams 20:11:10 terceiro, i suppose the saying is: you are what you do 20:11:15 and also DM since the start of the year 20:11:25 Who is at the moment Debian Maintainer, and feels it's time to be pushed throught NM 20:11:30 ? 20:11:51 tpot is a candidate 20:11:58 yes, thanks 20:12:05 bsc should probably be DM already 20:12:10 bsc: are you? 20:12:11 i think hleb valoshka should upload their own packages 20:12:12 me, but I have not contributed so much since debconf… 20:12:18 yeah is there anyone else who could become DM first? 20:12:21 I am a DM, and I started thinking about NM few weeks back. 20:12:29 bsc: since when? 20:12:38 terceiro, it's been 6 months 20:12:41 ah 20:12:43 good 20:13:12 is there anyone here that have done packaging work that i sponsored/uploaded? :) 20:13:13 (there's a soft recommendation to be DM for 6 months before NM) 20:13:34 #info tpot, bsc are DM for sufficiently long time to think about NM 20:13:35 i have never been a DM, and it existed before i entered NM 20:14:05 I'm dm since more than 1 year :) 20:14:10 i had some sponsored packages, but not much really. more coding work in debian-installer. 20:14:25 sbadia, so it is really time that you help with the team uploads! 20:14:30 #info sbadia too 20:14:56 * terceiro remembers pushing sbadia to enter NM during the last sprint 20:15:05 indeed :-/ 20:15:12 and during debconf too 20:15:17 lol 20:15:22 I don't know what is the status of Hleb at the moment, but he should indeed upload his packages on his own 20:16:28 it seems hleb is not here; who wants to take an action to send an email? 20:16:40 Nobody seems to complain about being pushed to enter NM. Good. 20:16:47 I can write him 20:16:57 #action boutil write hleb about NM 20:17:11 cool thanks 20:17:28 i've already said here that i want to see at least hleb and sbadia being pushed in :) 20:17:37 thanks :) 20:18:26 so let's go then 20:18:35 #action sbadia enter in the NM process 20:18:46 oh, a side note. is there anyone on the team that is an Application Manager (guiding NM candidates through the NM process)??? if not, at least half or a third of that amount we push into NM should be accounted for, asking to become AM:s 20:19:58 i can help out with that - becoming an AM 20:20:07 #idea at least some DD:s on the team should ask to become AM:s 20:20:10 am i doin it rite? 20:20:11 presumably after becoming a DD first 20:20:16 tpot, yes :) 20:20:21 I can try to think about it... Unfortunately, I don't have much time atm... 20:20:42 the "becoming an AM" does not mention being DD as a prerequisite! 20:20:49 yeah, i think you should be asked after you have been a DD for six months. (i have never been asked AFAIK, though.) 20:21:08 i can become an AM. 20:21:31 good! 20:21:46 I may join you then :) 20:21:50 (maybe0 20:22:06 * bsc is waiting to meet one more DD, to satisfy the count of key signatures.. :D 20:22:16 boutil, don't say yes if you can't back it up! 20:22:42 ok! 20:22:43 unfortunately at the moment I can't possibly take any more stuff or I'll become crazy 20:22:51 i support you saying no boutil. if that is your wish. :) 20:23:19 yes, don't go crazy. 20:23:44 (i myself need to learn to say no also. but i can handle the occasional mail with someone in NM just fine.) 20:24:01 I think we have now a good view of the situation 20:24:22 I look forward to welcoming the four new DDs in the team soon! 20:24:27 yay 20:24:30 moving on? 20:24:53 tpot, well, you need to send a signed mail to Front Desk asking to become an AM. and you need a Debian LDAP password etc. in short, you need to be a DD of course. :) 20:25:06 is it possible to get a recap of decisions or whatnot? 20:25:06 #topic Policy for answering times on the mailing list 20:25:32 like OCTOSHARPsummarize-topic-plz 20:26:13 oh, https://wiki.debian.org/MeetBot 20:26:18 avtobiff: yeah the bot will create meeting notes 20:26:33 provided we mark the important stuff with the #commands 20:26:40 #info is there anyone on the team that is an Application Manager (guiding NM candidates through the NM process)??? if not, at least half or a third of that amount we push into NM should be accounted for, asking to become AM:s 20:27:09 #action avtobiff will become an AM 20:27:13 liko so? 20:27:14 like* 20:27:26 yep seems good 20:27:31 avtobiff: you proposed a policy to deal with mails of newcomers, right? 20:27:32 yes 20:27:36 but it goes into the wrong topic then? 20:27:41 yes 20:27:47 oh well. 20:27:56 next time you get it right :) 20:28:25 on the topic at hand 20:28:32 anyway. on topic. Andreas Tille gave a presentation about the DebianMed team and how they have a living community around DebianMed 20:28:50 during a Debian Blends BoF or some such at DebConf13 or so IIRC 20:29:02 avtobiff, you have a link? 20:29:09 not documented, sorry 20:29:18 ah ok :/ 20:29:51 but they have the policy (don't know if it's official) that they should respond to newcomers questions, requests, etc, within a day (24 hours I suppose) 20:30:31 I think tha makes a lot of sense 20:30:38 indeed 20:30:41 so people don't feel lost/alone 20:30:52 even if the answer is only "Hi and Welcome! I have read your question regarding X but I don't have time to give a detailed answer right now. Please stay tuned and I, or someone else, will whip something else within a week's time." 20:30:55 yes 20:31:04 i myself feel a little lost in the mailing list sometimes 20:31:31 Shall we try to apply this rule, then? 20:31:48 and it doesn't feel that nice and heart warming to be able to wake up threads from the beginning of the summer... 20:31:53 * bsc thinks there is some RFS from last month still unanswered.. not sure though :D 20:32:07 i think so yes! 20:32:26 boutil, i obviously think so. :) 20:32:31 is there some software we can use to help out with this? 20:32:50 sound a good idea indeed, in my associations we have something like rotating secretaryship (every month) 20:32:51 RFSs especially for new packages can take quite some time to deal with 20:32:56 something lightweight obviously but it would be nice to avoid things falling through the cracks 20:33:20 tpot, since this is a social issue i think we shouldn't solve it with some technology but instead work as a team/community 20:33:24 I would recommend that people send an email by package to sponsor, so that it is easier to deal with (visibility) 20:33:46 someone take the month, and with this it's not always the same people who respond 20:33:49 boutil, didn't get you.. sry 20:34:15 avtobiff: ok - i need to stop trying to solve social problems with technical solutions (-: 20:34:25 #info the team adopts a policy to answer questions of newcomers within 24hours 20:34:50 we can track what is pending with a mail client. what I do is not marking unreplied RFS mails (for example) as read 20:35:06 i don't have any real good suggestion on we should accomplish this. i suppose we just need to check the list daily (or every other day)? 20:35:10 #idea people asking for sponsorship should send an email per package (with a clear list of yet missing dependencies if any) 20:35:22 just pointing out the obvious: we all can try responding faster, but reality will still catch us... 20:35:42 right :) 20:35:45 well 20:35:47 ch2500: I guess the main point is for newcomers, who don't know how things work yet 20:35:48 boutil, aren't people still doing that? Or are you talking about multiple packages in single RFS ? 20:36:04 my idea is that we should respond basically anything as quick as possible 20:36:14 ch2500, ^ 20:36:36 its all best-effort anyway 20:36:39 bsc: sometimes, there is a mail asking for sponsoring 5 packages, but only 3 of them can be uploaded, one has to be corrected, and the other has to wait for dependencies to enter the archive 20:36:51 we can't promise a SLA 20:36:54 it is a bit difficult to follow that in the same thread 20:36:57 boutil, ah.. I guessed.. Yeah, that is difficult to deal with.. 20:36:59 and not wait until we have built the package in a clean chroot, checked all the errors, warnings, copyright issues etc. 20:37:04 I think that a thread per package is easier 20:37:17 just answer and say: hi and welcome! 20:37:30 who can update the procedures wiki page with that? 20:37:46 i personally don't see any issue with how RFS:s are done at the moment. 20:38:09 I think 1 thread per package is indeed easier to follow 20:38:27 but we don't have to bikeshed on that 20:38:30 aren't you just free to break out into another thread if it becomes a great discussion? (Like: RFS somepackage WAS all the old stuff) 20:38:48 for example, I am not sure I uploaded all pacakges prepare d by tpot a year ago. 20:39:03 yeah, i don't mind. i probably find 1 thread per package easier as well but i see no issue at all with it as it is now. 20:39:07 some my have gotten lost in the many messages 20:39:19 yes, sure, it is just personal preference. 20:39:24 boutil: no worries - have been mired in java-land for a while (-: 20:39:39 but i can see how it perhaps could make it harder for newbs, all these rules and whatnot and then someone says "hey! you should have on package per RFS PLEASE (not really please!!!)" 20:39:46 a volunteer to update the wiki then? tpo? 20:39:49 a volunteer to update the wiki then? tpot? 20:40:29 * terceiro noticed the wiki explicitly says to request more than one package per email 20:40:41 avtobiff, newbies usually deal with one package at a time.. :) 20:40:56 bsc, haha, maybe you're correct. :) 20:41:10 boutil: sure - sign me up 20:41:19 I, untile recently, followed the concept of sending RFS only after previous RFS was answered.. :) 20:41:22 *until 20:41:40 terceiro, most of the time the correspondence goes "RFC: pkg 1 2 3", response "> 1 2 3\nUploaded, thanks!" 20:41:43 very htoughful of you :) 20:41:56 bsc: ^ 20:41:59 #action tpot update the wiki about policy for emails and maybe RFS" 20:42:16 avtobiff: yes, this should work too. 20:42:32 Next topic is ruby-launchy, right? 20:42:36 where exactly should we document our response time effort? 20:42:39 #info s/policy/recommendations/ ^ 20:42:40 it is not exactly clear to me 20:42:57 avtobiff: probably in the wiki as well? 20:43:14 "we will try to reply in less than 24h, but if we can't, don't get upset and wait a little longer" 20:43:22 we don't have any other "official" document. 20:43:33 #info document the 24 hour answer time effort under Get in touch on the team landing page? 20:43:35 haha, in the ruby-policy? 20:43:38 * sbadia run :D 20:43:45 #info https://wiki.debian.org/Teams/Ruby/Packaging 20:43:46 :D 20:44:03 #link https://wiki.debian.org/Teams/Ruby/Packaging 20:44:19 I thought the ruby-policy is a urban legend 20:44:20 i think that is too buried 20:44:25 terceiro, ^^ 20:44:41 terceiro, shouldn't it just be converted into an asciidoc and submitted to somewhere? but we digress... 20:44:54 avtobiff: which "it" 20:44:59 I think the wiki is fine 20:45:03 the wiki page or the ruby-policy 20:45:06 terceiro, ruby-policy :) 20:45:23 let's agree on having the wiki as the actual policy 20:45:27 avtobiff: debian-policy should be the final destination 20:45:32 i think it is to hidden under Teams/Ruby/Packaging 20:45:37 no wait 20:45:48 it above being answer times 20:45:54 the wiki page is a tutorial-style doc of "how we do things" 20:45:59 it's not the policy 20:46:06 :) 20:46:14 the policy is way shorter than that 20:46:19 yeah 20:46:32 that, should eventually go into the the debian policy package as a sub-policy 20:46:45 next topic? 20:46:50 e.g. the perl policy is already there 20:46:51 next topic! 20:46:54 boutil, think so 20:46:56 #topic ruby-launchy 20:46:58 terceiro, yes 20:46:59 let's try a timebox of 1h for meetings :) 20:47:15 #idea let's just upload the package 20:47:28 i have another topic after this one (sorry) 20:48:01 avtobiff: if you want, just do it 20:48:04 (me too, but as an open question) 20:48:10 havent looked at all at ruby-launchy, but if all it does is open a browser, patch ruby-launchy to run xdg-open and uplaod that. 20:48:14 ? 20:48:20 The current ruby-launchy package has many patches 20:48:23 #idea if there are two or more rdepends on a package, it might be less work just uploading it instead of trying to patch out the use of it. 20:48:32 ch2500, i had that idea as well 20:48:45 I think it is less maintainable than just a patch to open a webbrowser with xdg-open 20:48:52 or write a shim from scratch with the same API 20:49:12 mmm 20:49:31 i dont care if there's an extra package, people wanting it should decide on whats less work and do that 20:49:40 it really is just Launchy.launch isn't it? 20:49:40 yeah 20:49:41 FYI 20:49:48 the *only* API supported: 20:49:51 Launchy.open( uri, options = {} ) { |exception| } 20:50:15 and everyone only uses it to open a web browser to view some html? 20:50:35 yep 20:51:16 there, ruby-launchy written in 1min: 20:51:33 $ cat lib/launchy.rb 20:51:33 module Launch 20:51:33 def self.open(uri, options = {}) 20:51:33 system('xdg-open', uri) 20:51:34 end 20:51:35 end 20:51:56 add a gemspec with the same version as the original package, and that's it 20:51:57 don't you need to escape the uri etc. security reasons. 20:52:09 system with multiple arguments doesn't shell out 20:52:16 ok 20:52:21 on rubygems.org launchy is used by 732 gems fyi 20:52:22 system("xdg-open #{uri}") would be broken 20:52:36 very good 20:53:01 #info terceiro propose to reimplement ruby-launchy in 5 lines, and be done with it. 20:53:03 but, on a more philosophical level, we will hit this in the future again. 20:53:35 do we really just want to reimplement small and simple(!) things everytime, instead of carrying upstream? 20:53:50 maybe it's on a case to case basis... 20:53:58 it is 20:54:00 case to case thing, depends on integration with debian 20:54:03 mmm 20:54:16 there's small and simple, and there is launchy 20:54:24 Silly doubt alert. Even if we are re-implementing it, there is a new package in archive right? Then, why not just package the upstream? 20:54:25 *snicker* 20:54:45 bsc: because the original package is a mess? 20:55:20 bsc, ok 20:55:25 oops.. terceiro ok 20:55:44 or I can even provide it inside rubygems-integration 20:55:55 it would be great 20:55:59 instead of adding a new binary, which would indeed be ridiculous 20:56:28 terceiro, i'd keep it out of that... 20:56:42 rubygems-integration? 20:57:23 ch2500: ok 20:57:26 :-p 20:57:35 #action terceiro will upload ruby-launchy-sim 20:57:40 #action terceiro will upload ruby-launchy-shim 20:57:50 problem solved then 20:57:56 next topic? 20:58:01 #info ruby-launchy-shim will provide the same API as launchy, and a corresponding gemspec 20:58:14 #topic bundler 20:58:37 what about bundler? 20:58:46 upstream hasn't been very supportive of us packaging it, and i can see why/where they are coming from 20:58:57 and i've lost interest/motivation working on bundler 20:59:15 otoh, pretty much everything wants to require bundler nowadays 20:59:28 not sure what the best thing to do is here 20:59:55 ch2500: do you have links to their reasoning? 21:00:14 TBH we don't have the option of not having it 21:00:35 whoever maintains rails will have to jump whichever hoops /o\ 21:00:38 no good link, but their approach is basically "we ship X, and it's not meant to be shipped by distros" 21:00:51 (and distros need to keep the breakage distros cause) 21:01:03 what does that mean? 21:01:41 f.e., if we decide that we can't ship their prebuilt manpages we're on our own 21:01:54 which i think is very reasonable, just not very helpful 21:02:12 prebuilt as in ... ? 21:02:20 nroff? 21:02:34 ronn 21:02:53 so yeah, ronn and nroff is included 21:02:58 and obv. nobody's gonna edit the nroff 21:03:25 there are countless packages with manpages in nroff 21:03:40 people do write manpages directly in nroff 21:03:41 but they are not the preferred form of modification and stuff 21:03:46 at least in this case 21:03:53 so they have source 21:03:58 is it in the git repo? 21:03:59 source is in the tar.gz 21:04:12 I don't see the issue then 21:04:15 but ronn is unmaintained and depends on the unmaintained hpricot 21:04:40 bad hpricot! 21:04:43 ah 21:06:59 pandoc can transform markdown into nroff 21:08:21 ch2500: so you look for someone to help and take over maintainance for bundler? 21:08:34 just the second part actually ;) 21:09:10 ok 21:09:24 #info bundler is looking for a new maintainer 21:09:32 I don't have a solution now, but I do have a package that uses ronn that I care about 21:09:49 so I will probably need to do something about it eventually 21:09:59 of course anyone is welcome to beat me to it 21:10:26 i think ronn upstream would welcome any help, too 21:10:27 #info transition of ruby-ronn from hpricot is a blocker 21:10:38 noted 21:11:01 next topic? 21:11:27 #topic next team sprint 21:11:37 ok 21:11:39 this one is quick 21:12:04 everyone please read 20151020141108.GA1178@debian.org> and reply 21:12:23 #link https://lists.debian.org/debian-ruby/2015/10/msg00069.html 21:12:36 less succintly: 21:12:57 we need to agree on a few basic topics: dates, specific location in brazil, and duration of the sprint 21:13:10 specially people who never attended, please consider coming 21:13:27 debian has money to cover sprint costs 21:13:43 and that is one of the most useful ways of spending the money that is donated to debian 21:13:45 looks really cool. would like to come. don't know if i'll be able to come. can i bring my entire family? 21:13:48 and sprint are cool 21:14:01 sprints are great! (when everybody is healthy) 21:14:20 boutil, indeed ;-) 21:14:34 avtobiff: you can bring them, but we can't justify covering their costs as well :-/ 21:15:02 how did this work at debconf? i think we got all our costs covered. 21:15:09 unless they all upload a few ruby packages in the archive before the sprint 21:15:14 lol 21:15:19 avtobiff: I don't know 21:15:28 no, they do other work and no work respectively 21:15:33 all as it should be :) 21:15:36 lol 21:15:39 i guess, ask leader@ about that part 21:15:56 indeed 21:16:11 was the last sprint a great success? :) 21:16:18 avtobiff: indeed. I am all for it, but we need debian-wide consensus that that is acceptable 21:16:42 that would be an interesting topic for -project, I guess 21:17:08 #info we need to agree on a few basic topics: dates, specific location in brazil, and duration of the sprint 21:17:16 one family members have contributed to DebianJr and conferences etc 21:17:30 but maybe that qualifies for debconf more than a ruby sprint 21:17:40 #action everyone read terceiro's email and reply 21:17:59 #info the email is <20151020141108.GA1178@debian.org>, linked above 21:18:36 very good! 21:18:39 nice 21:18:46 thanks! 21:18:49 I'm done 21:18:50 other questions? 21:18:54 yes 21:19:03 I wondered if there was a tips to share something like a "hide-list" in udd 21:19:11 when do we start an outreach program?! ;) 21:19:43 (hide-list for rc/things already threated by a team member) 21:20:16 sbadia: apart from "that'd be great" i have nothing to offer :-/ 21:20:52 hey :) ok, I ask to lucas then 21:21:06 anything else? 21:21:27 ok for me 21:21:52 then we'll stop here 21:21:57 thanks everybody! 21:22:02 #endmeeting