Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread Andrea Corbellini
On Wed, Mar 26, 2014 at 9:54 AM, Brendan Donegan 
 wrote:

IMO, a team should also be looking at Triaged bugs when selecting new
tasks to work on, so if the bugs are genuinely Triaged and they have
enough information to go to In Progress (when a developer wants to 
work

on them) then I don't see the harm in general. I personally would tend
to look at both New and Triaged bugs when looking to pick up bug 
fixing

work on the projects I help maintain.


As I see it, we (bug triagers) work for developers. If developers are 
not happy, than it's our fault, we can't blame them: they're our 
customers!


We are free to discuss/blame their practices and suggest improvements. 
However such suggestions must reach the correct people (in this case, 
if I have understood correctly, the Ubuntu security team). We can't 
decide for them.


But in my opinion, the real problem here is that either Launchpad or 
the Ubuntu Wiki or the security team fail to communicate that security 
bugs are special and shouldn't be touched unless you know the correct 
workflow.

--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread Brian Murray
On Wed, Mar 26, 2014 at 10:36:34AM -0500, C de-Avillez wrote:
> On Wed, Mar 26, 2014 at 3:54 AM, Brendan Donegan <
> brendan.done...@canonical.com> wrote:
> 
> > IMO, a team should also be looking at Triaged bugs when selecting new
> > tasks to work on, so if the bugs are genuinely Triaged and they have
> > enough information to go to In Progress (when a developer wants to work
> > on them) then I don't see the harm in general. I personally would tend
> > to look at both New and Triaged bugs when looking to pick up bug fixing
> > work on the projects I help maintain.
> >
> 
> It all depends. There is NO one-size-fits-all that will work. The security
> team (as well as the kernel team, and others) have special workflows. One
> problem we have in launchpad is that there is no concept of workflow, all
> we have are bugs (as far as we are concerned). Workflow was hammered in
> bugs, using what launchpad provides.
> 
> (Also, you have imposed yourself a limit -- "when looking (...) on the
> projects I help maintain". You do not go and change bugs on projects you DO
> NOT maintain. You actually may go in, but you will be more careful.)
> 
> But, back to the issue at hand. The majority of security bugs shown with
> Alberto's search are *visibly* different from the "normal" bugs we deal
> with. I expect triagers to be careful on what they do -- if a certain bug
> looks different from the "common" (whatever it may mean) bug, STOP. Find
> why it is different. Don't assume that it is all the same.

And, if something is different or you have any doubts ask for help
either in the #ubuntu-bugs channel on irc or on the ubuntu-bugsquad
mailing list. If you don't get an answer in a timely fashion ping me and
I'll do my best to respond.

--
Brian Murray


signature.asc
Description: Digital signature
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread Brendan Donegan
On 26/03/14 15:36, C de-Avillez wrote:
> On Wed, Mar 26, 2014 at 3:54 AM, Brendan Donegan <
> brendan.done...@canonical.com> wrote:
> 
>> IMO, a team should also be looking at Triaged bugs when selecting new
>> tasks to work on, so if the bugs are genuinely Triaged and they have
>> enough information to go to In Progress (when a developer wants to work
>> on them) then I don't see the harm in general. I personally would tend
>> to look at both New and Triaged bugs when looking to pick up bug fixing
>> work on the projects I help maintain.
>>
> 
> It all depends. There is NO one-size-fits-all that will work. The security
> team (as well as the kernel team, and others) have special workflows. One
> problem we have in launchpad is that there is no concept of workflow, all
> we have are bugs (as far as we are concerned). Workflow was hammered in
> bugs, using what launchpad provides.
> 
> (Also, you have imposed yourself a limit -- "when looking (...) on the
> projects I help maintain". You do not go and change bugs on projects you DO
> NOT maintain. You actually may go in, but you will be more careful.)

No, I wasn't talking about Triaging bugs, I was talking about picking up
new bugs to work on.

> 
> But, back to the issue at hand. The majority of security bugs shown with
> Alberto's search are *visibly* different from the "normal" bugs we deal
> with. I expect triagers to be careful on what they do -- if a certain bug
> looks different from the "common" (whatever it may mean) bug, STOP. Find
> why it is different. Don't assume that it is all the same.

It is the purpose of bug-control to triage bugs in Ubuntu - if there are
exceptions to that then they should be documented. It sounds like we're
talking about CVE's specifically and I can understand how they'd be a
special case. I guess this should be documented somewhere. We shouldn't
expect people to guess.

> 
> And, of course, we should document these special workflows, at least to
> allow triagers to identify them.
> 
> ..C..
> 


-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread C de-Avillez
On Wed, Mar 26, 2014 at 3:54 AM, Brendan Donegan <
brendan.done...@canonical.com> wrote:

> IMO, a team should also be looking at Triaged bugs when selecting new
> tasks to work on, so if the bugs are genuinely Triaged and they have
> enough information to go to In Progress (when a developer wants to work
> on them) then I don't see the harm in general. I personally would tend
> to look at both New and Triaged bugs when looking to pick up bug fixing
> work on the projects I help maintain.
>

