12:02:27 <ndevos> #startmeeting
12:02:27 <zodbot> Meeting started Tue Aug 26 12:02:27 2014 UTC.  The chair is ndevos. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
12:02:32 <ndevos> the agenda for this Bug Triage meeting can be found here: https://public.pad.fsfe.org/p/gluster-bug-triage
12:02:35 <ndevos> #topic Roll Call
12:02:39 * kshlm is here!
12:02:43 * kkeithley_ is here
12:02:49 * pranithk is here
12:02:52 * hchiramm_ here
12:03:47 <ndevos> well, thats 4 + me, okay
12:04:01 <ndevos> #topc Any questions about why we need regular bug triage?
12:04:04 <ndevos> #topic Any questions about why we need regular bug triage?
12:04:20 <ndevos> did everyone read http://supercolony.gluster.org/pipermail/gluster-users/2014-August/018488.html ?
12:04:46 <kshlm> Yes. And I have no questions.
12:05:09 <hchiramm_> ndevos, if not , we wont be here I think :P
12:05:12 * hchiramm_ hiding
12:05:20 <ndevos> okay, good, others seem to stay quiet, I guess its clear why we want bug triage :D
12:05:29 <ndevos> #topic Any questions about the triage guidelines?
12:05:49 <ndevos> the triage guidelines from http://www.gluster.org/community/documentation/index.php/Bug_triage are clear to everyong?
12:06:04 <ndevos> who did read that page?
12:06:31 * kshlm is reading it now.
12:07:02 * pranithk reading now
12:07:02 <ndevos> kshlm: thanks for being open about it :)
12:07:45 <hchiramm_> ndevos, I think its better if we can include a filter URL for different GlusterFS version bugs
12:07:48 <hchiramm_> we have NEW there
12:08:10 <hchiramm_> but better if we can include the list for releases as well
12:08:12 <pranithk> does anyone know why new afr bugs are not assigned to me by default? :-(
12:08:29 <hchiramm_> the default assignee list is not changde
12:09:05 <ndevos> pranithk: because we do not want *you* to triage on all those bugs?
12:09:56 * lalatenduM is here
12:10:05 <ndevos> pranithk: you should probably have a bookmark that shows all afr bugs and that have the Triaged keyword set
12:11:47 * lalatenduM is reading msgs till now
12:11:49 <pranithk> ndevos: I need to see all bugs on afr
12:12:14 <ndevos> pranithk: all NEW bugs, or *all*?
12:12:35 <ndevos> pranithk: NEW bugs: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&keywords_type=anywords&product=GlusterFS
12:12:53 <ndevos> oh, even this works: https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW&product=GlusterFS
12:13:05 <kshlm> I think he wants notifications on new AFR bugs.
12:13:08 <ndevos> uh, add &component=afr
12:13:40 <ndevos> kshlm: notification is different, but we can do that too - although its not documented in the wiki yet
12:14:20 <ndevos> hchiramm_: did you request/create a replacement for gluster-bugs@redhat.com?
12:14:37 <hchiramm_> not yet
12:14:57 <hchiramm_> did we confirm on component maintainers ?
12:15:19 <pranithk> ndevos: but as soon as the bug is raised I used to get a main in inbox because I used to be CCed. As I am the default Assignee of replicate bugs
12:15:25 <pranithk> ndevos: Now it is not the case :-|
12:15:31 <ndevos> #action hchiramm_ to create/request a bugs@gluster.org mailinglist and have it as default assignee of any Gluster product bug
12:15:35 <pranithk> ndevos: *mail*
12:15:50 <kshlm> pranithk, I think you can be added to default cc list.
12:15:51 <pranithk> ndevos: great!
12:16:08 <lalatenduM> yeah mail notification will help
12:16:26 <kshlm> pranithk, you can also setup bugzilla alerts ( I can't remeber what its called though)
12:16:28 <hchiramm_> ndevos I am not sure whether we want to do that
12:16:33 <ndevos> pranithk: you can follow (in Bugzilla) the gluster-bugs@redhat.com user, that (fake) user gets all the email, when you follow it, you get them too
12:17:10 <ndevos> pranithk: you can then filter on X-Bugzilla-* headers in the email to delete/sort/... specific comonents/status/.. etc
12:17:19 <pranithk> ndevos: Hmm...
12:17:36 <hchiramm_> if we have component maintainers list, we can request to change the default assignee to those per component and keep gluster-bugs@ in Cc list..
12:17:45 <pranithk> hchiramm_: +1
12:17:57 <ndevos> pranithk: https://bugzilla.redhat.com/userprefs.cgi?tab=email -> user watch list on the bottom of the page
12:18:22 <lalatenduM> hchiramm_, +1
12:18:28 <pranithk> ndevos: Can't we have something similar to what hchiramm_ is suggesting?
12:18:44 <ndevos> hchiramm_: that would be possible, but we also want anyone from the community that helps with triaging to get emails about new afr bugs
12:19:04 <pranithk> ndevos: Since gluster-bugs is Cced they would I guess?
12:19:21 <ndevos> hchiramm_: I think keeping the list of maintainers is in bugzilla is quite some work?
12:19:22 <kshlm> I'd prefer the opposite. Let the default assignee be gluster-bugs but component owners be in the cc list.
12:19:41 <hchiramm> kshlm, that also works
12:19:43 <kkeithley_> lshlm +1
12:19:48 <kkeithley_> kshlm +1
12:20:06 <lalatenduM> kshlm, +1, this is better
12:20:22 <pranithk> kshlm: Hmm... I guess that works too
12:20:50 <ndevos> okay, so, default gluster-bugs@redhat.com (until hchiramm has a list) and add maintainers of components to CC?
12:21:19 <ndevos> #agreed default gluster-bugs@redhat.com (until hchiramm has a list) and add maintainers of components to CC
12:21:27 <hchiramm> will do
12:21:48 <kshlm> BTW I thought gluster-bugs@redhat.com was a list. Isn't it?
12:21:54 <ndevos> and the maintainers should be like the MAINTAINERS file in the sources?
12:22:13 <hchiramm> ndevos, I doubt.
12:22:27 <ndevos> kshlm: yes, but a red hat internal one, so not very usable - except for the 'user watch' option in bugzilla
12:22:46 <hchiramm> because currently the list of components are really micro level I feel
12:23:12 <hchiramm> we dont list maintainers that level in MAINTAINERS file
12:23:26 <kshlm> Oh, I'd forgotten that. Could'nt we just create a @gluster.org mailing list then?
12:23:27 <ndevos> hchiramm: yeah, thats the point, maybe MAINTAINERS should reflect the CC in Bugzilla too?
12:23:43 <ndevos> kshlm: hchiramm is already taske with that :)
12:23:45 <hchiramm> what we can do here is, revisit the component list
12:24:00 <hchiramm> and consolidate if possible
12:24:35 <kshlm> hchiramm, I agree. The component list is too big right now.
12:24:39 <ndevos> hchiramm: I dont really care how it's done, but if we talk about maintainers, it should be clear who we mean
12:25:21 <hchiramm> kshlm, yep. otherwise its difficult to maintain
12:25:32 <ndevos> hchiramm: MAINTAINERS is what community members will see, and I dont think there is an advantage if that file differs from the list in Bugzila
12:25:52 <hchiramm> ndevos, thats what we were saying :)
12:26:16 <ndevos> hchiramm: you want to reduce/merge the two>
12:26:17 <ndevos> ?
12:26:30 <hchiramm> no ..
12:26:37 * ndevos has a new laptop, and needs to get used to the keyboard
12:27:02 <hchiramm> we need to make sure the number of components listed under product GlusterFS should tally to the maintainers file components
12:27:21 <hchiramm> if u look @ " Is it assigned to correct component of GlusterFS? " in http://www.gluster.org/community/documentation/index.php/Bug_triage section
12:27:50 <hchiramm> u can see lots of components .
12:27:52 <ndevos> yeah, that list is huge
12:28:14 <lalatenduM> yeah , the list is huge
12:28:32 <hchiramm> so somehow we have to consolidate the bugzilla component list
12:28:37 <hchiramm> then confirm the maintainers
12:28:49 <hchiramm> in Cc list
12:29:02 <ndevos> any volunteer to reduce/merge the bugzilla component list and the MAINTAINERS file in the sources?
12:30:00 <ndevos> kshlm, pranithk, kkeithley_?
12:30:19 <ndevos> (and a "no" is fine)
12:30:28 <lalatenduM> ndevos, lets postpone this work for later
12:30:33 <kkeithley_> only if nobody else wants to...
12:30:42 <ndevos> kkeithley_: same here :)
12:31:03 <ndevos> #help we need a volunteer to reduce/merge the bugzilla component list and the MAINTAINERS file in the sources
12:31:03 <lalatenduM> I think a mailing list thing should be ok to start bug triage
12:31:19 <pranithk> lalatenduM: agreed
12:31:38 <ndevos> lalatenduM: yes, that is a start, and we'll see what components we can drop from there
12:31:58 <lalatenduM> ndevos, agree
12:32:11 <hchiramm> btw we need to add one more component to the list :)
12:32:19 <pranithk> ndevos: The problem is there a quite a few components without any owner. People change them as they please and if it gets +1, +2 they get merged...
12:33:13 <ndevos> pranithk: yes, but I hope maintainers of a component have an email notification setup in Gerrit and get emails about new patches?
12:33:44 <ndevos> anyway, except for the question on how to get notified on new *bugs* , are there any questions on the triage process/guidelines?
12:34:36 <lalatenduM> do we really need separate components for each xlator? in future we will have more xlator . I hope we will be able to maintain the list then too
12:35:00 <pranithk> ndevos: none for now from me
12:35:05 <kshlm> I don't have any again. The triage doc was well written.
12:35:09 <hchiramm> may be component MAINTAINERS can look into current component list and suggest how we can shrink those
12:35:11 <kshlm> lalatenduM++
12:35:12 <glusterbot> kshlm: lalatenduM's karma is now 1
12:35:30 <hchiramm> ndevos, ^^^
12:36:12 <ndevos> hchiramm: yes, some components from Bugzilla can probably get grouped together and be added/corrected in the MAINTAINERS file
12:36:16 <lalatenduM> kshlm, thnaks, is it  for bug triage doc?
12:36:24 <kshlm> yup.
12:36:28 <lalatenduM> :)
12:36:29 <kkeithley_> wrt lalatenduM's comment.... I had proposed a single xlator component and various subcomponents, e.g. afr, stripe, dht, etc.
12:37:05 <kshlm> If sub-components are possible, then +1 to kkeithley_s plan from me.
12:37:25 <lalatenduM> kkeithley_, +1
12:37:35 <ndevos> kkeithley_: for major xlators it definitely makes sense, but maybe not for all? /me thinks about performance/debugging xlators
12:38:00 <hchiramm> yep. I do think the same way
12:38:39 <ndevos> #agreed we'll need bugzilla components and entries in MAINTAINERS for major xlators, but probably not for all
12:39:16 <pranithk> kkeithley_: Are you saying afr needs to be sub component?
12:40:19 <ndevos> I'm not sure if sub-components really are very useful, almost all funciotionality is in an xlator?
12:40:26 <lalatenduM> pranithk, yeah component  should be xlator and sub-comp should be afr . But sure how difficult it would be to implement
12:40:36 <lalatenduM> in bugzilla
12:40:53 <pranithk> lalatenduM: So now we want users to know there is a concept called xlator?
12:40:57 <ndevos> lalatenduM: bugzilla supports that already, it's done at least for the kernel package in RHEL
12:41:32 <pranithk> lalatenduM: It is easier for people with functionality name based components like distribute/replication/locks etc etc...
12:41:34 <lalatenduM> pranithk, hmmm, I thought they know it if they know afr :)
12:41:53 <lalatenduM> pranithk, yup agree
12:41:54 <pranithk> lalatenduM: On bugzilla it is called replication not afr...
12:42:11 <pranithk> lalatenduM: So people just file it there when something is not replicating/self-healing etc...
12:42:34 <pranithk> lalatenduM: So I believe it will be difficult for new people to understand where to file the bug...
12:42:36 <lalatenduM> pranithk, I agree , replication is user friendly
12:42:45 <ndevos> #info it is possible to create sub-components in Bugzilla and groups xlators that way, but it should be user-friendly
12:42:54 <hchiramm> pranithk, for every component there is a description
12:42:57 <pranithk> lalatenduM: So may be we should not do this xlator/sub-component for now IMO again
12:43:11 <hchiramm> if we need we can change those descriptions in a better user friendly manner
12:43:37 <lalatenduM> pranithk, agree we need more user friendly names than xlator/sub-component
12:43:52 <lalatenduM> ndevos, ok
12:44:18 <ndevos> #agreed the general triage guidelines on http://www.gluster.org/community/documentation/index.php/Bug_triage look good and should be workable
12:45:02 <ndevos> #action ndevos to describe how to 'watch' gluster-bugs@redhat.com and filter email
12:45:25 <ndevos> anything else related to the bug triage guidelines?
12:45:31 <hchiramm> #action hchiramm to create "doc" component under GlusterFS in bugzilla
12:45:53 <ndevos> hchiramm: and maybe website?
12:45:53 <lalatenduM> ndevos, are you planning to add " ndevos to describe how to 'watch' gluster-bugs@redhat.com and filter email" to soemwhere in wiki
12:46:04 <hchiramm> ndevos, sorry , didnt get
12:46:10 <ndevos> lalatenduM: yes
12:46:18 <lalatenduM> ndevos, nice
12:46:23 <ndevos> hchiramm: a component in bugzilla for the website?
12:46:36 <hchiramm> ahhhhh.. required ?
12:46:47 <kkeithley_> pranith: I'm saying that all the various xlator components we have today would go away and be replaced with a single xlator component. And the xlator component in bugzilla would have subcomponents like afr, dht, distribute, ec, and so on.
12:46:56 <kkeithley_> That
12:46:58 <ndevos> hchiramm: not sure, but it may help in tracking corrections/issues/...
12:47:09 <kkeithley_> That's only a suggestion. I don't feel strongly that we have to do that
12:47:11 <hchiramm> ndevos, hmmmmmm. make sense
12:47:26 <hchiramm> kkeithley++ I do think thats better
12:48:01 <ndevos> kkeithley_, hchiramm: a word like "xlator" is not very user-friendly, do our users know what a xlator is?
12:48:03 <hchiramm> but then I am not sure our Cc list work for sub components
12:48:06 <hchiramm> kkeithley_,
12:48:08 <pranithk> kkeithley_: At the moment I feel it would be difficult for new users because lot of new people don't know what afr means. They just log bugs on replicate...
12:48:30 <hchiramm> ndevos, again we have a description field :)
12:48:48 <ndevos> hchiramm: it still makes filing a bug more work
12:48:49 <kkeithley_> we don't have to use "xlator". I'd be perfectly happy with another word
12:49:07 <hchiramm> same here :)
12:49:52 <ndevos> but well, this discussion is all theoretical, we need a volunteer to propose a component-list and updated MAINTAINERS file
12:50:31 <ndevos> next topic?
12:50:55 <ndevos> #topic Triage by example
12:51:15 <ndevos> nobody added any bugs to the etherpad/agenda, so I guess we dont need exampled?
12:51:23 <ndevos> *exampled
12:51:23 <ndevos> argh
12:52:23 <ndevos> well, if you need an example, or have a particular weird bug that you want to triage, let us know :)
12:52:30 <ndevos> #topic Recurrence of this meeting, and (more?) suitable time
12:52:31 <pranithk> ndevos: +1
12:52:31 <lalatenduM> ndevos, real crunch time for us :(
12:52:55 <ndevos> so, this meeting time seems to work, I did not get any direct complaints about it
12:53:12 <ndevos> how often would we need this meeting? every week, or bi-weekly?
12:53:20 <hchiramm> bi -weekly
12:53:21 <hchiramm> ?
12:53:44 <lalatenduM> ndevos, weekly in the beginning ?
12:53:47 <ndevos> I propose a meeting next week too, just because we have some action items to work out
12:53:50 <ndevos> lalatenduM: yeah
12:53:51 <lalatenduM> then bi-weekly
12:54:05 <lalatenduM> then once-in month
12:54:08 <ndevos> pranithk, kshlm, kkeithley_: any opinion?
12:54:22 <pranithk> ndevos: What will we be doing in the meeting? Triaging itself?
12:54:34 <kkeithley_> +1 for weekly to start, then bi-weekly
12:54:47 <lalatenduM> yeah we should triage bugs during the meeting
12:54:48 <ndevos> pranithk: we can, and improve the triage guidelines
12:55:17 <ndevos> #action ndevos to schedule a meeting for next week again
12:55:20 <lalatenduM> if we triage bugs during meeting , it would be more interesting I think
12:55:31 <lalatenduM> what do you guys think?
12:55:38 <ndevos> #item next weeks meeting will be used to triage meeting too
12:55:50 <pranithk> lalatenduM: I generally like to do it as soon as I get the mail (best possible scenario) but once a week is fine too I guess
12:56:07 <ndevos> pranithk: please triage as soon as you get mail :)
12:56:26 <kkeithley_> lalatenduM: +1, yes, let's use the meetings to get the existing bugs under control, then revisit doing triage by mail
12:56:34 <ndevos> we'll see what bugs are in NEW and do not have the Triaged keyword in next weeks meeting
12:56:43 <pranithk> ndevos: That is the problem. I am not getting mail :-(
12:56:55 <pranithk> ndevos: someone changed settings :-(
12:57:10 <ndevos> pranithk: we'll get that fixed, somehow
12:57:12 <pranithk> ndevos: I am not the default owner. So I don't get any mails now :-(
12:57:15 <pranithk> ndevos: yeah!
12:57:18 <lalatenduM> pranithk_the_one_man_army++
12:57:20 <glusterbot> lalatenduM: pranithk_the_one_man_army's karma is now 1
12:57:32 <ndevos> #action ndevos to prepare some bugzilla queries that show untriaged bugs per component(-group)
12:57:32 <lalatenduM> pranithk, ^^
12:57:46 <pranithk> lalatenduM: too much!
12:57:49 <lalatenduM> :)
12:58:34 <ndevos> #topic Open Floor
12:58:35 <kshlm> You can setup bugzilla whines (I remembered what its called) on searches.
12:59:06 <ndevos> kshlm: yeah, those are timed/daily emails
12:59:25 <ndevos> any last minute topics that did not land on the etherpad?
12:59:36 <pranithk> ndevos: none from e
12:59:36 <pranithk> me
12:59:40 <lalatenduM> ndevos, none from me
13:00:01 <lalatenduM> ndevos, ok I have one question
13:00:13 * ndevos almost ended the meeting...
13:00:17 <lalatenduM> how do we find out how many bugs are getting triaged in a week
13:00:25 * pranithk gotta leave now.. cya folks
13:00:30 <ndevos> cya pranithk
13:00:34 <lalatenduM> does anyone have a query
13:00:47 <ndevos> lalatenduM: I dont know, I guess it is possible to get that from bugzilla
13:01:05 <lalatenduM> ndevos, ok
13:01:38 <ndevos> #help lalatenduM would like to know how many bugs are getting triaged in a week - does bugzilla provide these stats?
13:01:50 <ndevos> lalatenduM: noted in the minutes, maybe someone can help you out
13:01:58 <ndevos> #endmeeting