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