[Gluster-users] Our plan to get bugs fixed quicker, and features implemented sooner

Niels de Vos ndevos at redhat.com
Fri Aug 22 08:56:30 UTC 2014


On Thu, Aug 21, 2014 at 10:55:46PM -0700, 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.
> 
> 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.
> 
> 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 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.

I agree that any change in the urgency (severity/priority) should be 
considered with care. When changing the urgency, the one changing it 
should explain why the change is made, so that others can object and 
change it with their opinion or for their use-case.

I'm happy to review bugs for these kind of unexpected changes, and 
mediate between user/triager/developer to get to an acceptable 
agreement. Just ping me on IRC or send me an email with the bug in 
question, and your explanation/opinion.

Cheers,
Niels

> 
> 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



More information about the Gluster-users mailing list