12:03:29 <ndevos> #startmeeting 12:03:29 <zodbot> Meeting started Tue Sep 9 12:03:29 2014 UTC. The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:03:29 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 12:03:37 <ndevos> #topic roll call 12:03:47 * kkeithley_ is here 12:03:49 <ndevos> hi all, who's here today? 12:04:42 * krishnan_p is here 12:04:47 * hchiramm_ here 12:05:29 <ndevos> okay, not too crowded today, maybe we can get some work done then 12:05:31 * jdarcy arrived just in time. 12:05:50 <ndevos> agenda, nice to have in the meeting minutes: https://public.pad.fsfe.org/p/gluster-bug-triage 12:06:19 <ndevos> #topic Status of last weeks Action Items 12:06:37 <ndevos> any items on the agenda marked as [done] will get skipped 12:06:48 <ndevos> #topic hchiramm to create/request a bugs@gluster.org mailinglist and have it as default assignee of any Gluster product bug 12:07:08 <ndevos> hchiramm_: I understood that the mailiglist was created? 12:07:29 <hchiramm_> yes 12:07:36 <hchiramm_> mailing list is created 12:07:50 <ndevos> any idea when the list will become the default owner for the bugs? 12:08:19 <hchiramm_> the request for making it default assignee is in progress 12:08:44 <hchiramm_> hopefully it will be done tonight 12:08:50 <ndevos> #action hchiramm to make sure that bugs@gluster.org becomes the default owner of new bugs 12:08:59 <hchiramm_> ndevos, ^^^^ 12:09:15 <ndevos> hchiramm_: yes, we'll follow up with that next week :) 12:09:17 <hchiramm_> everyone is encouraged to subscribe the same list 12:09:35 <hchiramm_> ok :) 12:09:44 <ndevos> hchiramm_: oh, and anywhere there is gluster-bugs@redhat.com assigned, or on CC, is that getting updated too? 12:10:13 <hchiramm_> I have put the request to replace gluster-bugs with bugs@gluster.org 12:10:22 <ndevos> hchiramm_: awesome! 12:10:30 <ndevos> #topic hchiramm to create "doc" component under GlusterFS in bugzilla 12:10:43 <hchiramm_> ndevos, done 12:10:50 <ndevos> thanks! 12:11:03 <ndevos> #topic lalatenduM will add bugzilla queries (per component) to the Bug triage wiki page 12:11:25 <ndevos> http://www.gluster.org/community/documentation/index.php/Bug_triage 12:11:28 <lalatenduM> ndevos, done 12:11:49 <ndevos> lalatenduM: thanks! 12:12:05 <ndevos> #topic lalatenduM requests iptables, df, SElinux and logs for bug 1109613 12:12:06 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1109613 urgent, unspecified, ---, kparthas, NEW , gluster volume create fails with ambiguous error 12:12:18 <lalatenduM> ndevos, done 12:12:24 <ndevos> cool :) 12:12:27 <ndevos> #topic lalatenduM asks the reporter of bug 1136349 to: a. make the private comments public, or b. post a summary that explains the issue/situation 12:12:28 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1136349 high, high, ---, spalai, POST , DHT - remove-brick - data loss - when remove-brick with 'start' is in progress, perform rename operation on files. commit remove-brick, after status is 'completed' and few files are missing. 12:12:36 <lalatenduM> yeah that also :) 12:12:39 <ndevos> :) 12:12:42 <ndevos> #topic hchiramm will split the Bug Triage page into smaller ones, starting with a "How to clone" best practise 12:12:49 <hchiramm_> ndevos, TBD 12:12:59 <ndevos> #action hchiramm will split the Bug Triage page into smaller ones, starting with a "How to clone" best practise 12:13:08 <ndevos> #topic lalatenduM will update the Bug Triage page to mark bugs for group triage (NEEDINFO on gluster-bugs@redhat.com) 12:13:25 <lalatenduM> ndevos, will do 12:13:31 <lalatenduM> on it 12:13:34 <ndevos> #action lalatenduM will update the Bug Triage page to mark bugs for group triage (NEEDINFO on gluster-bugs@redhat.com) 12:14:02 <ndevos> that were the AIs from last week, seems we managed to narrow down the list a bit :) 12:14:12 <ndevos> #topic Group Triage 12:14:33 <ndevos> there were no bugs added to the agenda, so we can skip that 12:14:59 <ndevos> but, we can have bugs marked for group triage in bugzilla 12:15:02 <ndevos> #topic Bugs marked for group triage (NEEDINFO from gluster-bugs@redhat.com) 12:15:10 <ndevos> https://bugzilla.redhat.com/buglist.cgi?f1=flagtypes.name&f2=requestees.login_name&o1=substring&o2=substring&v1=needinfo&v2=gluster-bugs%40redhat.com 12:15:42 <ndevos> only bug 1005616 is maked with NEEDINFO from us 12:15:42 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1005616 high, unspecified, ---, gluster-bugs, NEW , glusterfs client crash (signal received: 6) 12:16:34 <ndevos> I dont think there is a question for us in there? 12:16:56 <ndevos> it seems more of a please "help?!" request? 12:17:35 <ndevos> I'll drop the NEEDINFO now if nobody objects? 12:17:59 <krishnan_p> ndevos, should we ask what info (s)he is requesting from us? 12:18:04 <jdarcy> Looks like 3.3, and it's client-side self-heal. Didn't we disable/deprecate that in 3.4 or 3.5? 12:18:39 <ndevos> krishnan_p: there has not been any response from us on what the issue could be, the bug is in NEW and not Triaged 12:18:44 <hchiramm_> yeah the glusterFs version is 3.3.1 12:19:04 <ndevos> krishnan_p: so, I do not think there is an actual question... 12:19:10 <krishnan_p> ndevos, hmm 12:20:09 <ndevos> this bug is up for the normal triaging process, anyone can get that done 12:20:34 <ndevos> #topic New bugs to triage (filed since last week) 12:20:45 <ndevos> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&chfield=[Bug creation]&chfieldfrom=-1w&chfieldto=Now&f1=keywords&o1=notsubstring&product=GlusterFS&v1=Triaged 12:21:13 <ndevos> that is a most awesome link, you probably need to copy/paste the whole thing 12:22:27 <ndevos> there are quite some bugs there, please check if you can triage some 12:24:40 <ndevos> is there anything particular that someone notices amoung these new bugs? 12:26:25 <ndevos> well, I think we'll just move on then? 12:26:45 <kkeithley_> I can't always type that fast 12:26:52 <kkeithley_> e.g. 1136835 12:27:07 * ndevos checks 12:27:21 <ndevos> ah, yes, I just moved that to POST 12:27:33 <kkeithley_> Pranith cloned it. I sort of wonder if maybe the person cloning it has a particualr reason to clone it, then maybe they should take it? 12:27:36 <kkeithley_> oh, okay 12:28:06 <ndevos> oh, true, I'll assign it to pranith too 12:28:45 <kkeithley_> Or maybe they know who it should be assigned to, if they know enough about it to clone it 12:29:21 <ndevos> well, I tend to clone bugs that need a backport for other releases, but I do not want to do the backport myself 12:29:30 <ndevos> well, not each backport that is 12:30:01 <kkeithley_> cloning it doesn't automatically assign it to the same person the original was assigned to? Or does it? 12:30:06 <ndevos> but, when someone posts a patch, they should move the bug to POST regardless, it will not be in the list of to-triage bugs anymore then 12:30:13 <kkeithley_> indeed 12:30:39 <ndevos> no, you can pick someone to assign the clone to, I'm not sure what the default value is 12:31:10 <kkeithley_> right, that's my point 12:31:17 <ndevos> oh, the default assignee of a clone is the default assignee for the component 12:31:28 <ndevos> not the assignee of the cloned-bug 12:32:19 <ndevos> I think we could note it in the 'how to clone' steps hchiramm_ is documenting 12:32:27 <kkeithley_> +1 12:32:28 <krishnan_p> ndevos, I have a candidate for needinfo in our triage list - 1138229 12:32:43 <ndevos> but, not everyone has permissions to assign a bug to someone else :-/ 12:34:27 <krishnan_p> ndevos, I am trying to acquire the 'lock' before asking the appropriate question for BZ 1138229 and thereby avoid any possible mid-air collisions in bugzilla :-) 12:34:57 <ndevos> krishnan_p: lock granted to you! 12:35:46 <hchiramm_> krishnan_p, isnt a downstream bug ? 12:36:11 <ndevos> kkeithley_: on a clone, the original assignee will be put on CC by default, do you think that is sufficient? 12:36:45 <kkeithley_> sometimes it's sufficient 12:36:53 <ndevos> hchiramm_, krishnan_p: hmm, indeed, that version looks very much like rhs 12:37:03 <hchiramm_> glusterfs-3.6.0.22-1.el6rhs.x86_64 12:37:25 <ndevos> but, that must be RHS-3.0? rhs-2.1 is on glusterfs-3.4.... 12:38:45 <krishnan_p> hmm, didn't catch that. I went ahead and asked the reporter to share the libgfapi script that he uses to recreate the problem 12:38:56 <ndevos> kkeithley_: I'm not sure what we should expect from setting the assignee to the assignee of the cloned-bug 12:39:29 <ndevos> kkeithley_: are they supposed to backport the change, or is that a mere suggestion? 12:39:41 <hchiramm_> krishnan_p, ndevos if its downstream we have to change the product 12:39:47 * krishnan_p wonders why the reporter thought libgfapi issue should be classified under glusterd. 12:40:18 <ndevos> hchiramm_: depends on where the bits come from? 12:40:38 <ndevos> krishnan_p: ah, yes, lol, *anything* can be glusterd 12:40:49 <hchiramm_> if downstream version of GlusterFS is in use, we need that under RHS 12:40:55 <krishnan_p> ndevos, tell me about it :-) 12:41:24 <kkeithley_> if it gets assigned to someone and they think that's incorrect, they can reset the assignee. In the mean time at least it's assigned and maybe the assignee looks at it. If it's a backport, then yes, it's a strong suggestion that they should do the backport. IMO 12:41:52 <hchiramm_> true.. of the assignee think that issue exist in glusterfs , we need to track it for upstream as well 12:42:09 <hchiramm_> but any case we have to start with the proper product 12:42:15 <hchiramm_> of/if 12:43:41 <ndevos> kkeithley_: can we think of a way to track ASSIGNED bugs where there is no progress? or would we keep them in NEW? 12:43:58 <krishnan_p> hchiramm, should we ask the reporter if (s)he is facing this issue with the upstream bits as well? 12:45:06 <hchiramm_> not really , if we have the reproducer , assignee or reporter can check it.. 12:45:07 <kkeithley_> ndevos: yes, keep it in NEW until the Assignee acks it by changing it to ASSIGNED 12:45:57 <hchiramm_> krishnan_p, its flexible , but from our pov, its always to cross check against upstream version.. 12:46:16 <hchiramm_> insert(better) :) 12:46:19 <kkeithley_> IMO it might be found in rhs and reported against community glusterfs, and that's okay. Hopefully there's already a BZ for downstream and this should just be a clone 12:46:55 <ndevos> kkeithley_: ok 12:48:03 <ndevos> #action hchiramm_ to include a suggestion to assign a clone of a bug (and keep/add bugs@gluster.org on CC) in his 'how to clone' steps 12:48:11 <hchiramm_> kkeithley_, I fear we may fail in bug routing and fixing if we only have upstream bugzilla 12:48:33 <hchiramm_> the deadline and priority matters if its a downstream bug 12:49:18 <ndevos> hchiramm_: asking the reporter should do, and maybe ask if they have opened a support case for their RHS issue? 12:49:42 <ndevos> hchiramm_: after confirming, the bug could get cloned to the RHS product 12:49:50 <kkeithley_> hchiramm_: I wasn't trying to suggest that we only have upstream bugzilla. Just saying that IMO the fact that the version is 3.6.0...rhs does not mean it's misfiled 12:50:11 <kkeithley_> yes, what ndevos wrote 12:50:54 * ndevos sees that there are 10 minutes left... 12:51:05 <ndevos> #topic NEW bugs that do not have the "Triaged" keyword, listed per version 12:51:14 <hchiramm_> ndevos, kkeithley_ yep, we need to confirm and perform further actions. 12:51:27 <ndevos> for the ones paying attention to the agenda, I've skipped one point 12:51:34 <ndevos> (that was intentional) 12:51:58 <ndevos> kkeithley_: the new links with the ^3.4 at the end might be interesting for you 12:52:05 <ndevos> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&f2=version&o1=nowords&o2=regexp&v1=Triaged&v2=^3.4 12:52:26 <kkeithley_> yes, I just clicked on that and the first BZ is filed against mainline 12:52:35 <ndevos> :-/ 12:52:57 <kkeithley_> and the second 12:53:02 <ndevos> huh? 12:53:15 <ndevos> not for me... bug 911160 is the first 12:53:15 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=911160 unspecified, medium, ---, kparthas, NEW , Following a change of node UUID I can still reconnect to the volume 12:53:36 <ndevos> filed against 3.4.0-alpha 12:54:29 <ndevos> kkeithley_: maybe you need to copy/paste the full url and not right-click-open-in-new-tab ? 12:54:57 <kkeithley_> sort order. 911160 is last in my case. reverse teh sort order and 911160 is first 12:55:39 <ndevos> well, Bug 1136810 12:55:39 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1136810 high, unspecified, ---, gluster-bugs, NEW , Inode leaks upon repeated touch/rm of files in a replicated volume 12:55:41 <kkeithley_> but, e.g. 1136810 is last (or first) and it's filed against mainline 12:55:49 <ndevos> is last, for 3.4.2 12:56:14 <ndevos> well, that actually is the same bug? 12:56:56 <ndevos> and really, it is for 4 12:57:02 <ndevos> uh, 3.4.2 12:57:04 <kkeithley_> whoa, bugzilla is going crazy on me 12:57:11 <kkeithley_> rathole 12:58:04 <ndevos> well, when bugzilla likes you again, I hope these new URLs are helpful 12:58:13 <kkeithley_> yup 12:58:22 <ndevos> #topic Open Floor 12:58:34 <ndevos> kkeithley_: you added bug 1127140 ? 12:58:35 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1127140 unspecified, unspecified, 3.4.6, gluster-bugs, NEW , memory leak 12:58:38 <kkeithley_> I did 12:59:22 <kkeithley_> this is likely the last blocker for 3.4.6 and nobody seems to be interested in it 12:59:24 <ndevos> okay, I guess you want to triage it together? 12:59:31 <kkeithley_> I've looked at it 12:59:38 <kkeithley_> don't see anything obvious 12:59:49 <kkeithley_> who is the right person to gift this to? ;-) 13:00:01 <ndevos> hmm, and "not entirely sure how to reproduce" is not very helpful 13:00:30 <ndevos> who is listed in MAINTAINERS for fuse? 13:00:34 <kkeithley_> and parenthetically, it looks like 3.5.2 has the same (or similar) leak in my longevity cluster 13:00:53 <ndevos> oh :-/ 13:01:22 <kkeithley_> MAINTAINERS file, yes, I know about that actually 13:01:30 <kkeithley_> Hadn't gotten that far 13:01:37 <ndevos> fuse seems to be avati, bfoster and csaba - none of them are very actively working on fuse, I think 13:02:16 <ndevos> I know pranith has an interest in fuse, maybe poke him? 13:02:40 <kkeithley_> okay 13:02:58 <kkeithley_> good enough, thanks 13:03:35 <ndevos> anyone else an other topic for the open floor? 13:03:52 <ndevos> if not, we'll end the meeting in a few seconds 13:04:31 * ndevos thinks we've been waiting long enough 13:04:35 <ndevos> #endmeeting