12:01:27 <ndevos> #startmeeting
12:01:27 <zodbot> Meeting started Tue Sep  2 12:01:27 2014 UTC.  The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:01:38 <ndevos> agenda: https://public.pad.fsfe.org/p/gluster-bug-triage
12:01:44 <ndevos> #topic Roll Call
12:01:51 * kkeithley is hiere
12:01:51 <ndevos> Hi all, who's online today?
12:02:20 * hagarth is here
12:02:50 <ndevos> and elico joins us too :D
12:03:03 <ndevos> hchiramm, lalatenduM, JustinClift?
12:03:06 <elico> Just wanted to see what is it about.
12:03:21 * lalatenduM is here
12:03:28 <ndevos> elico: you're very welcome, feel free to drop comments as we go
12:03:29 <lalatenduM> ndevos, hello
12:03:46 <elico> Thank!
12:03:56 <ndevos> elico: https://public.pad.fsfe.org/p/gluster-bug-triage is the agenda for today
12:04:31 <ndevos> hmm, seems we have a few guys missing, I guess it'll be a short meeting
12:05:01 <ndevos> lets go through the action items from last week
12:05:12 <ndevos> #topic hchiramm to create/request a bugs@gluster.org mailinglist and have it as default assignee of any Gluster product bug
12:05:31 <ndevos> any one knows if hchiramm got that done?
12:05:56 <ndevos> I guess not..
12:06:02 <hagarth> I don't think so
12:06:04 <ndevos> #action hchiramm to create/request a bugs@gluster.org mailinglist and have it as default assignee of any Gluster product bug
12:06:11 <ndevos> #topic ndevos to describe how to 'watch' gluster-bugs@redhat.com and filter email
12:06:30 <ndevos> well, I've got that drafted, but was not sure where to post it
12:06:43 <ndevos> should we put that on a seperate wiki page?
12:06:48 <lalatenduM> ndevos, a blog would be good
12:06:54 <lalatenduM> yeah wiki page
12:06:57 <elico> is it text? pdf?other?
12:07:07 <lalatenduM> should be linked to the bug triage page
12:07:09 <ndevos> it's just text
12:07:18 <elico> the a wiki can be a good idea.
12:07:25 <ndevos> oh, and I was thinking to add a some images too
12:07:47 <ndevos> okay, 2 votes for a wiki page, that works for me
12:07:53 <elico> still can be good in a wiki.
12:08:19 <ndevos> #agreed ndevos to create a wiki page to describe how to 'watch' gluster-bugs@redhat.com and filter email
12:08:30 <ndevos> #topic hchiramm to create "doc" component under GlusterFS in bugzilla
12:08:46 <ndevos> hmm, do we have a doc component yet?
12:09:03 <ndevos> no, we dont :-/
12:09:10 <ndevos> #action hchiramm to create "doc" component under GlusterFS in bugzilla
12:09:23 <ndevos> #topic ndevos to prepare some bugzilla queries that show untriaged bugs per component(-group)
12:09:47 <ndevos> they are currently in the agenda, see https://public.pad.fsfe.org/p/gluster-bug-triage under "group triage"
12:10:00 <Thilam> hum sorry, it's the first time I attend this meeting
12:10:09 <Thilam> how does it work ?
12:10:11 <ndevos> Thilam: welcome!
12:10:45 <ndevos> Thilam: we're going through the point in the agenda (see link above), we're currently at the last bullit-point from #2
12:11:01 <lalatenduM> Thilam, welcome
12:11:02 <elico> I am unsure I understood but the idea behind the "doc' component is to make it all be well organized in the bugzilla right?
12:11:17 <ndevos> elico: yes, that is it
12:11:57 <ndevos> bugs or improvements to the documentation should get their own component in bugzilla, makes it easier for searching particular bugs
12:12:03 <elico> just to make it more clear: What would be the definition of a triage, compared to a non-tirage bug?
12:12:13 <elico> ho OK.
12:12:40 <lalatenduM> elico, http://www.gluster.org/community/documentation/index.php/Bug_triage
12:12:59 <ndevos> well, a new bug get filed by a user, that user may not understand the different components and picks 'glusterd' at (mostly) random
12:13:38 <ndevos> someone needs to look at the bug, and check if it is indeed a glusterd bug, or something else, and verify if there is enough information for the developers to get the bug fixed
12:14:30 <ndevos> if something is incorrect, or missing, the one doing the triage for that bug should request the missing details from the reporter, or fetch the details somehow else
12:15:21 <elico> it's starting to make more sense..
12:15:22 <ndevos> when the bug has got the correct component, and all the details (versions, error messages, logs, ...) are there, the bug can get marked as "Triaged"
12:15:57 <ndevos> the goal is that developers can focus on the Triaged bugs, and need to invest less time in the troubleshooting or information gathering
12:17:06 <lalatenduM> elico, you can see some example here i.e. a bugzilla query https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords=Triaged&keywords_type=anywords&list_id=2739593&product=GlusterFS&query_format=advanced
12:17:29 <ndevos> anyway, we're getting off-topic
12:17:56 <ndevos> should we list those bugzilla queries in the Bug Triage wiki page too?
12:18:03 <ndevos> lalatenduM: you want to add them?
12:18:13 <lalatenduM> ndevos, it is present in the wiki page
12:18:34 <ndevos> lalatenduM: I mean the untriaged + per-component urls
12:19:01 <lalatenduM> ndevos, ok will do that
12:19:14 <ndevos> ah, there is the component-less query
12:19:19 <ndevos> lalatenduM: thanks!
12:19:44 <ndevos> #action lalatenduM will add bugzilla queries (per component) to the Bug triage wiki page
12:20:13 <ndevos> lalatenduM: of course, no need to add all components, just some of the major ones
12:20:24 <lalatenduM> ndevos, yeah, agree
12:20:27 <ndevos> #topic Group Triage
12:20:44 <ndevos> well, pranith seems to be absent...
12:21:22 <ndevos> do you guys want to triage a bug together?
12:21:22 <elico> OK moved on to the next topic :D
12:21:32 <ndevos> yes ;)
12:21:36 <elico> yes
12:21:39 <hagarth> yes
12:22:09 <ndevos> I suggest we'll pick a bug taht is filed for glusterd
12:22:11 <lalatenduM> yes
12:22:20 <elico> OK
12:22:32 <ndevos> many users file bugs against glusterd, and they often tend to be for an other component
12:22:41 <ndevos> so, open this bugzilla query: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS&f1=keywords&o1=nowords&v1=Triaged&component=glusterd
12:22:52 <elico> in
12:23:05 <elico> lots of them(64)
12:23:17 <lalatenduM> lets take a recent one
12:23:38 <ndevos> yes, quite a lot of them, someone post a number we should look at
12:23:50 <lalatenduM> what abt https://bugzilla.redhat.com/show_bug.cgi?id=1109613
12:23:51 <glusterbot> Bug 1109613: urgent, unspecified, ---, kparthas, NEW , gluster volume create fails with ambiguous error
12:24:13 <ndevos> sure, any of the listed ones should be good
12:24:38 <elico> ok
12:24:55 <ndevos> lalatenduM: you want to go through it?
12:25:06 <lalatenduM> ndevos, sure
12:25:32 <lalatenduM> regarding the summery of the bug? it looks fine to me
12:25:42 <lalatenduM> i.e. gluster volume create fails with ambiguous error
12:26:19 <lalatenduM> the component is also correct i.e. glusterd
12:27:07 <lalatenduM> it is assigned Krishnan, not sure if he is the rigjt guys, so need to check who assigned to him
12:27:07 <elico> well it stated in the bugs that the directory does not exists... If I am right.
12:27:47 <kkeithley> hagarth assigned it.
12:28:02 <elico> or some directory..
12:28:04 <lalatenduM> ohh :) then it has to be correct :)
12:28:07 <ndevos> lalatenduM: the assignee of a bug in NEW is unimportant, it only is assigned when the bug is in ASSIGNED state
12:28:32 <ndevos> elico: what error message are you referring to?
12:28:42 <lalatenduM> ndevos, right, it should be in assigned state
12:28:51 <elico> " [2014-06-14 15:16:30.470704] D [glusterd-utils.c:620:glusterd_check_volume_exists] 0-management: Volume devroot does not exist.stat failed with errno : 2 on path: /var/lib/glusterd/vols/devroot "
12:29:01 <elico> unsure on what it states..
12:29:13 <lalatenduM> The description is also not very clear
12:29:38 <elico> well the steps to reproduce are kind of exact.
12:29:40 <lalatenduM> it should have details like what kind of partition being used , xfs or ext4
12:29:54 <lalatenduM> may be "df -h" out put have helped
12:30:03 <ndevos> elico: right, that tells us (more or less) that the directory which will contain the .vol file does not exist - which is OK, as long as it gets created
12:30:42 <ndevos> elico: the " D " bit in the log message stands for "Debug", often those are not fatal errors
12:30:53 <elico> ok thanks
12:31:13 <lalatenduM> opps, the steps to reproduce have some more info
12:32:27 <lalatenduM> I dont understand " mkdir devroot /data/brick1" in steps to reproduce
12:32:40 <lalatenduM> what is it trying to do
12:33:02 * ndevos doesnt know either
12:33:19 <elico> it means "mkdir /data/brick1/devroot"
12:33:27 <ndevos> what would be the next step to get this bug in a state where a dev can work on it?
12:33:30 <lalatenduM> elico, yeah thats right
12:34:05 <lalatenduM> ndevos, I think we need glusterd logs
12:34:17 <elico> but just to make sure a "ls -ld /data/brick1/devroot" would have helped to make sure he did it right :\
12:35:01 <elico> the getarrt states that it exists..
12:35:07 <lalatenduM> also we need to know if selinux is enabled or iptable rules are set correctly, as it look like more of a setup issue to me
12:35:08 <ndevos> right, at least those two points: 1. glusterd logs, 2. mountpoint of the brick(s)
12:35:34 <ndevos> lalatenduM: yes, can be
12:36:31 <ndevos> note that there already was a request from Atin, and the reporter did not respond
12:36:50 <ndevos> but, yes, lalatenduM, can you request the details from the reporter?
12:37:03 <elico> so "df -h;iptables -L;sestatus"
12:37:36 <ndevos> lalatenduM: maybe also ask if the problem still occurs, or if it has been solved already
12:37:49 <lalatenduM> ndevos, ok,
12:38:11 <ndevos> #action lalatenduM requests iptables, df, SElinux and logs for bug 1109613
12:38:12 <glusterbot> Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1109613 urgent, unspecified, ---, kparthas, NEW , gluster volume create fails with ambiguous error
12:38:31 <ndevos> an other bug?
12:38:48 <lalatenduM> after putting all questions, will add triaged keyword to it
12:39:11 <elico> ok seems reasonable.
12:39:17 <lalatenduM> ndevos, here is the one I was triaging
12:39:19 <lalatenduM> https://bugzilla.redhat.com/show_bug.cgi?id=1136349
12:39:20 <glusterbot> Bug 1136349: high, high, ---, spalai, NEW , 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:40:33 <ndevos> lalatenduM: hmm, thats an ugly bug. the person who filed it made the initial comments private, non Red Hat folks can not read it
12:41:44 <lalatenduM> ndevos, right, what to do in this situation hagarth ^^
12:41:51 <ndevos> lalatenduM: and a patch has been posted, if it is only one patch, the bug should be in POST, if additional patches are needed, it should be in ASSIGNED
12:42:16 <lalatenduM> ndevos, right
12:42:19 <hagarth> lalatenduM: I suggest that a summary of the issue be posted as a public comment
12:42:33 <lalatenduM> hagarth, make sense
12:42:37 <lalatenduM> agree
12:42:38 <jdarcy> I think in these cases we need to push back on the submitter to provide a public "abstract" as well as the private details
12:43:01 <jdarcy> Unfortunately, AFAIK the details need to be private if they include information e.g. about internal tests or systems.
12:43:09 <kkeithley> If there's nothing in the comment, i.e. no customer data, we can just make it a non-private comment
12:43:23 <hchiramm> lalatenduM, comments can be made public
12:43:50 <lalatenduM> hchiramm, right, but it would be right if the original reporter make it public
12:44:05 <kkeithley> I don't think we care about our own machine names.  Customer's machine names yes; ours, no.
12:44:07 <lalatenduM> after making sure it does not have customer info
12:44:07 <ndevos> I prefer asking the reporter to either: a. make the private comments public, or b. post a summary that explains the issue/situation
12:44:17 <lalatenduM> ndevos, yup
12:44:20 <kkeithley> ndevos: +1
12:44:26 <lalatenduM> i am going to do that
12:44:28 <elico> ndevos: +1
12:45:03 <ndevos> #action 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:45:04 <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:45:04 <hchiramm> lalatenduM, we can place a 'NEEDINFO  for requesting it
12:45:16 <lalatenduM> hchiramm, yes, I am going to do that
12:45:21 <hchiramm> ok..
12:45:46 <lalatenduM> Also we need to know if the issue applicable to 3.6 ,3.5 and 3.4 release branch
12:45:56 <jdarcy> That particular private comment is also a roll-up of an entire history for the bug it was cloned from, including things like account changes.  :(
12:45:56 <ndevos> lalatenduM: oh, and ask if it is only one patch (-> POST) or more patches (-> ASSIGNED)
12:45:58 <lalatenduM> the patch is for master
12:46:10 <lalatenduM> ndevos, agree
12:46:33 <jdarcy> lalatenduM: I've seen some email about this one.  From what I understand of the root cause, it's applicable to other releases as well.
12:47:09 <lalatenduM> jdarcy, I too think the same
12:47:13 <ndevos> jdarcy: yeah, cloning just like that isnt very helpful, stripping useless bits out of it, and removing references to customers/internal-systems should be a standard procedure
12:48:20 <jdarcy> ndevos: Most of it should even be scriptable.  Some comments on the parent bug are *obviously* useless in the child.
12:48:30 <elico> * BB Soon
12:48:38 <ndevos> #idea we should create a "how to clone" best practises wiki page if we do not have one yet
12:48:53 <jdarcy> +1 to that idea
12:49:00 <lalatenduM> ndevos, we have a section for this in triage wiki page
12:49:10 <hagarth> ndevos #radical idea .. move to launchpad so that cloning is not possible
12:49:25 <lalatenduM> hagarth, lol :)
12:49:31 <lalatenduM> http://www.gluster.org/community/documentation/index.php/Bug_triage#Bugs_present_in_multiple_Versions
12:49:37 <ndevos> hagarth: I dont think hchiramm like that idea :D
12:50:01 <ndevos> lalatenduM: maybe we should split that page into smaller ones
12:50:07 <hchiramm> :D
12:50:11 <hagarth> :)
12:50:19 <lalatenduM> :), I knew this is coming
12:50:36 <lalatenduM> ndevos, we can do that :)
12:51:01 <ndevos> lalatenduM: you want to go that, or do we give hchiramm something to work on?
12:51:16 <lalatenduM> ndevos, I will vote for hchiramm :)
12:51:47 * hchiramm elected as president
12:51:48 <ndevos> #action hchiramm will split the Bug Triage page into smaller ones, starting with a "How to clone" best practise
12:52:14 <hchiramm> slip++
12:52:16 <glusterbot> hchiramm: slip's karma is now 1
12:52:32 <ndevos> lalatenduM: I guess you've got enough details for that bug?
12:52:38 <lalatenduM> ndevos, yes
12:52:57 <ndevos> good
12:53:07 <jdarcy> AFAICT the initial report for that bug doesn't contain anything more sensitive than internal system names.  Any objections if I copy 'n' paste *that part* into a new public comment?
12:53:08 <ndevos> any other bug for collective triage?
12:53:22 <kkeithley> jdarcy: go for it
12:53:37 <lalatenduM> jdarcy, I am ok with it
12:53:57 <hagarth> jdarcy: +1
12:54:39 <ndevos> well, if there is not an other bug soon, we're running out of time :)
12:54:39 <kkeithley> meta: timecheck, five minutes
12:54:59 <ndevos> #topic Open Floor
12:55:11 <ndevos> any other topics to discuss?
12:55:22 <hagarth> ndevos: should we have a list of recent bugs to triage?
12:55:23 <kkeithley> bug triage related!
12:55:28 <lalatenduM> jdarcy, the original bug has all public comments, it should also have
12:55:29 <hagarth> in this meetings i mean
12:55:31 <hchiramm> hagarth+1
12:55:36 <lalatenduM> https://bugzilla.redhat.com/show_bug.cgi?id=969020
12:55:37 <glusterbot> Bug 969020: high, high, RHS 3.1.0, vsomyaju, ASSIGNED , 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:55:52 <ndevos> hagarth: we can, how recent do you want it?
12:56:14 <hagarth> ndevos: the previous week?
12:56:15 <hchiramm> ndevos, better to start from past
12:56:35 <hagarth> to ensure that we at least triage the incoming ones
12:56:42 <ndevos> hagarth: sure, we can do that
12:56:50 <lalatenduM> hagarth =1
12:56:58 <lalatenduM> I mean +1
12:56:59 <hchiramm> Isnt it good to close old bugs first ?
12:57:08 <ndevos> #action ndevos to add a bugzilla query with untriaged bugs that have been filed in the last week
12:57:17 <lalatenduM> hchiramm, there are so many
12:57:20 <hagarth> hchiramm: we can also chose to pick up some subset of bugs from the backlog
12:57:24 <elico> here
12:57:46 <ndevos> we should triage old bugs too, but the triage time isnt limited to this meeting!
12:57:47 <hchiramm> I thought we should clear the backlog somehow
12:57:56 <jdarcy> Can/should we use a tag to identify candidates for group triage?
12:58:17 <ndevos> jdarcy: not sure, but you can add them to the agenda
12:58:21 <jdarcy> So a bug can either go from untriaged either to triaged (by one person) or recommended to the group.
12:58:28 <hagarth> jdarcy: yes, I think ndevos will circulate BZ urls for triaging
12:58:55 <hagarth> hchiramm: yes, we need to plan a strategy for backlog
12:59:01 <ndevos> jdarcy: hmm, what about setting NEEDINFO for the gluster-bugs@redhat.com address?
12:59:15 <hchiramm> hagarth, yep
12:59:19 <jdarcy> ndevos: Either that or something in the whiteboard
12:59:41 <hagarth> ndevos: it could be all bugs with created < 1w and whiteboard not containing 'Triaged'
12:59:48 <hagarth> or some equivalent of the above
12:59:52 <ndevos> jdarcy: I prefer the needinfo
13:00:26 <ndevos> hagarth: yeah, its not too difficult to get that (Triaged is a "Keyword", not whiteboard)
13:00:34 <hagarth> ndevos: right
13:01:06 <hagarth> need to drop off now, thanks ndevos!
13:01:15 <ndevos> #idea if you need a bug triaged by the group during this meeting, set NEEDINFO for gluster-bugs@redhat.com
13:01:19 <ndevos> hagarth: cya!
13:02:01 <ndevos> #action ndevos to create a bugzilla query to list the NEEDINFO gluster-bugs@redhat.com for group triage
13:02:23 <ndevos> anyone wants the AI to update the wiki page with this NEEDINFO option?
13:02:46 <lalatenduM> ndevos, will do it
13:03:18 <ndevos> #action lalatenduM will update the Bug Triage page to mark bugs for group triage (NEEDINFO on gluster-bugs@redhat.com)
13:03:22 <ndevos> lalatenduM: thanks!
13:03:38 <ndevos> that seems to be it for this week
13:03:48 <ndevos> I'll send meeting minutes later today
13:03:56 <hchiramm> thanks.. bye
13:04:03 <ndevos> if theer is anything missing, let me know :)
13:04:06 <hchiramm> ndevos, btw doc component is already in process
13:04:06 <ndevos> #endmeeting