search for: triage

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

...bull 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 my head constantly. Ticket triage is basically the process of making sure a ticket is valid (usually means reproducing the problem, and if code is attached making sure that it does what it''s supposed to). It would be a huge help if I didn''t have to do this myself for every opened ticket. I know that it wil...

Hi, Yesterday, I’ve landed a description 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 vo...

...And thanks for re-raising the question whether we have the right components in bugzilla. As I think this could be an area for lots of different opinions, without any near-perfect solution, it has the potential to be a discussion that drags on for a long time. I thought half of all bugs not getting triaged was a serious enough problem to try and tackle first (with this mail thread) before aiming to improve the component breakdown in bugzilla. I think that setting default-cc lists on the components we have currently is largely orthogonal to reducing/merging components, as we can always merge default-...

...icator * All Bugs Polly * All Bugs Runtime Libraries * libprofile Test Suite * All Bugs tools * All Bugs Website * All Bugs XRay * All Bugs I don't think it's helpful to have what essentially amounts to lots of dead components, because it causes confusion for bug reporters as well as triagers. I also don't think the above split is radically different than what is already there, and for the most part, it still *is* organized by expertise. It also means you need to find less volunteers to add themselves to the cc list for various components. Instead of needing to find a separate...

On Mon, Aug 28, 2017 at 8:04 AM, Alex Bradbury <asb at asbradbury.org> wrote: > On 27 August 2017 at 00:01, Alex Bradbury <asb at asbradbury.org> wrote: >> Hi all. I'm assuming most people reading this email are familiar with LLVM's >> code review process <http://llvm.org/docs/DeveloperPolicy.html#code-reviews> >> as well as LLVM Weekly, the

...s >> * All Bugs >> >> Website >> * All Bugs >> >> XRay >> * All Bugs >> >> I don't think it's helpful to have what essentially amounts to lots of >> dead components, because it causes confusion for bug reporters as well as >> triagers. I also don't think the above split is radically different than >> what is already there, and for the most part, it still *is* organized by >> expertise. It also means you need to find less volunteers to add >> themselves to the cc list for various components. Instead of...

...ssues. - There is no builtin way for users to subscribe to emails for bugs that have a given label (for example, all "clang" issues, or all x86 issues). Further steps ---- After we migrate, there's still things we want to do: 1. Discuss and setup new and better procedures around bug triage and prioritization. What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done ( https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-triage, https://forg...

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

...gt; 14 bugs every day. > > Since June 1st: > - 412 total bugs filed > - 87 bugs resolved invalid > - 227 bugs resolved fixed > - 133 bugs confirmed but not resolved (status new) > - 292 bugs created but unconfirmed > > Doing some subtraction that means we have 292 new untriaged bugs, but we > triaged or fixed (412-292-87-227-133) = 327 old bugs. > > So, we're swimming above water, which is good. But at this rate it'll > be years before we triage every bug. So, let's do something :) > > > Bug Jam this Monday! > > One idea that...

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.

...emails for bugs that have a given label (for example, all "clang" issues, or all x86 issues). > > > > Further steps > > ---- > > After we migrate, there's still things we want to do: > > > > 1. Discuss and setup new and better procedures around bug triage and prioritization. > > > > What we have been doing up until now has not been great in any case. Switching bug-trackers is a great opportunity to try to do something better. E.g., like what the rust project has done (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-tr...

..., all "clang" issues, or all x86 > issues). > >>> > >>> Further steps > >>> ---- > >>> After we migrate, there's still things we want to do: > >>> > >>> 1. Discuss and setup new and better procedures around bug triage and > prioritization. > >>> > >>> What we have been doing up until now has not been great in any case. > Switching bug-trackers is a great opportunity to try to do something > better. E.g., like what the rust project has done ( > https://github.com/rust-lang/rust...

...ls for bugs that > have a given label (for example, all "clang" issues, or all x86 issues). > > > > Further steps > > ---- > > After we migrate, there's still things we want to do: > > > > 1. Discuss and setup new and better procedures around bug triage and > prioritization. > > > > What we have been doing up until now has not been great in any case. > Switching bug-trackers is a great opportunity to try to do something > better. E.g., like what the rust project has done ( > https://github.com/rust-lang/rust/blob/master/CON...

...bmitted upstream'. The gap between those two things ends up being the issue here, which is when patches we (as the Samba Team) don't agree with are still applied by distributors and porters, all the QA, experience etc applied to Samba.org releases is just discarded. It also just makes bug triage much harder, and we have seen here that triage of FreeBSD issues is hard enough right now. Now of course there are always matters of degree in this, but is is an important principle to start with. Andrew Bartlett -- Andrew Bartlett https://samba.org/~abartlet/ Authentication Developer, Samba Te...

...g.lists at gmail.com> wrote: >> This still all begs the question of what exact metrics exist for the >> Q/A of llvm releases? IMHO, the bad PR from shoving out compiler >> releases with severe performance regressions in the generated code far >> outweighs a brief delay to triage these issues as much as possible. > > Hi Jack, > > It depends on how you interpret LLVM releases. > > I still see them as points in time where we actually did some deeper > investigations as a community and made sure the compiler is still > sane. If it's not, future poin...

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 through each of the tickets and categorizing them (or marking them as not needing this category) ASAP, but I would sure like some help. In particular, I''d love it if one or more peo...