Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2016-10-18

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:02 Alghost joined #gluster-dev
00:21 luizcpg joined #gluster-dev
00:31 Alghost joined #gluster-dev
00:56 skoduri joined #gluster-dev
01:21 k4n0 joined #gluster-dev
02:35 mchangir|gone joined #gluster-dev
02:54 George joined #gluster-dev
02:59 Alghost joined #gluster-dev
03:04 k4n0 joined #gluster-dev
03:13 magrawal joined #gluster-dev
03:39 nbalacha joined #gluster-dev
03:46 Alghost joined #gluster-dev
03:52 hgowtham joined #gluster-dev
04:03 itisravi joined #gluster-dev
04:19 atinm joined #gluster-dev
04:30 shubhendu joined #gluster-dev
04:33 jiffin joined #gluster-dev
04:42 ankitraj joined #gluster-dev
04:42 sanoj joined #gluster-dev
04:43 Alghost_ joined #gluster-dev
04:49 Alghost joined #gluster-dev
04:51 rafi joined #gluster-dev
05:01 ndarshan joined #gluster-dev
05:05 karthik_us joined #gluster-dev
05:06 ppai joined #gluster-dev
05:08 ashiq joined #gluster-dev
05:10 kotreshhr joined #gluster-dev
05:15 Muthu_ joined #gluster-dev
05:29 kotreshhr joined #gluster-dev
05:30 anrao_ joined #gluster-dev
05:36 aravindavk joined #gluster-dev
05:43 anrao_ joined #gluster-dev
05:48 anrao joined #gluster-dev
05:48 kdhananjay joined #gluster-dev
05:49 devyani7_ joined #gluster-dev
05:51 devyani7 joined #gluster-dev
05:56 asengupt joined #gluster-dev
06:01 Bhaskarakiran joined #gluster-dev
06:04 itisravi joined #gluster-dev
06:06 hchiramm joined #gluster-dev
06:16 msvbhat joined #gluster-dev
06:23 pranithk1 joined #gluster-dev
06:32 Muthu_ joined #gluster-dev
06:39 hchiramm joined #gluster-dev
06:39 hchiramm joined #gluster-dev
06:42 msvbhat joined #gluster-dev
06:48 apandey joined #gluster-dev
06:51 Debloper joined #gluster-dev
06:57 hchiramm joined #gluster-dev
07:04 Alghost_ joined #gluster-dev
07:13 sac joined #gluster-dev
07:17 kdhananjay nigelb: netbsd test run failed on one of my patches with a core dump. I tried accessing the archived build, logs and core from this particular run and I get a '404 Not Found' error. Could you help me with this?
07:17 [o__o] joined #gluster-dev
07:17 kdhananjay nigelb: Here's the console output: https://build.gluster.org/job/n​etbsd7-regression/1065/console
07:18 kdhananjay nigelb: And the link to the archive at the bottom of this page - http://nbslave7g.cloud.gluster.org/archives/ar​chived_builds/build-install-20161018075703.tgz
07:23 Saravanakmr joined #gluster-dev
07:25 ndevos pranithk1, aravindavk: could you please fix the status of the 3.9 bugs? many of them should in ON_QA/fixe-in-version=glusterfs-3.9rc1
07:34 devyani7 joined #gluster-dev
07:35 anrao_ joined #gluster-dev
07:41 nigelb kdhananjay: remove the initial /archives
07:41 nigelb kdhananjay: http://nbslave7g.cloud.gluster.org/archive​d_builds/build-install-20161018075703.tgz will work.
07:43 hchiramm_ joined #gluster-dev
07:53 atinm joined #gluster-dev
08:03 ndevos kkeithle: they are backported, but 3.7 is the first release that has them
08:04 Alghost joined #gluster-dev
08:05 ankitraj joined #gluster-dev
08:07 ankitraj joined #gluster-dev
08:09 ndevos nigelb: was/is there an issue with the freebsd-smoke builder? I just got a Jenkins stackdump at https://build.gluster.org/job​/freebsd-smoke/17860/console
08:10 nigelb seems to be a network interrupt.
08:10 ndevos well, https://build.gluster.org/computer​/freebsd0.cloud.gluster.org/builds looks ok now, I'll just retrigger
08:10 nigelb I'll check if it's an interrupt from our DC side or Rackspace side.
08:11 rraja joined #gluster-dev
08:11 rafi2 joined #gluster-dev
08:27 Alghost joined #gluster-dev
08:35 kdhananjay nigelb: that worked. thanks!
08:35 kdhananjay nigelb++
08:35 glusterbot kdhananjay: nigelb's karma is now 32
08:50 anrao nigelb: had a query wrt gluster benchmarking project
09:07 magrawal nigelb, ping
09:08 Alghost_ joined #gluster-dev
09:32 nigelb anrao: sure, give me a second. I was afk.
09:32 nigelb magrawal: pong?
09:33 anrao nigelb: sure, thanks
09:34 magrawal nigelb, i am getting abort without any error at the time of running net-bsd regression https://build.gluster.org/job/n​etbsd7-regression/1061/console, do u have any idea what could be the reason of this?
09:36 nigelb magrawal: looks like something in that particular test is hanging.
09:36 nigelb Not an infra issue, that much I can tell in confidence.
09:37 magrawal nigelb, ok,thanks
09:43 anrao_ joined #gluster-dev
09:52 anrao joined #gluster-dev
09:52 ppai joined #gluster-dev
10:11 Alghost joined #gluster-dev
10:15 pranithk1 joined #gluster-dev
10:22 bfoster joined #gluster-dev
10:26 decay joined #gluster-dev
10:29 bfoster joined #gluster-dev
10:38 msvbhat joined #gluster-dev
10:49 hchiramm joined #gluster-dev
11:08 msvbhat joined #gluster-dev
11:12 kshlm ndevos, nigelb, Could one you merge this https://github.com/gluster/gluster​fs-patch-acceptance-tests/pull/64
11:13 kshlm It's a simple change to the gd2 centos-ci job. I could merge it myself if there are no objections.
11:15 ndevos kshlm: looks good to me - merged
11:15 kshlm ndevos, Thanks.
11:16 kshlm ndevos, I've merged your PR to the nightly-rpms job.
11:16 ndevos kshlm: ah, thanks!
11:26 atinm joined #gluster-dev
11:47 ppai joined #gluster-dev
11:48 anrao_ joined #gluster-dev
11:55 ashiq joined #gluster-dev
11:57 kkeithle Community Bug Triage in three minutes in #gluster-meeting
12:16 riyas joined #gluster-dev
12:30 skoduri joined #gluster-dev
12:35 ashiq joined #gluster-dev
12:36 dlambrig_ joined #gluster-dev
12:49 rafi joined #gluster-dev
12:59 atinm joined #gluster-dev
13:01 hagarth joined #gluster-dev
13:07 lpabon joined #gluster-dev
13:07 rastar joined #gluster-dev
13:08 anrao_ joined #gluster-dev
13:24 skoduri joined #gluster-dev
13:31 shyam joined #gluster-dev
13:32 Saravanakmr joined #gluster-dev
13:42 anrao_ joined #gluster-dev
13:45 skoduri joined #gluster-dev
13:58 msvbhat joined #gluster-dev
14:12 anrao_ joined #gluster-dev
14:18 ankitraj joined #gluster-dev
14:18 skoduri joined #gluster-dev
14:26 skoduri joined #gluster-dev
14:26 ankitraj joined #gluster-dev
14:29 kkeithley joined #gluster-dev
14:30 hagarth joined #gluster-dev
14:34 pranithk1 joined #gluster-dev
14:43 luizcpg joined #gluster-dev
14:43 shaunm joined #gluster-dev
14:44 anrao_ joined #gluster-dev
14:55 pranithk1 nigelb: hey need to talk to you about smoke. let me know when we can talk about it...
15:12 wushudoin joined #gluster-dev
15:12 kotreshhr joined #gluster-dev
15:15 shyam joined #gluster-dev
15:19 kdhananjay joined #gluster-dev
15:20 jiffin joined #gluster-dev
15:20 pranithk1 ndevos: What is the procedure for default assignee for components?
15:21 ndevos pranithk1: none, the team that needs to be the default assignee needs to apply notifications like everyone else
15:21 pranithk1 ndevos: why?
15:21 pranithk1 ndevos: who came up with that rule and how to change it?
15:21 ndevos pranithk1: because a default assignee is a single point of failure, and we do not want those
15:22 ndevos pranithk1: we want new community members to start triaging bugs, if someone is assigned already, new members will not do anything
15:22 ndevos pranithk1: most maintainers and developers use (or should use) https://github.com/gluster/glusterdocs/blob/mas​ter/Developer-guide/Bugzilla%20Notifications.md
15:23 pranithk1 ndevos: who came up with these rules?
15:23 ndevos pranithk1: is something not working with notifications?
15:23 pranithk1 ndevos: I like to be default assignee for the components I maintain
15:23 pranithk1 ndevos: As long as the bug is not assigned people can assume it is not being worked on
15:23 ndevos pranithk1: the bug triage team, I guess, components were not watched over, so we made it the same for everything
15:24 pranithk1 ndevos: I would like to be assigned by default if possible
15:24 ndevos pranithk1: there us an assumption that the assignee is going to take action, we can not assume that is the case, and need other people to setup notification when the assignee is not responsive
15:25 ndevos pranithk1: those notifications can be used by anyone, so there is no single point of failure
15:25 pranithk1 ndevos: People who want to triage bugs can still get the notifications but bugs without assignee even when there are designated maintainers for the components doesn't make sense to me
15:26 ndevos pranithk1: what is the advantage of being assigned? why are notifications not enough for you?
15:26 pranithk1 ndevos: I think there is already a keywork 'Triaged' which the assignee will set if he/she triages it
15:26 pranithk1 ndevos: What is the problem with assigning maintainer to be default assignee
15:27 ndevos pranithk1: most maintainers are extremely busy, and will not appreciate the additional triage work that needs to be done for new bugs, and I really doubt you have time to that as well
15:27 pranithk1 ndevos: people who want to triage can still triage the bugs following same procedure
15:27 pranithk1 ndevos: All I am asking for an additional step of assigning the maintainre
15:27 kkeithley who is going to keep default-assignee-per-component up to date?
15:28 pranithk1 kkeithley: That depends on each individual maintainer's opinion. I like it this way for the components I maintain
15:28 ndevos pranithk1: with assigning, you mean updating the assigned-to fiels and setting the bug to status=ASSIGNED?
15:28 pranithk1 ndevos: Nope, no status change, no keyword change. Just assigned should be maintainer
15:28 ndevos pranithk1: uhm, we maintain at least one component together, who gets those bugs assigned? you or me?
15:28 pranithk1 ndevos: I don't mind if the default assignee for that is me
15:29 pranithk1 ndevos: I don't want a bug to be assigned to me after 7 days (potentially) for a bug I may consider important.
15:29 ndevos pranithk1: there is no state definde for status=NEW + assignee=<someone>, those bugs are still not assigned, only when the status is updated to ASSIGNED
15:29 pranithk1 ndevos: I am not asking for process change. I just want the default assignee to be there. I want the user who logged the bug to know who to bug to get their fix in
15:30 aravindavk joined #gluster-dev
15:31 shubhendu joined #gluster-dev
15:31 ndevos pranithk1: they should be able to bug anyone, and all bugs deserve a timely response from someone, not after 7 days, but preferably the same day
15:32 pranithk1 ndevos: not everyone will be able to solve the same kind of bugs the maintainer of that component can solve
15:32 pranithk1 ndevos: It just isn't possible
15:32 ndevos pranithk1: maybe we can get nigelb to write a job that goes through bugs in NEW state and add maintainers from the MAINTAINERS file on CC?
15:33 ndevos pranithk1: we want maintainers to be utilized efficiently, I guestimate thet 90% of the bugs get reported against the wrong components, that is a lot of additional notifications for those maintainers that do currently not triage (many) bugs
15:33 pranithk1 ndevos: Sure that isn't a problem either. But I want there to be a human assignee who the user can mail to get a timely response if possible
15:34 pranithk1 ndevos: I am not asking for a generic change. I am asking for a change only for the components I maintain.
15:34 pranithk1 ndevos: I want to be assigned for those
15:34 ndevos pranithk1: I would like to address the problem a level earlier, if triage happens correctly, maintainers get put on CC, and maintaines+developers see the notifications about the bugs
15:35 ndevos pranithk1: what would be a good reason to address problems with components you maintain only, and not for all components we have?
15:35 pranithk1 ndevos: Let me ask the question this way. When you call a company you don't know, do you want to be greeted by a machine or a human?
15:35 pranithk1 ndevos: Assigning a bug to a human is different from bugs@gluster.org
15:36 pranithk1 ndevos: it just doesn't give a good outlook to the person who took the time to raise a bug
15:36 ndevos pranithk1: most companies have an automated menu, because the time needed to get redirected to the correct person?
15:36 pranithk1 ndevos: That is not the answer to my question. The question is do you want a human to answer or a machine?
15:36 ndevos pranithk1: it doesnt help if that single person can not triage all those bugs either
15:37 ndevos pranithk1: I want the most efficient path, waiting on the phone for 10 minutes and speaking to a person that redirects me is not what I want
15:37 pranithk1 ndevos: Like I mentioned, I am talking about just me and the components I maintain
15:37 pranithk1 ndevos: I am not asking for a generic process change
15:38 ndevos pranithk1: and I would like you to not need to care about incorrectly reported bugs, that is something any developer (or even contributor) can do
15:38 pranithk1 ndevos: Why do you get to make that decision on behalf of me?
15:39 ndevos pranithk1: we need to have guidelines for all components, and we have tools (like those notifications) for all of them, I would like to know why it does not work for you when it works for all others
15:40 pranithk1 ndevos: I think I mentioned, I don't like a user to be greeted by an automated assignee. If they raise a bug on components I handle, I would be greeting them.
15:41 ndevos pranithk1: and as one of the most busy maintainers we have, I do not agree that you greeting all reporters of bugs is a useful thing to you, you are needed much more in other places
15:41 pranithk1 ndevos: Again, why are you making decisions on behalf of me? Let me try. If it doesn't work for me. I will tell you and we can remove it.
15:42 ndevos pranithk1: when triaging is done upon every notification of a new bug, anyone interested in components you maintain can greet the bug reporter
15:42 ndevos pranithk1: I still do not understand why you can not use the notifications... cant you use those to greet the bug reporter?
15:43 pranithk1 ndevos: Let them greet them. I am not saying change anything with the process we do have. All I am asking for is an additional step
15:43 pranithk1 ndevos: I would like to be the assignee
15:43 pranithk1 ndevos: for the components I maintain
15:44 ndevos pranithk1: but *why* ? you still receive the notifications for all those components, and can assign the bugs to yourself if you want to work on them?
15:44 pranithk1 ndevos: I think I answered it already. What is difficult to understand?
15:45 ndevos pranithk1: what is the difference to *you* ? it may be nice for the reporter to see a person, but in the end it is about the progress a bug report makes, and when work starts, the bugs gets the developer assigned
15:46 pranithk1 ndevos: Yes, but he can mail me if he doesn't get a response in the time he feels he should
15:47 anrao_ joined #gluster-dev
15:47 pranithk1 ndevos: Quite a few people who know me on users/devel mail me in person and ask doubts. But not everyone can know who maintainer of that particular component. Who should they mail? Why do we want to burden users with an additional step of finding where the development tree is and seeing the maintainers?
15:48 ndevos pranithk1: each component should be handled by several maintainers, a reporter should be able to reach out to anyone, even if the default assignee is non-responsive for whatever reason
15:49 pranithk1 ndevos: So you are saying he must wait for 7 days no matter what? until someone adds CC?
15:49 ndevos pranithk1: when you are on holidays for a week (or two), should we update the default assignee to the other maintainers of the shared components?
15:50 ndevos pranithk1: no, triaging is an effort done by everyone working on the components, as soon as a bug is reported, people only need to configure notifications once and can reply to those new bugs
15:50 ndevos pranithk1: I'm not sure where you get 7 days from, hopefully bugs get triaged the same or next day?
15:51 pranithk1 ndevos: Really? Then why do we have weekly meetings?
15:51 ndevos pranithk1: we only do the weekly meetings because not all bugs for all components get triaged quickly enough, it is only a backup meeting
15:53 pranithk1 ndevos: Why is having a default assignee hurting the existing procedure? I think it is only adding to it?
15:53 pranithk1 ndevos: What is the problem if all it does is add an extra step to assign it to the maintainer of the component?
15:53 JoeJulian ndevos: pranithk1 is getting 7 days because on a day that you have the triage meeting, if someone reports a new bug no new bugs are triaged until the next triage meeting 7 days later.
15:54 pranithk1 ndevos: JoeJulian has an edge where he directly mailed me and We worked together to solve a problem. Granted somedays I will be on leave, but on the days I am available why should we take away the option of mailing me directly from the users?
15:55 ndevos pranithk1: a single-point-of-failure hurts scalability, specially the maintainers that are busy with more complext stuff need to be free'd up
15:55 pranithk1 ndevos: I would like to decide myself when I am free to respond and when I am not. I don't like someone else deciding it for me.
15:55 ndevos JoeJulian: that only counts for components that do not have people actively watching the notifications and acting on them
15:56 ndevos pranithk1: if you are the default assignee, the expectation of the bug reporter is that you respond to them in the next (few) day(s)
15:56 JoeJulian I lean toward agreeing with ndevos if only because you can use watches to get the notifications. Heck, you could script auto-responses if you wanted in order for the reporter to feel heard.
15:57 pranithk1 ndevos: I would like the option of having a default assignee. It is important for me. I like to give users the option of mailing me if I don't immediately respond on the bug.
15:57 ndevos JoeJulian: we use https://github.com/gluster/glusterdocs/blob/mas​ter/Developer-guide/Bugzilla%20Notifications.md for many components already, and different people act on those notifications
15:57 pranithk1 JoeJulian: The perspective is not from maintainers', it should be from users'
15:58 ndevos JoeJulian: emails, bugzilla queries and even RSS feeds are possible
15:58 pranithk1 JoeJulian: you know half the maintainers if not more. You can mail them directly if you have an urgency
15:58 pranithk1 JoeJulian: How can a user who is new know that info?
15:59 JoeJulian They can look at the MAINTAINERS file.
15:59 ndevos pranithk1: I do not see what is different from a users that asks "helloooo? any update in this bug???" in a bug report that gets received by many, or an email that gets received by a single person
16:01 ndevos pranithk1: most users will update the bug report at least a few times before getting in touch with the person that is assigned, at least that is what happens to the bugs that I get assigned to
16:01 ndevos I have to think really hard to remember a case where someone emailed me, instead of updating the bug report...
16:01 jiffin joined #gluster-dev
16:01 pranithk1 ndevos: I have quite a few cases where people emailed me directly.
16:01 ndevos maybe once for a fedora bug, but I'm not even sure about that anymore, definitely years ago
16:02 pranithk1 ndevos: I made them log bugs because they are important ones
16:02 ndevos pranithk1: I also get emails from people, but mostly not asking about certain bugs
16:02 pranithk1 ndevos: If you are happy with the process there is, that is fine. I am not, and I want it to work well for me too. And I want default assignee to be me for the components I maintain
16:02 hagarth joined #gluster-dev
16:03 pranithk1 JoeJulian: Again, in this case, you know where to look. Not everyone may know.
16:03 pranithk1 JoeJulian: I meant about MAINTAINERS file
16:03 JoeJulian Then everyone else has to get smarter. ;)
16:04 pranithk1 JoeJulian: :-).
16:04 ndevos pranithk1: can you tell me how you currently do the 1st comment in newly reported bugs, and why that would change when you are the default assignee?
16:04 JoeJulian pranithk1: What if you just write a script that watches the rss feed and assigns bugs to yourself if they match your criteria?
16:04 pranithk1 ndevos: Again, you are not even understanding my point. It is not about my convenience. It is from user's perspective
16:05 pranithk1 ndevos: When bugzilla offers that functionality why should I sweat it?
16:05 pranithk1 JoeJulian: ^^
16:05 ndevos pranithk1: I dont agree with that, if *you* reply to the newly reported bug as soon as you get the notification, users will be much more impressed than when they see your name but no reaction for a day
16:05 JoeJulian Does it? I thought it was an all-or-nothing problem.
16:06 pranithk1 JoeJulian: It has the functionality
16:06 JoeJulian From the perspective of managing infrastructure, it's better if everyone uses the same configuration.
16:06 pranithk1 ndevos: If you don't agree with that don't do it for the components you look into. Don't make it a generic rule that has to apply for everyone including people who don't agree with like me
16:07 JoeJulian And I say that as someone who manages infrastructure.
16:07 ndevos pranithk1: bugzilla does not support having multiple default assignees per component, so it does not work for many componets we have
16:07 pranithk1 JoeJulian: We can just change the rules so that for a subset of components default assignee is me.
16:07 pranithk1 ndevos: I think I already mentioned, I just want it to be changed for the components I maintain.
16:08 pranithk1 ndevos: For people happy with the current setup let them continue
16:08 pranithk1 ndevos: I don't like it
16:08 ndevos pranithk1: yes, you mentioned that, but we need a way for all components that we have, no exceptions or awkward lists to maintain
16:08 pranithk1 ndevos: Again, who makes these rules?
16:09 ndevos pranithk1: we discussed it a lot during several triage meetings
16:10 JoeJulian Sounds to me like this should then be brought up on -infra to discuss the problems of maintaining the option, and also at a triage meeting.
16:12 pranithk1 JoeJulian: They are just rules you need to apply. Just like it applies bugs@gluster.org, if it is replicate, it can be me, if it is arbiter it can be Ravi, if it is sharding it can be Krutika
16:13 ndevos pranithk1: would that also mean that the weekly bug triage meeting does not need to care about those components anymore?
16:13 JoeJulian And it was Avati for many for months and months after he was no longer participating, so it is an infra problem.
16:14 ndevos pranithk1: and the default assignee will become responsible to triage those bugs, in a reasonable amount of time (say max. 2 days), and make sure someone traiges the bugs when they are not available?
16:15 ndevos if one of those questions gets a "no", I doubt the advantage of a default assignee
16:15 pranithk1 ndevos: JoeJulian: Let me ask the question differently. How can we make finding the person who is responsible for a component easily available in bugzilla when a user logs a bug. Don't bring up what is easier for the people who are on the side of looking into it.
16:16 pranithk1 ndevos: JoeJulian: User who logs a bug should immediately know a human who is responsible for the component.
16:16 ndevos pranithk1: the person that reports a bug should not need to care, someone working on the component should update the status of the bug, ask for details, ... when a notification gets in - or check for thoe every morning or such
16:16 pranithk1 ndevos: JoeJulian: How do you solve that problem?
16:16 JoeJulian Add it to the Component Description?
16:16 pranithk1 ndevos: Dude! this is exactly my problem.
16:17 ndevos pranithk1: a default assignee does not solve it, the assignee can be busy or unavailable - that is what happens with community projects, buy RHGS or support elsewhere if you need to talk to a person *now*
16:18 JoeJulian Add to the description template information about where to look for maintainers?
16:19 hchiramm joined #gluster-dev
16:19 ndevos pranithk1: why would there bugs be left to triage every week? the main problem is that many developers/maintainers do not act on newly reported bugs, I doubt that changes with a default assignee
16:19 pranithk1 ndevos: Ah! see that is one more problem. You are again speaking for every other maintainer. I don't agree to that. I helped JoeJulian in the past and I will help him agian if he wants help *now* even if he doesn't bug RHGS
16:19 JoeJulian I kind of like that last idea. "For urgent help, try our IRC channel, mailing lists, or email the maintainer directly. See https://github.com/gluster/glu​sterfs/blob/master/MAINTAINERS.
16:19 pranithk1 ndevos: buy*
16:20 JoeJulian Put that right in the bug description template.
16:20 shyam joined #gluster-dev
16:21 JoeJulian I think that does what pranithk1 is asking for, it empowers the user.
16:21 ndevos pranithk1: sure, I help users too, either in #gluster, by email or in bug reports - all of them are most often group visible, including bug reports... not sure what your point is?
16:21 pranithk1 ndevos: Exactly so they did get help from quite a few of us when they needed even when they didn't buy RHGS.
16:22 JoeJulian Kind of like when we call the doctor's office and the recording says, "if this is an emergency, please hang up and call 911".
16:22 pranithk1 ndevos: I agree we are not entitled to. But you gave users the option
16:22 pranithk1 ndevos: We need to give that option
16:22 ndevos JoeJulian: yes, I understand that pranithk1 wants to give more initiative to the user, but I also want to understand why notifications for new bugs are not sufficient when a user asks for help
16:23 pranithk1 ndevos: Because user doesn't know who to contact. JoeJulian knows who to contact. I want others also be as knowledgeable as him about who to contact
16:23 ndevos JoeJulian: I think the template of the bug report is bugzilla wide, not per component :-(
16:24 JoeJulian I thought it was product-wide. :(
16:24 pranithk1 ndevos: I thought it is product-wide too?
16:24 pranithk1 ndevos: We get specific comments added after a bug is raised on RHGS
16:24 ndevos not sure, I've only seen one template... if it is product wide, we could probably get it adapted
16:25 ndevos pranithk1: thats done by a bot, it is not the template
16:25 pranithk1 ndevos: It does it quite fast actually
16:26 ndevos pranithk1: yes, it uses notifications, pretty much the same you should and act upon when someone reports a new bug :)
16:26 ndevos ... should get and ...
16:26 pranithk1 ndevos: See, you again missed the point
16:26 pranithk1 ndevos: Goal is to empower user. Not ourselves
16:27 ndevos pranithk1: sure, and by updating the template that might work for you too?
16:27 pranithk1 ndevos: didn't get the last point. Sorry
16:28 Muthu|afk joined #gluster-dev
16:28 ndevos pranithk1: get the "report a new bug template" (the one that asks for a description, version, reproduce steps, ..) updated with a link to the MAINTAINERS file or gluster.org/contact (or wahetever)
16:29 pranithk1 ndevos: How do I get that?
16:30 ndevos pranithk1: I really do not like the idea that users send emails to maintainers/developers without the community lists on CC, we should try to get users to communicate in the community
16:30 JoeJulian pranithk1: it's information given to the user. If the user feels it's urgent enough to need to contact a maintainer, there's a clear invitation to do so.
16:31 JoeJulian pranithk1 has a point, though. There's still a strong producer/consumer mentality in the world and when users are stuck, a lot of them don't feel a connection with a project and don't feel "worthy" to ask for help, especially since they're not paying any money.
16:31 ndevos pranithk1: would you be happy to see a link to https://www.gluster.org/community/ and https://github.com/gluster/glu​sterfs/blob/master/MAINTAINERS when a user reports a new bug?
16:33 ndevos JoeJulian: I expect that those users would update the bug report, and not start to email the assignee
16:34 JoeJulian Not necessarily. I didn't. I have bugs that are still open that are over 10 years old for some projects. An invitation to engage is what some people need.
16:35 pranithk1 ndevos: That would help. I think we solved the complete problem from the users point of view. They raise a bug. It is assigned to maintainer and we add a message saying the bug will be CCed with co-maintainers as and when the bot runs through the list. To know more about getting help we link to https://www.gluster.org/community/ and https://github.com/gluster/glu​sterfs/blob/master/MAINTAINERS
16:35 JoeJulian (and some of those bugs were auto-assigned) ;)
16:35 pranithk1 JoeJulian: :-)
16:36 ndevos JoeJulian: fedora auto assigns bugs too, many of those never get handled and auto-closed when the release goes EOL
16:36 ndevos I'm just wondering how and why we could make it work better for us
16:37 ndevos and bugs for fedora are mostly easy, packagers only need to forward the details to the upstream projects and pass details back...
16:37 JoeJulian as a user, that auto-assign means nothing to me. I've never even thought about emailing the assingee directly.
16:38 ndevos JoeJulian: that matches my experience for any of the bugs that I got assigned to
16:39 JoeJulian Even a bot that replied to the bug with a "Hey, thanks for reporting this. I'll be taking a look at it as soon as possible." would have left me with a better feeling.
16:39 ndevos pranithk1: so, shall we into providing the links (with a note) in the template or automated comment? and not a default assignee because that needs backup people and other exception handling?
16:41 ndevos (backup people would need to stay using the notifications that are available now already too, in any case)
16:41 pranithk1 ndevos: Thinking
16:46 pranithk1 ndevos: From the pov of user I think we can still choose a default assignee I guess. We can say something like: "The bug is generally assigned to the component maintainer for triaging, if you you need immediate help/response please take a look at: https://www.gluster.org/community, and the following link  https://github.com/gluster/glu​sterfs/blob/master/MAINTAINERS mentions other folks who may help you with this bug". This doesn't change anything from wha
16:48 ndevos pranithk1: well, the difficulty is to set a default assignee for components that have none, or have multiple, I would really like to treat all components equally
16:48 pranithk1 ndevos: Then we should have maintainers/default assignee for all components.
16:49 ndevos pranithk1: yes, and extend bugzilla to allow multiple assignees
16:49 JoeJulian Fix bugzilla! I like that. :)
16:50 ndevos pranithk1: and we still require backup people that watch the bugs when default assignees are not available... it is just *so* much easier to not have default assignees and use the same ways for all components
16:51 pranithk1 ndevos: Think from users pov Niels. It doesn't matter what we do. What matters is what would be easier for users. Not have an assignee who is human or have an assignee who is human?
16:52 ndevos pranithk1: as a user, I've always found it extremely confusing to get updates in bugs from people that are not the assignee... I would probably have been more confident if there was no assignee
16:53 pranithk1 ndevos: I found it to be opposite. I like to know who I would be talking to. If possible send him a mail explaining the dire need of the bug being fixed asap.
16:54 pranithk1 ndevos: I guess now I understand we both are trying to change the system the way *we* think would be useful. Which are in conflict. I guess one possible solution is to give maintainers a choice to be the default assignee?
16:55 ndevos pranithk1: right, I understand the potential need to get in touch with someone that knows about the topic, but I do not have the experience with bugzilla that the default assignee is that person
16:56 pranithk1 ndevos: yeah.
16:56 ndevos pranithk1: we still can not have multiple default assignees in bugzilla, and I would like to revent users to email only one of the multiple maintainers
16:57 ndevos p+revent
16:58 pranithk1 ndevos: Goal is to get attention. All debugging should happen on bugzilla. I see your point about why having all the discussions on the bz is much more helpful. But we as maintainers should make it happen
16:59 ndevos pranithk1: pointing the users to the list of maintainers, irc and mailinglists would probably be helpful, but a default assignee introduces a SPOF and that is what I'd like to prevent
16:59 pranithk1 ndevos: Maintainers inviting them to have further conversation on bugzilla is much more productive than preventing people from mailing a person. I will be happy to CC xavih/ashish whenever someone mails me in person for EC related bugs.
17:00 pranithk1 ndevos: I believe default assignee at least a single point.
17:01 JoeJulian What if you're hit by the proverbial bus?
17:01 ndevos pranithk1: sure, and if someone emails you about bugs, you are responsible to capture all details in bugzilla anyway , but that is besides the point for now :)
17:01 pranithk1 ndevos: why?
17:02 ndevos pranithk1: I dont think it is much related
17:02 pranithk1 ndevos: JoeJulian, then my account will be deleted by redhat bot and it will be assigned to my manager.
17:05 ndevos pranithk1: that brings an other point, we will need to make sure that the default assignee is always the correct one, otherwise we break the users' expectations of being able to send emails to them...
17:06 pranithk1 ndevos: Yes, the email id will bounce if the email is not valid. Most of the people put automatic responses when they are on vacation. So it is not that bad
17:07 pranithk1 ndevos: email will bounce not the email id :-D
17:07 ndevos pranithk1: depends, your email will be redirected to Satish on other occasions, and I doubt he'll reply quickly :)
17:08 ndevos pranithk1: we already have difficulties enough keeping the MAINTAINERS file correctly updated, adding an other place where we need to update it will be a pain
17:08 pranithk1 ndevos: As with design, you optimize for the common case
17:08 kotreshhr left #gluster-dev
17:08 ndevos pranithk1: hmm, maybe we should have a bot that reads the MAINTAINERS file and leaves a note with email addresses in the new bugs?
17:09 pranithk1 ndevos: As with design, you optimize for the common case. In the worst case it will be caught in the next weekly triage
17:10 ndevos pranithk1: right, and the common case is that nobody uses the email address of the assignee... people email you because you send emails on the mainlingsts :)
17:11 ndevos *mailinglists
17:11 pranithk1 ndevos: Then in my world, default assignee is good. So I would like that to happen.... i.e. for components I maintain
17:12 ndevos pranithk1: but you will be the exception, and not the common case anymore...
17:14 pranithk1 ndevos: If user wants to send me mails, and I want to receive them, why should any rule/process prevent user to send me mail?
17:15 ndevos pranithk1: a users will have your, and the other component maintainers emails when we point to the MAINTAINERS file (or even include it in an automated comment)
17:16 pranithk1 ndevos: No doubt. Is there any additional harm that is done if we also add a default assignee?
17:16 kkeithley ndevos: you're Mr. Mock.  To build, e.g., nfs-ganesha with a special build of glusterfs, I would use `mock --installdeps $specialglusterrpms nfs-ganesha.src.rpm` ?   Or I have to do --installdeps first, then run `mock nfs-ganesha.src.rpm`
17:16 ndevos pranithk1: that is something we can apply to all new bugs, no exceptions needed, no SPOFs
17:16 ndevos kkeithley: you can use 'mockchain' for that
17:17 ndevos kkeithley: like 'mockchain -r epel-7-x86_64 glusterfs-...src.rpm nfs-ganesha-...src.rpm'
17:17 kkeithley ah, okay
17:17 pranithk1 ndevos: I can't affect bugs that are not in my component because I don't know enough. But for the bugs I do know something about, I would like to be assigned.
17:18 ndevos pranithk1: the harm is in maintaining the default assignee for components outside our direct control (bugzilla), getting that list out of sync and setting wrong expectations to users if the defaul assignee is unavailable
17:20 pranithk1 ndevos: For the components which I maintain to go out of sync one of the three things should happen: 1) I should die. 2) I voluntarily choose to let go of the component. Both of them will be publicly known. So for an even that will happen once in a lifetime doesn't need to be taken into account in deciding this.
17:20 pranithk1 ndevos: one of the two things :-/
17:21 ndevos pranithk1: for you yes, but we need the same process for all other components, and we've seen difficulties with keeping the MAINTAINERS list up-to-date, this counts for any list
17:22 pranithk1 ndevos: Why should it be same for everyone?
17:22 ndevos pranithk1: its not something I worry too much for in relation with you, but we need to handle common guidelines for everything
17:22 pranithk1 ndevos: why?
17:22 ndevos pranithk1: nobody likes exceptions, they are difficult to maintain
17:23 pranithk1 ndevos: Then have all maintainers be default assignee for their respective components
17:24 ndevos pranithk1: maybe you would like to have a script that watches for notifications and assigns new bugs to you as soon as they get reported?
17:24 JoeJulian I think we've just encountered recursion with a possible memory leak.
17:25 pranithk1 ndevos: Do you have such a script?
17:25 pranithk1 ndevos: Don't ask me to write one.
17:26 ndevos pranithk1: I dont have a script that watches notifications, but I have commands that update he bugzilla status/assignee - having that watch a mailbox or rss-feed can not be very difficult
17:27 pranithk1 ndevos: Okay. I either need a default assignee or a script which does the same which is always running and does the same.
17:28 ndevos pranithk1: oh, what mail client do you use? maybe it can execute scripts when you receive the notifications
17:28 * ndevos thinks mutt can do that, and probably others too
17:28 pranithk1 ndevos: I use gmail
17:29 ndevos hmm, that might be more tricky... I guess it could run in Jenkins too
17:32 mss joined #gluster-dev
17:33 cogsu joined #gluster-dev
17:33 esmiurium joined #gluster-dev
17:33 jtc joined #gluster-dev
17:33 suliba joined #gluster-dev
17:34 ndevos pranithk1: when a bug gets assigned to a person, everyone will assume that this person will follow up, I doubt anyone in the bug triage meeting will look into the details and expect them to set the Triaged keyword immediately - is that acceptable for you too?
17:34 pranithk1 ndevos: I don't mind.
17:34 _iwc joined #gluster-dev
17:36 ndevos pranithk1: cool, that would then cover: afr, ec, index, io-threads, posix, libglusterfs?
17:36 ndevos + locks
17:36 hchiramm joined #gluster-dev
17:37 pranithk1 ndevos: okay
17:37 samikshan joined #gluster-dev
17:38 ndevos pranithk1: what would be the expectation of response times? some of those components have multiple maintainers, should they update the bug if there is no response from you after a day?
17:39 pranithk1 ndevos: Sure
17:44 ndevos pranithk1: there are currently 4 bugs in a state that would get assigned to you, can you check if that is correct?
17:44 ndevos https://bugzilla.redhat.com/buglist.cgi?bug​_status=NEW&amp;component=locks&amp;compone​nt=io-threads&amp;component=posix&amp;compo​nent=replicate&amp;component=disperse&amp;c​omponent=index&amp;keywords=Triaged&amp;key​words_type=nowords&amp;list_id=6251626&amp;​product=GlusterFS&amp;query_format=advanced
17:45 ndevos wait, that seems to be 18, this is more correct: https://bugzilla.redhat.com/buglist.cgi?bug_stat​us=NEW&amp;component=disperse&amp;component=inde​x&amp;component=io-threads&amp;component=locks&a​mp;component=posix&amp;component=replicate&amp;e​mail1=bugs%40gluster.org&amp;emailassigned_to1=1​&amp;emailtype1=substring&amp;list_id=6251633&am​p;product=GlusterFS&amp;query_format=advanced
17:46 pranithk1 ndevos: Yes there are 18....
17:48 ndevos pranithk1: there is no component libglusterfs in bugzilla, not sure how to select bugs for that, but I guess it is more of a 'core' thing and I dont think we should have a default assignee for something like that
17:48 primusinterpares joined #gluster-dev
17:49 pranithk1 ndevos: agreed
17:50 ndevos pranithk1: oh, that was unexpected... now I wonder why a user reporting a bug against 'core' would not have the default assignee to a person they can contact, this feels so messy :-/
17:50 pranithk1 ndevos: Niels something is better than nothing
17:50 ndevos we're also giving users a different experience depending on the component they report a bug against, that does not make me feel very good
17:51 pranithk1 ndevos: Depends on the maintainer the component belongs to
17:51 Muthu|afk joined #gluster-dev
17:52 ndevos pranithk1: it just feels like a partial solution, or maybe a hacky workaround... I probably need to think a little more about it
17:52 pranithk1 ndevos: Hacky workaround is fine too. Just give me the script. I can improve upon it to change it to my needs
17:52 ndevos pranithk1: well, 'core' is a strange component, and I'm sure we'll find others that dont fit with a signle default assignee
17:53 pranithk1 ndevos: 'core' is deprecated in RHGS product for the same reason.....
17:54 ndevos pranithk1: well, we cant deprecate it, we still have bugs in the code that are not related to real identifyable components
17:54 pranithk1 ndevos: We move them and then deprecate it
17:54 ndevos also 'other' or 'unclassified' is not really an option
18:06 pranithk1 ndevos: It is fine Niels. Just give me the script. I will take care of the rest.
18:07 ndevos pranithk1: http://termbin.com/q4v9 would probably do it, but you'll need to run it every now and then
18:09 ndevos pranithk1: that xargs command could use --no-run-if-empty too :)
18:10 pranithk1 ndevos: 'Your requested URL has been blocked as per the  directions received from Department of Telecommunications, Government of  India. Please contact administrator for more information."
18:10 pranithk1 ndevos: India doesn't like that URL :-)
18:10 ndevos pranithk1: haha, you're not allowed to access bugzill?
18:12 ndevos pranithk1: oh, wait, maybe you mean the termbin url, and it wasnt the output of the script :_
18:13 kkeithley ndevos: mockchain is doing a whole lot of nothing
18:13 pranithk1 ndevos: yes, the termbin one...
18:13 ndevos pranithk1: maybe http://paste.fedoraproject.org/455134/14768143/ then?
18:14 ndevos kkeithley: by default it does not show a lot of output, maybe it is trying to download the packages for the buildroot?
18:14 kkeithley regular mock built glusterfs in approx 10 min.  mockchain didn't even build the first (glusterfs) package in 60 min
18:15 ndevos kkeithley: yeah, and mockchain just executes mock with some fancy options
18:15 pranithk1 ndevos: checking it
18:27 ndevos kkeithley: did mockchain start some mock processes? maybe the mock commandline shows the location of the root.log or something?
18:35 ndevos pranithk1: I'll get something to eat now, its passed dinner time for me, we can check tomorrow how things work out for you
18:39 wushudoin| joined #gluster-dev
18:46 luizcpg joined #gluster-dev
18:47 pranithk1 ndevos: sure
18:47 pranithk1 ndevos: thanks for the script
18:50 luizcpg joined #gluster-dev
18:50 jobewan joined #gluster-dev
19:09 skoduri joined #gluster-dev
19:20 hchiramm joined #gluster-dev
19:29 msvbhat joined #gluster-dev
20:29 lpabon joined #gluster-dev
20:42 ndk_ joined #gluster-dev
21:56 luizcpg joined #gluster-dev
22:41 a2 joined #gluster-dev
23:21 hagarth joined #gluster-dev
23:41 shyam joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary