search for: triaging

Hello I was wondering if someone could put together a bug triage guide and put it on the wiki. I was looking for something to do tonight and z00dax said go hunt some bugs. So I went first to the wiki to look for a guide for a proper procedure on how the team would like bug triaging handled but didn't find one. I have triaged before but i know every place is different. So some guidelines would come in handy, thanks. -- LostSon http://lostsonsvault.org CentOS - It's not just for servers ya know... -------------- next part -------------- A non-text attachment was scru...

As everyone probably realizes, I''m getting swamped with incoming problems and tickets and I still need help triaging the tickets. James Turnbull has volunteered to help some, but I think we need more than one person. We''ve had a few people step in once or twice, but I''d like to be able to depend on Unreviewed tickets getting handled by someone else, rather than having it sitting over m...

...ion for how reported bugs should be flowing through the various stages of a bug’s life (triage, fixing, closing, …) at http://llvm.org/docs/BugLifeCycle.html. Thanks for the many many people who provided ideas and feedback for this! With there now being a description of what is expected during bug triaging (http://llvm.org/docs/BugLifeCycle.html#triaging-bugs), we're looking for more volunteers to actually do the bug triaging. About half of all raised bugs currently don’t seem to get triaged. The idea is to have one or more volunteers for each of the well over 100 different product/component com...

...0 bugs reported into an “Other” component. I do agree that some merging could still probably be done. E.g. maybe all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into a single component. So in summary: * I don’t think we need to delay assigning volunteers-for-triaging/default-cc lists to components. If we merge components later on, we can merge cc lists, or asks the volunteers for the relevant components If they want to remain on the default-cc list for the merged component. * My opinion is the we should define components based on areas of expertise. Thanks...

...0 bugs reported into an “Other” component. I do agree that some merging could still probably be done. E.g. maybe all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be merged into a single component. So in summary: * I don’t think we need to delay assigning volunteers-for-triaging/default-cc lists to components. If we merge components later on, we can merge cc lists, or asks the volunteers for the relevant components If they want to remain on the default-cc list for the merged component. * My opinion is the we should define components based on areas of expertise. Thanks...

...st 7 days which no-one seems to have looked at", or something similar. Hopefully it should be possible to build the list automatically. I'm not sure how large that list would be each week though, or how useful it would be. Also, this might be something we should fix by having a better bug triaging process in general. Cheers, Hans

...y be done. E.g. maybe >>> all the “clang/C++11”, “clang/C++14”, “clang/C++17”, “clang/C++2a” could be >>> merged into a single component. >>> >>> So in summary: >>> >>> - I don’t think we need to delay assigning >>> volunteers-for-triaging/default-cc lists to components. If we merge >>> components later on, we can merge cc lists, or asks the volunteers for the >>> relevant components If they want to remain on the default-cc list for the >>> merged component. >>> - My opinion is the we s...

...epository in approximately two weeks from now, and instruct everyone to start filing new issues there, rather than in bugzilla. Some things we'd like to get in place before turning on Github's Issue tracker: 1. Updated documentation. 2. An initial set of issue tags we'd like to use for triaging/categorizing issues. 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not. But more important are the things we do *not* want to make prerequisites for turning on Github issues: We do *not* yet plan to turn off Bugzilla, and do *not* plan to migrate the existing iss...

Evening, Alright folks, as Jeremy Kemper mentioned I''m working on a set of "triage" scripts for the Rails trac using RFuzz to go through all the tickets and clean them out. I''ve talked this over with the core guys, and they''re behind it. I''m calling this set of scripts "THE MAGGOT" thanks to hasmanyjosh. Basically THE MAGGOT (all caps)

Evening, Alright folks, as Jeremy Kemper mentioned I''m working on a set of "triage" scripts for the Rails trac using RFuzz to go through all the tickets and clean them out. I''ve talked this over with the core guys, and they''re behind it. I''m calling this set of scripts "THE MAGGOT" thanks to hasmanyjosh. Basically THE MAGGOT (all caps)

