[Gluster-users] Our plan to get bugs fixed quicker, and features implemented sooner
Pranith Kumar Karampuri
pkarampu at redhat.com
Fri Aug 22 07:50:34 UTC 2014
On 08/22/2014 11:46 AM, Joe Julian wrote:
> adding the "correct" gluster-devel to this.
>
> On 8/21/2014 10:55 PM, Joe Julian wrote:
>> There have been times that I, as a user and a front-line supporter,
>> have marked a bug with the urgency that I think it deserves - based
>> on my own knowledge as well as feedback from other users - only to
>> have that urgency lowered to normal because a developer who doesn't
>> experience the urgency we do as users, deemed it so.
Actually developers/assignees are not allowed to change severity, never
(Something that I learnt an year back. May be some developers don't even
know about it :-( ). Only priority is something that can be lowered by
the assignee. In my experience this happens for severe bugs as well when
the steps to re-create the bug are not there or logs are not enough to
find the root cause etc.
>>
>> Granted, there have also been many occasions where I didn't set the
>> urgency and my bug has been treated as if it was a message from
>> beyond the natural realm, for which I am truly grateful.
Because the message _is_ from beyond natural realm ;-)
>>
>> When I set the urgency, I try to consider more than just my own
>> current needs (though often they're truly quite urgent) and look at
>> potential for data loss, likelihood to encounter the bug during
>> normal operations, and feedback from other users who have (usually)
>> encountered the same bug. To have all that forethought discarded is
>> disheartening. For that reason, I never set the urgency of any of my
>> bugs any more.
I guess it would be better if you could raise it in devel mailing list
rather that not setting the urgency anymore :-(.
>>
>> I would be willing to participate in triage, but I would expect the
>> same rigidness in changing an urgency as there is in getting a change
>> accepted. The developer who wants to change the urgency should be
>> expected to argue his case, not simply change it.
+1
Pranith
>>
>> On 8/21/2014 12:12 AM, Lalatendu Mohanty wrote:
>>> I hope the subject line have increased your curiosity to go through
>>> the email :).
>>>
>>> As a community, we are looking for contributors for GlusterFS bug
>>> triage and hopefully this mail will give you enough motivation for it.
>>>
>>> As mentioned in the subject , bug triage will help to get bugs fixed
>>> quicker, and features implemented sooner. If you are not sure what
>>> bug triage means, please refer the gluster wiki page [1] for bug triage.
>>>
>>> Here are few questions and answers to help you if this is something
>>> you should do.
>>>
>>> * Q: Why we need to do bug triage?
>>> * A: It reduces the time between reporting a bug and the
>>> availability of a fix enormously.
>>> o Because many developers have bad response times for new bugs
>>> that are not pointed out to them. When well triaged bugs get
>>> assigned to right developers, the response time improves.
>>> o Also developers work mainly on writing bug fixes and
>>> implementing new features. Which in turn results in to
>>> spending (too little) time on bug triaging.
>>>
>>>
>>> * Q: I am just a GlusterFS user. Why bug triage will help me?
>>> * A: It will increase your understanding of GlusterFS, current
>>> issues in GlusterFS, increase the interaction between
>>> developers, community and triager. It will also help filing
>>> better bugs too. The better the bug report, the easier it is for
>>> a developer to write a fix.
>>>
>>>
>>> * Q: Do you run GlusterFS in production?
>>> * A: If your answer is yes, then bug triage is the right platform
>>> for you to raise the importance of bugs. Bug triage will also
>>> help you know existing issues in the version of GlusterFS you
>>> are using, help you to know existing issues in a new feature. So
>>> you will be in a better position to decide if a feature is
>>> production ready or not.
>>>
>>>
>>> * Q: I want to contribute to GlusterFS. Will bug triage help?
>>> * A: Yes, it is an awesome place to start. You will get to know
>>> about all the components in GlusterFS along with issues in each
>>> of them. This knowledge will help you to do better testing,
>>> development (bug fixing) etc. Also you will interact with
>>> developers while triaging bugs. You can use these interactions
>>> to ask more detailed questions.
>>>
>>>
>>> * Q: How can I triage bugs of GlusterFS?
>>> * A: The wiki page [1] is the right place start. We are starting
>>> up a bi-weekly/weekly triage meeting in #gluster-meeting on
>>> Freenode. There would be another mail with details about the
>>> meeting. You can join the meeting and interact with other triagers.
>>>
>>> Please don't hesitate to hit the reply button if you have any
>>> question on this. We would love to hear your suggestions/feed back :).
>>>
>>> [1] http://www.gluster.org/community/documentation/index.php/Bug_triage
>>>
>>> Thanks,
>>> On behalf of the bug triage team
>>> #gluster-dev, #gluster on Freenode
>>>
>>>
>>> _______________________________________________
>>> Gluster-users mailing list
>>> Gluster-users at gluster.org
>>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>>
>>
>>
>> _______________________________________________
>> Gluster-users mailing list
>> Gluster-users at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20140822/9e4c489e/attachment.html>
More information about the Gluster-users
mailing list