15:00:42 #startmeeting Gluster Weekly Community Meeting 15:00:42 Meeting started Wed May 21 15:00:42 2014 UTC. The chair is JustinClift. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:42 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:51 Roll call 15:00:57 * hagarth is here 15:01:02 * Humble here 15:01:18 Etherpad link: http://titanpad.com/gluster-community-meetings 15:01:19 * purpleidea is here but also in a real life meeting 15:01:20 Title: TitanPad: gluster-community-meetings (at titanpad.com) 15:01:26 * dbruhn is here 15:01:56 * ndevos is there too 15:02:20 * xavih is here 15:02:51 #topic Action items from last meeting(s) 15:03:08 "JustinClift to discuss with hagarth + Mgmt if a new approach to prioritisation is needed" 15:03:25 It's er... "in progress". I only started looking at this today. 15:03:39 Emailed hagarth to setup a time. ;) 15:03:42 JustinClift: sure, let us sync up later this week. 15:03:54 hagarth: Cool. :) 15:04:04 "JustinClift to hook some Jenkins slaves into build.gluster.org" 15:04:37 I'm still working on it. There have been multiple things getting in the way (finally finished those off today). 15:05:03 * JustinClift has a time already set aside with Luis Pabon on Thurs (8pm) to pick his brain about doing this 15:05:50 We should probably setup a NetBSD slave box too - there's a Jenkins port - in order to automatically test on NetBSD as well 15:05:58 "JustinClift to locate next Etherpad to try. Must be reliable and not require accounts for ppl" 15:06:31 Didn't get to it, so will need to do it over the next week. 15:06:42 Using TitanPad again as initial fallback 15:06:58 (maybe it'll be more reliable now, 6 weeks after the initial problems) 15:07:11 JustinClift: is hosting an etherpad on gluster.org a possibility? 15:07:34 hagarth: John Mark veto'd that when it was suggested initially 15:08:08 hagarth: Though, we could try that as long as it's all fully automatic. (eg minimal/no maintainence burden) 15:08:19 Lets try the public ones first, and see how that goes 15:08:24 JustinClift: sounds good 15:08:31 Moving on... 15:08:39 #topic 3.5.1 15:08:46 "hchiramm: How's the documentation for 3.5.1 going?" 15:08:59 JustinClift, half done.. \o .. hopefully, I will finish it soon.. \o/ :) 15:09:08 Humble: what all are pending atm? 15:09:28 DRC, libgfapi ..etc 15:09:36 #link https://bugzilla.redhat.com/showdependencytree.cgi?hide_resolved=1&id=glusterfs-3.5.1 15:09:38 Title: Dependency tree for Bug 1071800 (at bugzilla.redhat.com) 15:09:45 the bugs in NEW state need work :) 15:09:52 ndevos: Cool, I was just looking for that 15:10:23 gfid-access , rdma-cm ..etc are pending on feature owner.. 15:10:27 hagarth, ^^ 15:10:49 I think we need to wrap this up pretty soon.. there are one or two ugly crashes in 3.5.0 which have been already merged in 3.5.1 15:11:00 it would be good to have 3.5.1 out soon 15:11:08 Humble: Are the ones depending on feature owners that you're worried about? 15:11:21 gfid-access is mostly a developer oriented enhancement, do we need that in admin-guide 15:11:25 JustinClift, yes 15:11:34 rdma-cm has some content in doc/ 15:11:57 +1 for getting 3.5.1 out soon. We need stuff that's in its gfapi for nfs-ganesha-2.1, which just released their first RC. 15:12:05 Humble: sure, please contact Raghavendra G for rdma-cm 15:12:05 hagarth, there are some more like changelog geo rep .. 15:12:16 hagarth, 4 bugs are pending on him 15:12:24 Humble: Would you be ok to email gluster-devel with the bullet point list of what's still outstanding, and they one's you're worried about? 15:12:38 he has promised he will complete it .. but its almost one week now.. 15:12:41 hagarth, ^^ 15:12:50 Humble: an email on gluster-devel would be helpful 15:12:51 JustinClift, yeah.. give me one more day.. 15:12:57 Sure 15:13:00 hagarth, sure.. 15:13:01 so that others can chip in too 15:13:06 yep 15:13:28 Humble: just put the feature owners on CC too ;) 15:13:31 how about sending a daily reminder/nag on pending bugs for 3.5.1? 15:13:42 #action Humble to email gluster-devel with the bullet point list of docs still outstanding for 3.5.1, and the ones he's concerned about 15:13:43 hagarth, ndevos +1 15:13:46 like I do it for spurios failures :-P 15:13:53 hagarth: yeah, that might be good too :) 15:13:54 a mail to feature owners are already sent one week back .. 15:14:11 ndevos: the ball is in your court now ;) 15:14:11 pk1: It's effective :) 15:14:22 JustinClift: :-) 15:14:35 Moving on... 15:14:38 ndevos: How are the non-documentation patches for 3.5.1 going? 15:14:38 hagarth: oh, thanks! :D 15:15:14 JustinClift: I think one is waiting for inclusion in master 15:15:29 and there are 2-3 others that need a review in release-3.5 15:15:57 ndevos: Would you be ok to email gluster-devel with their details, to help get eyes on them 15:16:19 * lpabon here 15:16:21 JustinClift: yes, I got that AI already 15:16:28 ndevos: :) 15:17:04 ndevos: k, what's your ETA then? :) 15:17:21 JustinClift: for the email? later today 15:17:38 Nah, I'm meaning for 3.5.1 :) 15:17:54 (obviously depending on docs stuff) 15:18:11 should we aim for sometime next week? 15:18:13 JustinClift: I hope to get a beta out tomorrow, that should get tested a little before a final release 15:18:41 k. Yeah, that'll help the people that are experiencing crashes 15:18:44 hagarth: next week suits me 15:18:53 Cool. 15:18:54 ndevos: cool, thanks! 15:19:10 and, when the beta is out, the associated bugs should get moved to ON_QA too ;) 15:19:32 ndevos: right 15:19:34 the bugs with fixes actually in the beta 15:19:42 #info 3.5.1 beta for tomorrow, if positive testing results + all docs ready then release next week 15:19:48 079222 15:19:50 kkeithley: yes, of course ;) 15:20:04 just me and my keen eye for the obvious 15:20:18 Moving on 15:20:19 ;-) 15:20:23 #topic 3.4.4 15:20:29 what did purple idea say? 15:20:31 kkeithley: How are the patch reviews for this going? 15:20:37 pk1: Wrong window 15:21:38 what's the tracker bug for 3.4.4? 15:21:42 just need http://review.gluster.org/#/c/7583/ reviewed. Seems like people are waiting for lalatenduM's patch on master. It's legitimate to fix something on a branch and (logically) merge to master too though. 15:21:43 Title: Gerrit Code Review (at review.gluster.org) 15:22:04 tracker for 3.4.4 is tracker BZ https://bugzilla.redhat.com/show_bug.cgi?id=1095324 15:22:06 Bug 1095324: unspecified, unspecified, 3.4.4, kkeithle, ASSIGNED , Release 3.4.4 tracker 15:22:23 kkeithley: will review that tomorrow 15:22:43 thanks 15:22:57 kkeithley: is that the cppcheck one? 15:23:02 yes 15:23:22 okay, cool, I might be able to pick that for 3.5.1 too then 15:23:38 kkeithley: That IANA brick ports thing... who would know? 15:23:39 for 3.5.1 there is http://review.gluster.org/#/c/7605/ 15:23:41 Title: Gerrit Code Review (at review.gluster.org) 15:23:58 I'm pretty sure we're already using ports above 45152 in 3.4.x 15:24:04 JustinClift: IANA ? 15:24:16 Internet Assigned Numbers Authority 15:24:25 yes kkeithley is right, we switched to IANA compatible scheme from 3.4.0 15:24:36 * ndevos thought so too 15:25:13 * Humble recall IANA via 1095595 15:25:16 kkeithley: We need to pull xavih patch as well 15:25:18 so I'm going to close it as not a bug, we're not updating 3.3, and I wouldn't want to make a change like that from 3.X.3 -> 3.X.4 anyway 15:25:42 kkeithley: No worries. ;) 15:25:44 pk1: which patch is that? would you please update the tracker? 15:26:21 http://review.gluster.org/6736 15:26:22 Title: Gerrit Code Review (at review.gluster.org) 15:26:41 pk1: this has been merged in both master and release-3.5 right? 15:27:00 hagarth: yes. This is for 3.4? 15:27:16 pk1: That's the 3.5 patch. Is there a 3.4 one? 15:27:19 hagarth: I was debugging one bug submitted by a user. Seems to be this 15:27:29 JustinClift: We need to port it. 15:27:48 pk1: Are you ok to do it in time for 3.4.4? 15:27:51 pk1: I see, might be good to add the bug to the tracker and backport this patch. 15:28:00 pk1: it's already ported: http://review.gluster.org/6737 15:28:02 Title: Gerrit Code Review (at review.gluster.org) 15:28:12 xavih: yes it is :-) 15:28:13 it needs to be merged 15:28:35 Ahh cool. That's looking ready. 15:29:10 k, Moving on 15:29:14 #topic Failing regression tests progress update 15:29:20 JustinClift: one question on 3.4.4 15:29:24 np 15:29:27 Go for it 15:29:40 what's the likely schedule for 3.4.4? 15:29:47 Good point 15:29:55 kkeithley: eta for 3.4.4? 15:30:21 Those two bugs... As soon as I get the changes reviewed 15:30:55 kkeithley: I will review both tomorrow 15:31:26 #action hagarth to review the last few patches for 3.4.4 tomorrow (22nd May) 15:31:30 xavih: I cloned the BZ https://bugzilla.redhat.com/show_bug.cgi?id=1099955. ¿would you please resubmit http://review.gluster.org/6737 against the new BZ? Thanks 15:31:32 Bug 1099955: high, unspecified, ---, vbellur, NEW , self-heal process can sometimes create directories instead of symlinks for the root gfid file in .glusterfs 15:31:44 kkeithley: sure 15:31:45 #action kkeithley to release 3.4.4 this week if the patches are good 15:31:58 kkeithley: I'll do it just after the meeting 15:32:08 thanks 15:32:08 If the patches need work though, next week is fine.. ;) 15:32:33 k. Moving on attempt 2 15:32:40 "Failing regression tests progress update" 15:32:59 JustinClift: my favorite topic :-) 15:33:33 The regression tests are now in *much* better shape, thanks to pk1, Raghavendra G, and others 15:33:57 JustinClift: Vijai also sent a mail about the consistent failing test case. 15:34:04 what tests are the major offenders right now? 15:34:07 I kicked off a 20 VM test just before this meeting started, and will collect results after it 15:34:23 should we send a weekly offending list on gluster-devel till the problem is fixed? 15:34:25 hagarth: The one Vijai is working on 15:34:33 pk1: ok 15:34:34 hagarth: daily please 15:34:46 In the testing yesterday (before a new dependency problem showed up) it was all passing (100%) 15:34:54 pk1: will you be the owner for sending those nags? 15:34:56 Though it was only a 10 vm test on master 15:35:29 hagarth: Love to :-) 15:35:32 JustinClift: 100% pass sounds too good to be true ;) 15:35:37 pk1: Good man 15:35:50 pk1: thanks 15:35:57 hagarth: Well, I notice that Rackspace VM's seem to have good hours and bad hours 15:36:09 JustinClift: They are mostly races, which are the kinds of bugs I love :-) 15:36:13 #action pk1 to send daily nag emails on gluster-devel for regression test failures 15:36:26 So, if I start a bunch of VM's sometimes they can all pass. But the exact same git commit can have massive failures a few hours later 15:36:34 pk1: Yeah, so racy behaviour 15:36:58 JustinClift: might be good to record those races and keep sending them on gluster-devel. 15:37:29 hagarth: So, we'll only really have a good "reliable" 100% after it's been all passing for at least a few days regardless of when it's run 15:37:40 hagarth: this is the new offender. It has a core too. Something related to rebalance I think 15:37:59 hagarth: tests/bugs/bug-884455.t 15:38:05 pk1: interesting 15:38:15 hagarth: Yeah, definitely going to keep emailing gluster-devel with failure results that show up 15:38:22 * JustinClift has been trying to over the last few days 15:38:26 pk1: I recollect seeing this test fail before 15:38:45 However the tests have been broken in the meantime for various reasons not related to them 15:38:52 hagarth: Oh. Let me give an update when I get some more info 15:39:06 eg new dependency introduced by latest mock, etc 15:39:26 + breakage of the script (my own fault), etc 15:39:36 Anyway, we're on the right trajectory now 15:39:55 For the 2nd part of the Regression problem... 15:40:08 I'm still working on getting Jenkins setup with slaves in Rackspace 15:40:31 * JustinClift has time set aside to chat with lpabon about it tomorrow evening, to pick his brains about it 15:40:53 Was hoping for last week, but other non-gluster stuff took priority 15:40:57 I have one proposal to make about the mempool masking memory corruptions issue, once this topic is over. 15:41:06 JustinClift: if you capture some notes, please circulate that. Even a few other community folks might be interested in providing slaves. 15:41:18 pk1: add it to the agenda, there are few more to be discussed 15:41:27 hagarth: Yeah, I'll put it into a wiki page 15:41:51 Um... I think that's it for this topic 15:41:59 Moving on... 15:42:08 #topic Other items 15:42:12 3.6 15:42:16 Who's is that? 15:42:20 JustinClift: me 15:42:27 Go for it 15:42:36 Revised Feature freeze for 3.6 was planned for today 15:43:03 but have got requests from a few feature owners to move the schedule 15:43:17 I am in favor of moving the entire 3.6 schedule by 2 weeks or so 15:43:21 any thoughts on that? 15:43:43 this will give more time for all of us to get whatever we want into 3.6. 15:43:46 Lets do a month instead, and give people some time to focus on the docs instead of pushing too hard? 15:44:11 JustinClift: that sounds reasonable to me too 15:44:33 hagarth: is there a list of things that is still missing? 15:44:40 hagarth:, JustinClift +1 15:45:13 ndevos: don't have one ready, but let me update the planning36 page to reflect current status 15:45:26 hagarth: okay, that works too 15:45:41 #action hagarth to update the planning36 page to reflect current status, new schedule 15:45:57 hagarth: But it should be released before next downstream version. Right? 15:46:26 msvbhat: we bother only about community/upstream schedules here :) 15:46:34 So, we're good with 1 month push back for 3.6 schedule? 15:46:42 No objections... ? 15:47:15 don't see any 15:47:21 #agreed 3.6 schedule will be pushed back 1 month 15:47:41 Moving on 15:47:45 "NetBSD & OS X Port maintainers" 15:47:50 Who's is that? 15:48:19 * hagarth again 15:48:24 Go for it 15:48:45 I am considering adding NetBSD & OS X port maintainers for GlusterFS 15:49:03 What's a "port maintainer" ? 15:49:19 port maintainers will work with our regular releases to ensure that the respective ports of GlusterFS also arrive on time 15:49:38 Ahhh. Interesting idea. 15:49:49 they will also manage/merge patches necessary to keep the ports in a stable state 15:49:56 Manu would be the logical choice for the NetBSD one. 15:50:09 yes, Emmanuel Dreyfus is the obvious candidate for NetBSD. 15:50:20 NetBSD should be manu? OSX should be harsha? 15:50:36 Harshavardhana and Dennis would be the obvious ones for OS X 15:50:52 Yeah. Dennis mentioned he probably won't be around as much for a while though 15:51:04 eg he's relocating country to work at a start up 15:51:18 So Harsha :) 15:51:27 JustinClift: right, however I think he deserves this recognition too for all the heavylifting that he did. 15:51:55 my preference would be too have them both for OS X. 15:52:13 Recognition definitely well deserved for both of them 15:52:25 I will send out a note on gluster-devel on this if we do not have objections on this one. 15:52:25 Ask them I guess :) 15:52:30 Yeah 15:52:35 JustinClift: sure 15:52:51 OK, that's all around this one 15:53:00 No worries. It's a good idea. :) 15:53:14 Moving on... 15:53:15 "Engaging Community Developers for patch review?" 15:53:20 That's mine 15:53:53 go ahead 15:54:27 It's just an idea in the back of my head... do we have many people outside RH who are significant contributors in deeply knowledge gluster areas yet? 15:54:36 (sorry, took time to type) 15:54:55 eg Gluster development really needs a bunch of in depth experience in some areas 15:55:14 JustinClift: To encourage may be we should gear up dev documentation first. 15:55:28 So I'm just wondering if there's strategies we've used previously to attract those people 15:55:32 So that we can repeat it :) 15:55:38 pk1: Agreed 15:55:39 JustinClift: One more thing we can do is what golang community does, 15:55:43 also update "AUTHORS" file in source .. 15:55:55 JustinClift: we certainly do have folks like xavih, bharata rao & Mohan who are very knowledgeable wrt glusterfs 15:56:00 Humble: We have a MAINTAINERS file that's equiv now don't we? 15:56:13 JustinClift: Publish bugs that experienced developers can help new devs to fix. 15:56:26 pk1: nice idea! 15:56:39 hagarth: Thats what golang does 15:56:45 hagarth: Cool. I'm wondering if we can copy whatever approach worked for them, and repeat it :) 15:56:47 we have the extras/who-wrote-glusterfs.sh (or something) script, maybe we should blog post about contributions on a release? 15:56:56 ndevos: absolutely! 15:57:00 afaict, MAINTAINERS and AUTHORS are different .. Isnt it ? 15:57:15 ndevos: That's a really good idea 15:57:34 Humble: What should be in the AUTHORS file? 15:57:45 You mean like a list of all contributors ever? 15:57:50 yep .. 15:57:54 JustinClift: AUTHORS will be something like that. 15:58:02 JustinClift: yes, that is what AUTHORS in Wireshark does 15:58:05 Yeah, don't see why not 15:58:15 pk1: how about each sub-maintainer publishing and curating their list of easy to solve bugs? 15:58:35 hagarth: Yeah that is what I was wondering we should do 15:58:47 Humble: Do you want to update the AUTHORS file? 15:58:53 pk1, hagarth: and backports! http://www.gluster.org/community/documentation/index.php/Backport_Guidelines 15:58:54 I can do 15:58:54 Title: Backport Guidelines - GlusterDocumentation (at www.gluster.org) 15:59:00 hagarth: I did that with some of our colleagues at redhat and worked wonders 15:59:11 Humble: If you can script it btw, then by all means so that (and add the script to contrib/ or something) 15:59:24 pk1: please publish that on gluster.org and send out a note on mailing lists 15:59:31 #action Humble to update AUTHORS file 15:59:36 ndevos: awesome! 15:59:38 hagarth: Make an action for it :) 16:00:10 #action sub-maintainers to publish and curate easy to solve bugs for more community involvement. pk1 to lead by example. 16:00:11 ;) 16:00:15 :) 16:00:54 hagarth: yes sir! 16:01:05 ndevos: Does either of those above cover the "maybe we should blog post about contributions on a release" concept? 16:01:18 pk1: I didnt know there exist easy afr bugs? 16:01:21 I think we should publish names of developers for features when it is released 16:01:33 ndevos: believe me there are! 16:01:44 lalatenduM: As part of Release Notes or similar? 16:01:51 ndevos: most of them are logging related. So shouldn't be a big deal 16:01:57 slight OT, should we add a page for developers and prominent community users on gluster.org? 16:01:58 JustinClift: not really, are you not familiar with the 'who wrote linux $version?' posts? 16:02:00 * kkeithley wonders.... if they're easy, why aren't they already fixed? 16:02:09 JustinClift, part of release notes 16:02:12 ndevos: No, I'm not 16:02:24 Check Ceph's release notes for reference :) 16:02:45 kkeithley: Priority :-( 16:02:49 JustinClift: http://lwn.net/Articles/507986/ 16:02:50 Title: Who wrote 3.5 [LWN.net] (at lwn.net) 16:02:52 pk1, it would be great help to guys like me :) 16:03:17 kkeithley: experienced developers' affinity for a bug is inversely proportional to the ease of its fix ;) 16:03:29 +1 for bugs for beginners 16:03:39 #info we should include feature owner info (eg promo for each author) in our release notes. Eg for 3.6. 16:04:27 JustinClift: I am keen on showcasing our users and developers on gluster.org, but we could take it offline. 16:04:27 JustinClift, it is another way to appreciate devs 16:04:29 We have some "typos needing fixing" bugs that need doing. Good for people learning git and gerrit first time I reckon 16:04:51 lalatenduM: Yeah, I'm fully agreeing with anything along these lines :) 16:04:52 hagarth: you hit the nail on the head :) 16:04:54 JustinClift: Yes. Logging bugs can also go in there. 16:05:11 I usually try to slip those "easy" things into bigger fixes when I can. 16:05:27 #action hagarth to start discussion on showcasing Gluster users and developers 16:05:37 JustinClift: cool 16:05:51 k, is there anything I've missed under this bit so far before we move on? 16:05:58 pk1: those bugs should get the EasyFix keyword in bugzilla, it makes it easier to find bugs that way 16:06:08 ndevos: +1 16:06:15 * JustinClift didn't know that was a thing 16:06:17 ;) 16:06:26 JustinClift: I had a suggestion to make... 16:06:30 lalatenduM: ^ maybe a note for your bug triaging guidelines :) 16:06:53 pk1: go ahead before we pick up the last topic 16:06:55 ndevos, agree 16:07:02 #action JustinClift We should consider a "Who Wrote GlusterFS" thing, similar to https://lwn.net/Articles/507986/ 16:07:04 Title: Who wrote 3.5 [LWN.net] (at lwn.net) 16:07:17 JustinClift: We should run regressions without mempool 16:07:35 it is masking memory corruptions is my feeling 16:07:55 k, I don't know what a mempool is yet. If you tell me how to run regressions without it, I'm happy to do so. :) 16:08:12 * JustinClift realises this could make him look stupid ;) 16:08:33 Anyone object to us trying it? 16:08:47 pk1: how do you plan to do it - > have some magic flag that converts mempool to gf_calloc ? 16:08:55 I can send a patch which will set mempool count to 1 in case of DEBUG builds. We need to run the builds with that flag for regressions 16:09:37 pk1: ok, sounds like a good idea 16:09:41 mem_get will do calloc if the pool is full 16:09:59 pk1: once we have more slaves, we can run regressions with & without this flag 16:10:12 Sounds like a plan :) 16:10:15 hagarth: Yes. Future item then 16:10:29 pk1: ETA for when you can send that patch? 16:10:40 JustinClift: its a one liner. 16:10:44 When? 16:10:51 JustinClift: tomorrow 16:10:57 India time 16:11:13 pk1, excellent idea 16:11:27 #action pk1 to submit mempool disabling patch tomorrow 16:11:38 pk1: All good. :) 16:11:45 pk1: does that not also require building the packages with --enable-debug or something like that? 16:11:46 JustinClift: yes :-) 16:11:57 one more topic for today? 16:11:58 hagarth, I was thinking why we are not testing debugs builds , where code is full of gf_asserts :) 16:12:07 ndevos: Yes. Thats the part where JustinClift comes :-) 16:12:20 pk1: I dont think JustinClift realized that bit ;) 16:12:26 lalatenduM: limited CI infrastructure is the primary reason 16:12:27 @%@#@@$@#$!!!! 16:12:28 Heh 16:12:43 Nah, I'm cool. Let me know what needs to be done, etc. 16:13:03 JustinClift: I will send out a mail on gluster-devel about the commit. 16:13:10 need to drop pretty soon .. are we discussing "Gluster Forge project for bug-upsting and release-engineering scripts?" 16:13:15 pk1: Will there be some way to verify that mempool is disabled in builds when we're running tests? 16:13:28 pk1: Lets that that offline 16:13:29 JustinClift: I will elaborate in the mail 16:13:30 Moving on 16:13:44 "Gluster Forge project for bug-upsting and release-engineering scripts?" 16:13:48 that last topic is mine 16:13:52 Go for it :) 16:14:04 I've discussed it with lalatenduM before, but we did not really come to a conclusion 16:14:25 Er... what's bug-upsting? 16:14:25 JustinClift: we definitely could host a forge repo if we do not have anything ready for these scripts 16:14:26 we have some small scripts to help with the bug checking and updating 16:14:51 JustinClift: bug-updating :) 16:14:55 Ahhh 16:15:23 like the script I've used to close the 180 (or 280?) bugs last month 16:15:45 ndevos: sure, let us get them over to forge. 16:15:46 Yeah, chuck it on Forge somewhere 16:16:00 does anyone knoe if there is a project on the forge or elsewhere that we should re-use? 16:16:18 JustinClift: you do have one project on forge for something similar right? 16:16:31 JustinClift: scripts from b.g.o? 16:16:52 Hmmm... I'm not sure. I have a few things on there but am only remembering the regression and /opt/qa ones 16:16:57 It's possible 16:16:59 one project on the forge can have multiple git repositories, it might make sense to keep it all together 16:17:04 hagarth, thats for regression tests I guess, JustinClift 16:17:10 lalatenduM: right 16:17:15 If not, lets create a new one. Make the owner the glusterfs-infra group I guess 16:17:19 we can have one more then 16:17:24 JustinClift, +1 16:17:50 lalatenduM: a new project? like bug-zappers or something? 16:17:55 #action ndevos to get the bug-updating and release-engineering scripts onto the forge 16:18:07 ndevos, yes, not sure abt the name 16:18:21 anyone has a better name? 16:18:25 ndevos, lets keep it generic, so that we can add other scripts later 16:18:28 ndevos: Takea look through the forge later, and see what you can find. Make a new one if not, etc. 16:18:38 "bug-maintainance-tools" ? 16:19:13 * ndevos really doesnt care that much 16:19:36 I'm sure you'll think of something. 16:19:41 Just make sure the name is in English. ;) 16:19:51 JustinClift, +1 :) 16:19:53 k. moving on... 16:20:04 Anyone have anything else? 16:20:14 ndevos, will think abt it and will let u know if I find a good name 16:20:23 lalatenduM: please do :) 16:20:34 ... 16:20:40 #endmeeting