It all depends. There is NO one-size-fits-all that will work. The security
team (as well as the kernel team, and others) have special workflows. One
problem we have in launchpad is that there is no concept of workflow, all
we have are bugs (as far as we are concerned). Workflow was hammered in
bugs, using what launchpad provides.

(Also, you have imposed yourself a limit -- "when looking (...) on the
projects I help maintain". You do not go and change bugs on projects you DO
NOT maintain. You actually may go in, but you will be more careful.)

But, back to the issue at hand. The majority of security bugs shown with
Alberto's search are *visibly* different from the "normal" bugs we deal
with. I expect triagers to be careful on what they do -- if a certain bug
looks different from the "common" (whatever it may mean) bug, STOP. Find
why it is different. Don't assume that it is all the same.

And, of course, we should document these special workflows, at least to
allow triagers to identify them.

..C..
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread Alberto Salvia Novella

El 26/03/14 09:54, Brendan Donegan escribió:

IMO, a team should also be looking at Triaged bugs when selecting new
tasks to work on, so if the bugs are genuinely Triaged and they have
enough information to go to In Progress (when a developer wants to work
on them) then I don't see the harm in general. I personally would tend
to look at both New and Triaged bugs when looking to pick up bug fixing
work on the projects I help maintain.
Just imitate the One Hundred Papercuts work-flow 
's concepts 
 :P


 * In general: simple over correct, because correction is the child of
   simplicity. Simplicity makes problems to became obvious rapidly, and
   to be easy to change. So focus on this, because is what really matters.
 * Starting by deciding where to start (setting importance), so your
   work will attach what is more needed first. The 80% of return
   belongs to only the 20% of developed work, so start there.
 * Then with the latest step in the bug fixing process, so every piece
   of work is immediately poured in real improvement, instead of having
   unfinished work along the hole process.
 * Making information visually obvious to anyone, because visually is
   how information is processed more rapidly and in detail by the
   brain; and you'll want people helping you to be easy for them.
 * Measured, because processes tend to improve themselves when what's
   going on becomes obvious.
 * Parted, so its simple to accomplish one task; instead of having to
   pay attention to a bunch of things. Anything can be accomplished by
   dividing it into small goals.
 * It doesn't need much discussion, because the system is
   self-explanatory: serve yourself!
 * And adjusted to what is really required, not what you think it's
   required. The second can easily be a slant.

The result is generally something very small and minimalist that rarely 
will be noticed as what is: a power tool. As a rule of thumbs, as the 
tap when you open it for water, if it looks just too simple and easy to 
accomplish to be real; probably is well designed.


Just notice, as result of working like that, we have at this time only 
19 confirmed bugs with unknown priority for Trusty from the hundreds we 
had only three days ago :D (look at the final clean-up 
)


Philosophical but already powerful.

Regards @_@

--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-26 Thread Brendan Donegan
IMO, a team should also be looking at Triaged bugs when selecting new
tasks to work on, so if the bugs are genuinely Triaged and they have
enough information to go to In Progress (when a developer wants to work
on them) then I don't see the harm in general. I personally would tend
to look at both New and Triaged bugs when looking to pick up bug fixing
work on the projects I help maintain.

On 26/03/14 03:14, Pierre Equoy wrote:
> On Wed, Mar 26, 2014 at 12:15 AM, Alberto Salvia Novella <
> es204904...@gmail.com> wrote:
> 
>> El 25/03/14 17:02, Brian Murray escribió:
>>
>>  What particular bug number was this message regarding?
>>>
>> Marc was referring to the following work-flow 
>> (security bugs with an status of "new").
>>
>>
> Would it be possible for the security team to update this workflow to:
> security bugs with status in ("New", "Triaged")
> ?
> 
> That would be a request like this:
> https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&search=Search&field.status%3Alist=NEW&field.status%3Alist=TRIAGED&field.information_type%3Alist=PUBLICSECURITY&field.information_type%3Alist=PRIVATESECURITY&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&orderby=-importance&memo=75&start=0&direction=backwards
> 
> (I took the previous one and added issues with a "TRIAGED" status)
> 
> Cheers,
> 
> 


-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-25 Thread Pierre Equoy
On Wed, Mar 26, 2014 at 12:15 AM, Alberto Salvia Novella <
es204904...@gmail.com> wrote:

> El 25/03/14 17:02, Brian Murray escribió:
>
>  What particular bug number was this message regarding?
>>
> Marc was referring to the following work-flow 
> (security bugs with an status of "new").
>
>
Would it be possible for the security team to update this workflow to:
security bugs with status in ("New", "Triaged")
?