Back in February, I opened two bugs, that seem to have had no activity: https://bugs.centos.org/view.php?id=15850 https://bugs.centos.org/view.php?id=15846 Is there some step I skipped when creating these? Or am I being impatient? :) -- Brian Reichert <reichert at numachi.com> BSD admin/developer at large

Hey Guys, All the tickets in our database now have a milestone of 1.0 or 1.x. The current plan is to fix all the 1.0 blockers before the 1.0 release and leave the 1.x defects till later. To view the list of blockers you need this report http://dev.rubyonrails.org/report/9 Now, as we''re all pragmatic programmers the next step should be to create unit tests that expose each of those

...l have already had time to > play their games and see if they're still affected. If there's any sort > of success, hopefully this will become a regular event. > > > So, if you're into bug triage, please come and join me in #winehackers > this Monday. The purpose of triaging bugs is to ultimately get them > fixed, so if you're a developer and would rather work on patches then by > all means do that instead. > > I've created a wiki page for the event here: http://wiki.winehq.org/BugDay > When we're done I'll poke bugzilla for some stats a...

Hi, I think that there are a few bugs that can be closed or that are less severe than the time of submission. http://bugs.freedesktop.org/show_bug.cgi?id=12361 This one does work for me, if anyone can confirm that i believe this is fixed. http://bugs.freedesktop.org/show_bug.cgi?id=11231 crash with swfdec 0.4.x but 0.5.1 does not, fixed perhaps.

...om now, and instruct everyone to start filing new issues there, rather than in bugzilla. > > > > Some things we'd like to get in place before turning on Github's Issue tracker: > > 1. Updated documentation. > > 2. An initial set of issue tags we'd like to use for triaging/categorizing issues. > > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or maybe not. > > > > But more important are the things we do /not/ want to make prerequisites for turning on Github issues: > > > > We do /not/ yet plan to turn off Bugzill...

...ew > issues there, rather than in bugzilla. > >>> > >>> Some things we'd like to get in place before turning on Github's Issue > tracker: > >>> 1. Updated documentation. > >>> 2. An initial set of issue tags we'd like to use for > triaging/categorizing issues. > >>> 3. Maybe setup an initial issue template. Or maybe multiple templates. > Or maybe not. > >>> > >>> But more important are the things we do /not/ want to make > prerequisites for turning on Github issues: > >>> > &gt...

...truct everyone to start filing new > issues there, rather than in bugzilla. > > > > Some things we'd like to get in place before turning on Github's Issue > tracker: > > 1. Updated documentation. > > 2. An initial set of issue tags we'd like to use for > triaging/categorizing issues. > > 3. Maybe setup an initial issue template. Or maybe multiple templates. > Or maybe not. > > > > But more important are the things we do /not/ want to make prerequisites > for turning on Github issues: > > > > We do /not/ yet plan to turn o...

On Tue, 2020-08-25 at 14:12 -0400, Andrew Walker via samba wrote: > On Tue, Aug 25, 2020 at 1:17 PM James B. Byrne via samba < > samba at lists.samba.org> wrote: > > > > > > > On Mon, August 24, 2020 22:19, Andrew Bartlett wrote: > > > > > > > > A bit of an aside, but it would be incredibly awesome if the > > > FreeBSD >

...not bad enough to delay the release further, > but probably bad enough to start the next dot release right after the > end of this one. > > Does that really sound like such a bad idea? > > cheers, > --renato Renato, My concern is that, without strict enforcement of the triaging serious P1-type bugs, the major llvm.org releases will devolve into a continual exchange of one set of major regressions for another set. Strict enforcement of back porting the required fixes from later trunk for point releases seem to require as just much effort and even more due diligence than j...

Hi all, Now that it looks like we have some kind of process to manage tickets, I need people to help me with that process. There are currently something like 117 open tickets, and there are about 6 different dimensions on which these tickets can be categorized (e.g., complexity, triage stage -- all the report times listed on the Reports page). My plan is to work my fingers raw going