That would be a request like this:
https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&search=Search&field.status%3Alist=NEW&field.status%3Alist=TRIAGED&field.information_type%3Alist=PUBLICSECURITY&field.information_type%3Alist=PRIVATESECURITY&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_commenter=&field.subscriber=&field.structural_subscriber=&field.component-empty-marker=1&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_no_package.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on&orderby=-importance&memo=75&start=0&direction=backwards

(I took the previous one and added issues with a "TRIAGED" status)

Cheers,


-- 
Pierre Equoy
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-25 Thread Serge Hallyn
Switching to using tags instead of status to manage the workflow might
be less likely to get trampled on, but only so much.

Would it interfere with the workflow to have the bugs assigned to Ubuntu
Security Team (regardless of status)?  I don't think anyone would touch
a bug assigned to them...

Quoting Alberto Salvia Novella (es204904...@gmail.com):
> El 25/03/14 17:02, Brian Murray escribió:
> >What particular bug number was this message regarding?
> Marc was referring to the following work-flow
>  (security bugs with an status of
> "new").

> -- 
> Ubuntu-bugsquad mailing list
> ubuntu-bugsq...@lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad


-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-25 Thread Alberto Salvia Novella

El 25/03/14 17:02, Brian Murray escribió:

What particular bug number was this message regarding?
Marc was referring to the following work-flow 
 (security bugs with an status of "new").

--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-25 Thread Brian Murray
On Mon, Mar 24, 2014 at 04:01:48PM +0100, Alberto Salvia Novella wrote:
> El 24/03/14 14:47, Marc Deslauriers escribió:
> >On 14-03-24 09:37 AM, Alberto Salvia Novella wrote:
> >>El 24/03/14 13:31, Marc Deslauriers escribió:
> >>>Could you please stop changing statuses of bugs you don't intend on fixing 
> >>>yourself?
> >>>
> >>>Marking a bug as "triaged" and changing priorities on them makes 
> >>>absolutely no
> >>>sense if you aren't tasked to fix them.
> >>>
> >>>Changing one of my team's bugs to "triaged" means our scripts and 
> >>>procedures no
> >>>longer consider the bug to be new, hence, nobody will look at it anymore. 
> >>>It is
> >>>breaking our workflow.
> >>As said in the bug statuses  
> >>page,
> >>which arbitrates the hole bug management work-flow in Launchpad, "triaged" 
> >>means
> >>"a member of UbuntuBugControl 
> >>believes that the report describes a genuine bug in enough detail that a
> >>developer could start working on a fix."
> >>
> >>Moreover, according to lean management
> >>:
> >>
> >>   * The first source of flaws (or any waste) is them to remain invisible 
> >> (or
> >> untriaged or with unset priority in the case of bug management).
> >>   * Unpredictable work-flow has to be done manually till, after some 
> >> continuous
> >> improvement and waste reduction, it becomes regular.
> >>
> >>So, since your work-flow conflicts with Launchpad's one and with principal
> >>productivity recommendations, I'm sorry I'm not taking on your request; 
> >>except
> >>if I'm missing something.
> >>
> >(...)
> >Modifying in an arbitrary way bug statuses and priorities that teams depend 
> >on
> >to track work is simply a bad idea.
> >(...)
> What do you think; Quality, BugSquad and BugControl; about this topic?

It's hard to have an opinion on something without complete details of
the situation. What particular bug number was this message regarding?

--
Brian Murray

-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-24 Thread Alberto Salvia Novella

El 24/03/14 16:59, Thomas Ward escribió:
Correct me if I'm wrong, but the Triage Guide already IDs special 
package sets that have special rules, doesn't it?
I think the mistake was induce not because not being detailed in the 
documentation, but because the documentation being bloated.


While I have taking measures to develop my triaging with zero defect, I 
just couldn't handle in my mind all the details in such a long and non 
visual page as it's the bug triage 
 one.

--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality


Re: [Ubuntu-bugcontrol] Stop triaging bugs

2014-03-24 Thread Thomas Ward
Correct me if I'm wrong, but the Triage Guide already IDs special package sets 
that have special rules, doesn't it?



*Sent from my iPhone.  Please excuse any typos, as they are likely to happen by 
accident.*

> On Mar 24, 2014, at 11:56, Andrea Corbellini  
> wrote:
> 
>> On Mon, Mar 24, 2014 at 4:54 PM, Alberto Salvia Novella 
>>  wrote:
>> El 24/03/14 16:42, Andrea Corbellini escribió:
>>> Probably you are referring to this?
>>> https://wiki.ubuntu.com/Bugs/Bug%20triage#Special_types_of_bugs
>> Yes, here we have the problem. It has been a mistake of me, sorry.
>> 
>> It will be good if the bug triage page could be simplified.
> 
> Or probably each 'special' package needs to have a note on its Launchpad page 
> stating that non-standard triaging rules apply.
> ___
> Mailing list: https://launchpad.net/~ubuntu-bugcontrol
> Post to : ubuntu-bugcont...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol
> More help   : https://help.launchpad.net/ListHelp
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality