Re: A proposal to combine quality and bugsquad teams

[AG Restringere]

Thomas,

Okay, I'll create a separate subject and thread for this...thanks...

Best,
AG


On Mon, Nov 4, 2013 at 3:43 PM, Thomas Ward  wrote:

> AG,
>
> You are correct in proposing triage procedures here to the Bug Squad
> mailing list, but that should be made as a separate thread, in my
> opinion.  As it stands, the bug squad and QA are still separate right
> now, but ultimately any changes in triage procedure affect every group
> working with Ubuntu bugs, including the Server Team.
>
> Bug Control and Bug Squad work collectively on triage procedures, and
> the people in charge of bug triage (namely the bug god, Brian) do look
> at recommendations, so I recommend splitting your suggestions off the
> chain for the QA/BugSquad merger discussion and into its own thread on
> the bugsquad mailing list for now.
>
> -
> Thomas
>
> On Mon, Nov 4, 2013 at 3:40 PM, AG Restringere 
> wrote:
> > Thomas,
> >
> > Thank you for the information. I was previously unaware that they were
> two
> > separate groups. In that case where should I direct this feedback to
> improve
> > Bug Triage processes and what are the next steps I should take?
> >
> > Best regards,
> > AG
> >
> >
> > On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward  wrote:
> >>
> >> Ummm... I may be nitpicking but this is important... I think you're
> >> confusing Bug Squad with Bug Control, AG...
> >>
> >> In my discussions with Nicholas on IRC, we discussed the separation of
> Bug
> >> Squad and Bug Control.  Bug Squad has no specific rules to be a member.
>  It
> >> also does not give any special bug permissions to an individual.
> >>
> >> Bug Control is a separate group with a specific application procedure
> and
> >> has more permissions with bugs.  Given that, I had mentioned with
> Nicholas
> >> about the distinction and it was generally agreed that Bug Control
> would be
> >> left alone and separate from this 'merging' of Bug Squad and QA.
> >>
> >> Unless I missed further discussion on this, which would probably have
> >> landed on the Bug Control mailing list, that 'general understanding'
> still
> >> stood strong...
> >>
> >> (I want to make sure that you understand the distinction there, AG, that
> >> Bug Squad and Bug Control are different groups all bound to the same
> >> trialling rules, but with substantially different permission sets and
> >> application procedures.)
> >>
> >> On Nov 4, 2013, at 2:03 PM, AG Restringere 
> >> wrote:
> >>
> >> Hello Q/A and Bug Control teams,
> >>
> >> This is the first time I post to this list so hello!
> >>
> >> Because Bug Control is being restructured I was hoping that some of my
> >> ideas and experiences could find their way into the blueprint and be
> >> discussed at the next UDS:
> >>
> >> In my experience in - when I dabbled in some bug control work as part of
> >> the Ubuntu-X team - the Bug Triage process is still very tedious and
> lacks
> >> sufficient automation. Most of the time and effort I spent doing bug
> control
> >> work was spent browsing Launchpad and reading through hundreds of
> bug-emails
> >> in order to find bugs to work on.  Most of my time was spent searching
> for
> >> bugs but very little of my time was spent actively working on bugs and
> being
> >> productive.  Also, many times I saw bugs that had comments from Bug
> Control
> >> members but it was never clear who was working on the bug or what they
> >> wanted to do with it.  This often lead me to add comments when they
> weren't
> >> necessary or not contribute when a bug actually needed attention.  As a
> >> result I don't think the current process as it stands should be
> >> re-introduced into the new combined Q/A and Bug Control as is i without
> some
> >> modifications.
> >>
> >> Modifications I would make to the Bug Triage process:
> >>
> >> 1. Assignment and eliminating redundancy:
> >>
> >> When a Bug Triager begins working on a bug they should assign themselves
> >> to the bug on Launchpad if they intend to actively work on it.  Only
> one Bug
> >> Triage member should be assigned and actively working on a bug at any
> given
> >> time and they should effectively "own" that bug and be responsible for
> it.
> >> The only other people who should be working on that specific bug should
> be
> >> Reporters, Testers and Developers.  Assignment would help other Bug
> Triage
> >> people to know "this bug is actively owned by another member" and know
> to
> >> move on to other bugs and leave that one alone.  It would be even
> better if
> >> Launchpad could filter out the bugs that were actively assigned to Bug
> >> Control members so people could find those that nobody was working on
> and
> >> needed attention.  Sufficient criteria for finding new bugs could be as
> >> simple as "Confirmed"+"Unassigned".  I think this sort of assignment
> scheme
> >> makes sense given that the new Bug Control restructuring effort involves
> >> making roles very specific and eliminating redundancy.
> >>
> >> 2. Email volume reduction:
> >>
> >

Re: A proposal to combine quality and bugsquad teams

[Thomas Ward]

AG,

You are correct in proposing triage procedures here to the Bug Squad
mailing list, but that should be made as a separate thread, in my
opinion.  As it stands, the bug squad and QA are still separate right
now, but ultimately any changes in triage procedure affect every group
working with Ubuntu bugs, including the Server Team.

Bug Control and Bug Squad work collectively on triage procedures, and
the people in charge of bug triage (namely the bug god, Brian) do look
at recommendations, so I recommend splitting your suggestions off the
chain for the QA/BugSquad merger discussion and into its own thread on
the bugsquad mailing list for now.

-
Thomas

On Mon, Nov 4, 2013 at 3:40 PM, AG Restringere  wrote:
> Thomas,
>
> Thank you for the information. I was previously unaware that they were two
> separate groups. In that case where should I direct this feedback to improve
> Bug Triage processes and what are the next steps I should take?
>
> Best regards,
> AG
>
>
> On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward  wrote:
>>
>> Ummm... I may be nitpicking but this is important... I think you're
>> confusing Bug Squad with Bug Control, AG...
>>
>> In my discussions with Nicholas on IRC, we discussed the separation of Bug
>> Squad and Bug Control.  Bug Squad has no specific rules to be a member.  It
>> also does not give any special bug permissions to an individual.
>>
>> Bug Control is a separate group with a specific application procedure and
>> has more permissions with bugs.  Given that, I had mentioned with Nicholas
>> about the distinction and it was generally agreed that Bug Control would be
>> left alone and separate from this 'merging' of Bug Squad and QA.
>>
>> Unless I missed further discussion on this, which would probably have
>> landed on the Bug Control mailing list, that 'general understanding' still
>> stood strong...
>>
>> (I want to make sure that you understand the distinction there, AG, that
>> Bug Squad and Bug Control are different groups all bound to the same
>> trialling rules, but with substantially different permission sets and
>> application procedures.)
>>
>> On Nov 4, 2013, at 2:03 PM, AG Restringere 
>> wrote:
>>
>> Hello Q/A and Bug Control teams,
>>
>> This is the first time I post to this list so hello!
>>
>> Because Bug Control is being restructured I was hoping that some of my
>> ideas and experiences could find their way into the blueprint and be
>> discussed at the next UDS:
>>
>> In my experience in - when I dabbled in some bug control work as part of
>> the Ubuntu-X team - the Bug Triage process is still very tedious and lacks
>> sufficient automation. Most of the time and effort I spent doing bug control
>> work was spent browsing Launchpad and reading through hundreds of bug-emails
>> in order to find bugs to work on.  Most of my time was spent searching for
>> bugs but very little of my time was spent actively working on bugs and being
>> productive.  Also, many times I saw bugs that had comments from Bug Control
>> members but it was never clear who was working on the bug or what they
>> wanted to do with it.  This often lead me to add comments when they weren't
>> necessary or not contribute when a bug actually needed attention.  As a
>> result I don't think the current process as it stands should be
>> re-introduced into the new combined Q/A and Bug Control as is i without some
>> modifications.
>>
>> Modifications I would make to the Bug Triage process:
>>
>> 1. Assignment and eliminating redundancy:
>>
>> When a Bug Triager begins working on a bug they should assign themselves
>> to the bug on Launchpad if they intend to actively work on it.  Only one Bug
>> Triage member should be assigned and actively working on a bug at any given
>> time and they should effectively "own" that bug and be responsible for it.
>> The only other people who should be working on that specific bug should be
>> Reporters, Testers and Developers.  Assignment would help other Bug Triage
>> people to know "this bug is actively owned by another member" and know to
>> move on to other bugs and leave that one alone.  It would be even better if
>> Launchpad could filter out the bugs that were actively assigned to Bug
>> Control members so people could find those that nobody was working on and
>> needed attention.  Sufficient criteria for finding new bugs could be as
>> simple as "Confirmed"+"Unassigned".  I think this sort of assignment scheme
>> makes sense given that the new Bug Control restructuring effort involves
>> making roles very specific and eliminating redundancy.
>>
>> 2. Email volume reduction:
>>
>> Bug Triage members should only receive emails about bugs they're actively
>> assigned to.  It's really time consuming to sort through hundreds of
>> bug-mails that involve bugs that are not relevant to ones currently being
>> worked on.  This applies to all roles such as Testers, Reporters and others
>> as well.  The only general emails that should be received should be from the
>> 

Re: A proposal to combine quality and bugsquad teams

[AG Restringere]

Thomas,

Thank you for the information. I was previously unaware that they were two
separate groups. In that case where should I direct this feedback to
improve Bug Triage processes and what are the next steps I should take?

Best regards,
AG


On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward  wrote:

> Ummm... I may be nitpicking but this is important... I think you're
> confusing Bug Squad with Bug Control, AG...
>
> In my discussions with Nicholas on IRC, we discussed the separation of Bug
> Squad and Bug Control.  Bug Squad has no specific rules to be a member.  It
> also does not give any special bug permissions to an individual.
>
> Bug Control is a separate group with a specific application procedure and
> has more permissions with bugs.  Given that, I had mentioned with Nicholas
> about the distinction and it was generally agreed that Bug Control would be
> left alone and separate from this 'merging' of Bug Squad and QA.
>
> Unless I missed further discussion on this, which would probably have
> landed on the Bug Control mailing list, that 'general understanding' still
> stood strong...
>
> (I want to make sure that you understand the distinction there, AG, that
> Bug Squad and Bug Control are different groups all bound to the same
> trialling rules, but with substantially different permission sets and
> application procedures.)
>
> On Nov 4, 2013, at 2:03 PM, AG Restringere 
> wrote:
>
> Hello Q/A and Bug Control teams,
>
> This is the first time I post to this list so hello!
>
> Because Bug Control is being restructured I was hoping that some of my
> ideas and experiences could find their way into the blueprint and be
> discussed at the next UDS:
>
> In my experience in - when I dabbled in some bug control work as part of
> the Ubuntu-X team - the Bug Triage process is still very tedious and lacks
> sufficient automation. Most of the time and effort I spent doing bug
> control work was spent browsing Launchpad and reading through hundreds of
> bug-emails in order to find bugs to work on.  Most of my time was spent
> searching for bugs but very little of my time was spent actively working on
> bugs and being productive.  Also, many times I saw bugs that had comments
> from Bug Control members but it was never clear who was working on the bug
> or what they wanted to do with it.  This often lead me to add comments when
> they weren't necessary or not contribute when a bug actually needed
> attention.  As a result I don't think the current process as it stands
> should be re-introduced into the new combined Q/A and Bug Control as is i
> without some modifications.
>
> Modifications I would make to the Bug Triage process:
>
> 1. Assignment and eliminating redundancy:
>
> When a Bug Triager begins working on a bug they should assign themselves
> to the bug on Launchpad if they intend to actively work on it.  Only one
> Bug Triage member should be assigned and actively working on a bug at any
> given time and they should effectively "own" that bug and be responsible
> for it.  The only other people who should be working on that specific bug
> should be Reporters, Testers and Developers.  Assignment would help other
> Bug Triage people to know "this bug is actively owned by another member"
> and know to move on to other bugs and leave that one alone.  It would be
> even better if Launchpad could filter out the bugs that were actively
> assigned to Bug Control members so people could find those that nobody was
> working on and needed attention.  Sufficient criteria for finding new bugs
> could be as simple as "Confirmed"+"Unassigned".  I think this sort of
> assignment scheme makes sense given that the new Bug Control restructuring
> effort involves making roles very specific and eliminating redundancy.
>
> 2. Email volume reduction:
>
> Bug Triage members should only receive emails about bugs they're actively
> assigned to.  It's really time consuming to sort through hundreds of
> bug-mails that involve bugs that are not relevant to ones currently being
> worked on.  This applies to all roles such as Testers, Reporters and others
> as well.  The only general emails that should be received should be from
> the discussion or developer mailing lists.
>
> 3. Auto-assignment process queue:
>
> Similar to a tech-support ticket system the next step in this process
> would be to introduce a process queue with auto-assignment of bugs to Bug
> Triage members.  I don't know how this would work but some status change in
> the bug would have to trigger it's submission it into the process queue
> such as reaching a Confirmed status or increased Reporter activity at some
> threshold level. The distribution of the bugs would have to take into
> account the work-load of the Bug Triage members and distribute them evenly
> but perhaps that's a bit too complicated to do in code. Maybe random
> assignment would be better or it could based on the package selection
> preferences of individual members. Perhaps there could even be s

Re: A proposal to combine quality and bugsquad teams

[Alberto Salvia Novella]

What I find useful is having simple information in the wiki about how to 
find relevant bugs by using the advance search in Launchpad.



El 04/11/13 20:03, AG Restringere escribió:

Hello Q/A and Bug Control teams,

This is the first time I post to this list so hello!

Because Bug Control is being restructured I was hoping that some of my 
ideas and experiences could find their way into the blueprint and be 
discussed at the next UDS:


In my experience in - when I dabbled in some bug control work as part 
of the Ubuntu-X team - the Bug Triage process is still very tedious 
and lacks sufficient automation. Most of the time and effort I spent 
doing bug control work was spent browsing Launchpad and reading 
through hundreds of bug-emails in order to find bugs to work on.  Most 
of my time was spent searching for bugs but very little of my time was 
spent actively working on bugs and being productive.  Also, many times 
I saw bugs that had comments from Bug Control members but it was never 
clear who was working on the bug or what they wanted to do with it. 
 This often lead me to add comments when they weren't necessary or not 
contribute when a bug actually needed attention.  As a result I don't 
think the current process as it stands should be re-introduced into 
the new combined Q/A and Bug Control as is i without some modifications.


Modifications I would make to the Bug Triage process:

1. Assignment and eliminating redundancy:

When a Bug Triager begins working on a bug they should assign 
themselves to the bug on Launchpad if they intend to actively work on 
it.  Only one Bug Triage member should be assigned and actively 
working on a bug at any given time and they should effectively "own" 
that bug and be responsible for it.  The only other people who should 
be working on that specific bug should be Reporters, Testers and 
Developers.  Assignment would help other Bug Triage people to know 
"this bug is actively owned by another member" and know to move on to 
other bugs and leave that one alone.  It would be even better if 
Launchpad could filter out the bugs that were actively assigned to Bug 
Control members so people could find those that nobody was working on 
and needed attention.  Sufficient criteria for finding new bugs could 
be as simple as "Confirmed"+"Unassigned".  I think this sort of 
assignment scheme makes sense given that the new Bug Control 
restructuring effort involves making roles very specific and 
eliminating redundancy.


2. Email volume reduction:

Bug Triage members should only receive emails about bugs they're 
actively assigned to.  It's really time consuming to sort through 
hundreds of bug-mails that involve bugs that are not relevant to ones 
currently being worked on.  This applies to all roles such as Testers, 
Reporters and others as well.  The only general emails that should be 
received should be from the discussion or developer mailing lists.


3. Auto-assignment process queue:

Similar to a tech-support ticket system the next step in this process 
would be to introduce a process queue with auto-assignment of bugs to 
Bug Triage members.  I don't know how this would work but some status 
change in the bug would have to trigger it's submission it into the 
process queue such as reaching a Confirmed status or increased 
Reporter activity at some threshold level. The distribution of the 
bugs would have to take into account the work-load of the Bug Triage 
members and distribute them evenly but perhaps that's a bit too 
complicated to do in code. Maybe random assignment would be better or 
it could based on the package selection preferences of individual 
members. Perhaps there could even be some senior Bug Control members 
who would manually assign the bugs from the queue.  This would 
eliminate the need for Bug Triage members to even need to go to 
Launchpad to search for bugs unless they're doing some extra research. 
 Bugs would be sent to them via email automatically when they're ready 
to be triaged and auto-assigned without any extra steps needed.


Conclusion:

If the above steps were implemented or some equivalent processes I 
think the Bug Triage would be streamlined, eliminate redundancy and 
get faster turn-around times.  Bug Triage members would be more 
focused and successful. Newer Bug Triage members would be able to be 
"plugged in" to a standardized process and this would improve 
retention because people would see results faster with less effort.


Hopefully my feedback and comments had some value and will be 
considered for the upcoming changes to the Bug Control team and it's 
processes. If there are any other ways I can help the newly combined 
Q/A and Bug Control please let me know.  Thank you for your time and 
attention.


Best regards,
AG







On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs 
mailto:nicholas.ska...@canonical.com>> 
wrote:


Thanks to everyone for the feedback. Given the positive responses
I would like to move for

Re: A proposal to combine quality and bugsquad teams

[Thomas Ward]

Ummm... I may be nitpicking but this is important... I think you're confusing 
Bug Squad with Bug Control, AG...

In my discussions with Nicholas on IRC, we discussed the separation of Bug 
Squad and Bug Control.  Bug Squad has no specific rules to be a member.  It 
also does not give any special bug permissions to an individual.

Bug Control is a separate group with a specific application procedure and has 
more permissions with bugs.  Given that, I had mentioned with Nicholas about 
the distinction and it was generally agreed that Bug Control would be left 
alone and separate from this 'merging' of Bug Squad and QA.

Unless I missed further discussion on this, which would probably have landed on 
the Bug Control mailing list, that 'general understanding' still stood strong...

(I want to make sure that you understand the distinction there, AG, that Bug 
Squad and Bug Control are different groups all bound to the same trialling 
rules, but with substantially different permission sets and application 
procedures.)

> On Nov 4, 2013, at 2:03 PM, AG Restringere  wrote:
> 
> Hello Q/A and Bug Control teams,
> 
> This is the first time I post to this list so hello! 
> 
> Because Bug Control is being restructured I was hoping that some of my ideas 
> and experiences could find their way into the blueprint and be discussed at 
> the next UDS:
> 
> In my experience in - when I dabbled in some bug control work as part of the 
> Ubuntu-X team - the Bug Triage process is still very tedious and lacks 
> sufficient automation. Most of the time and effort I spent doing bug control 
> work was spent browsing Launchpad and reading through hundreds of bug-emails 
> in order to find bugs to work on.  Most of my time was spent searching for 
> bugs but very little of my time was spent actively working on bugs and being 
> productive.  Also, many times I saw bugs that had comments from Bug Control 
> members but it was never clear who was working on the bug or what they wanted 
> to do with it.  This often lead me to add comments when they weren't 
> necessary or not contribute when a bug actually needed attention.  As a 
> result I don't think the current process as it stands should be re-introduced 
> into the new combined Q/A and Bug Control as is i without some modifications. 
>  
> 
> Modifications I would make to the Bug Triage process:
> 
> 1. Assignment and eliminating redundancy: 
> 
> When a Bug Triager begins working on a bug they should assign themselves to 
> the bug on Launchpad if they intend to actively work on it.  Only one Bug 
> Triage member should be assigned and actively working on a bug at any given 
> time and they should effectively "own" that bug and be responsible for it.  
> The only other people who should be working on that specific bug should be 
> Reporters, Testers and Developers.  Assignment would help other Bug Triage 
> people to know "this bug is actively owned by another member" and know to 
> move on to other bugs and leave that one alone.  It would be even better if 
> Launchpad could filter out the bugs that were actively assigned to Bug 
> Control members so people could find those that nobody was working on and 
> needed attention.  Sufficient criteria for finding new bugs could be as 
> simple as "Confirmed"+"Unassigned".  I think this sort of assignment scheme 
> makes sense given that the new Bug Control restructuring effort involves 
> making roles very specific and eliminating redundancy.
> 
> 2. Email volume reduction: 
> 
> Bug Triage members should only receive emails about bugs they're actively 
> assigned to.  It's really time consuming to sort through hundreds of 
> bug-mails that involve bugs that are not relevant to ones currently being 
> worked on.  This applies to all roles such as Testers, Reporters and others 
> as well.  The only general emails that should be received should be from the 
> discussion or developer mailing lists.
> 
> 3. Auto-assignment process queue:
> 
> Similar to a tech-support ticket system the next step in this process would 
> be to introduce a process queue with auto-assignment of bugs to Bug Triage 
> members.  I don't know how this would work but some status change in the bug 
> would have to trigger it's submission it into the process queue such as 
> reaching a Confirmed status or increased Reporter activity at some threshold 
> level. The distribution of the bugs would have to take into account the 
> work-load of the Bug Triage members and distribute them evenly but perhaps 
> that's a bit too complicated to do in code. Maybe random assignment would be 
> better or it could based on the package selection preferences of individual 
> members. Perhaps there could even be some senior Bug Control members who 
> would manually assign the bugs from the queue.  This would eliminate the need 
> for Bug Triage members to even need to go to Launchpad to search for bugs 
> unless they're doing some extra research.  Bugs would be sent to them via 

Re: A proposal to combine quality and bugsquad teams

[AG Restringere]

Hello Q/A and Bug Control teams,

This is the first time I post to this list so hello!

Because Bug Control is being restructured I was hoping that some of my
ideas and experiences could find their way into the blueprint and be
discussed at the next UDS:

In my experience in - when I dabbled in some bug control work as part of
the Ubuntu-X team - the Bug Triage process is still very tedious and lacks
sufficient automation. Most of the time and effort I spent doing bug
control work was spent browsing Launchpad and reading through hundreds of
bug-emails in order to find bugs to work on.  Most of my time was spent
searching for bugs but very little of my time was spent actively working on
bugs and being productive.  Also, many times I saw bugs that had comments
from Bug Control members but it was never clear who was working on the bug
or what they wanted to do with it.  This often lead me to add comments when
they weren't necessary or not contribute when a bug actually needed
attention.  As a result I don't think the current process as it stands
should be re-introduced into the new combined Q/A and Bug Control as is i
without some modifications.

Modifications I would make to the Bug Triage process:

1. Assignment and eliminating redundancy:

When a Bug Triager begins working on a bug they should assign themselves to
the bug on Launchpad if they intend to actively work on it.  Only one Bug
Triage member should be assigned and actively working on a bug at any given
time and they should effectively "own" that bug and be responsible for it.
 The only other people who should be working on that specific bug should be
Reporters, Testers and Developers.  Assignment would help other Bug Triage
people to know "this bug is actively owned by another member" and know to
move on to other bugs and leave that one alone.  It would be even better if
Launchpad could filter out the bugs that were actively assigned to Bug
Control members so people could find those that nobody was working on and
needed attention.  Sufficient criteria for finding new bugs could be as
simple as "Confirmed"+"Unassigned".  I think this sort of assignment scheme
makes sense given that the new Bug Control restructuring effort involves
making roles very specific and eliminating redundancy.

2. Email volume reduction:

Bug Triage members should only receive emails about bugs they're actively
assigned to.  It's really time consuming to sort through hundreds of
bug-mails that involve bugs that are not relevant to ones currently being
worked on.  This applies to all roles such as Testers, Reporters and others
as well.  The only general emails that should be received should be from
the discussion or developer mailing lists.

3. Auto-assignment process queue:

Similar to a tech-support ticket system the next step in this process would
be to introduce a process queue with auto-assignment of bugs to Bug Triage
members.  I don't know how this would work but some status change in the
bug would have to trigger it's submission it into the process queue such as
reaching a Confirmed status or increased Reporter activity at some
threshold level. The distribution of the bugs would have to take into
account the work-load of the Bug Triage members and distribute them evenly
but perhaps that's a bit too complicated to do in code. Maybe random
assignment would be better or it could based on the package selection
preferences of individual members. Perhaps there could even be some senior
Bug Control members who would manually assign the bugs from the queue.
 This would eliminate the need for Bug Triage members to even need to go to
Launchpad to search for bugs unless they're doing some extra research.
 Bugs would be sent to them via email automatically when they're ready to
be triaged and auto-assigned without any extra steps needed.

Conclusion:

If the above steps were implemented or some equivalent processes I think
the Bug Triage would be streamlined, eliminate redundancy and get faster
turn-around times.  Bug Triage members would be more focused and
successful. Newer Bug Triage members would be able to be "plugged in" to a
standardized process and this would improve retention because people would
see results faster with less effort.

Hopefully my feedback and comments had some value and will be considered
for the upcoming changes to the Bug Control team and it's processes. If
there are any other ways I can help the newly combined Q/A and Bug Control
please let me know.  Thank you for your time and attention.

Best regards,
AG







On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> Thanks to everyone for the feedback. Given the positive responses I would
> like to move forward with the change. To help facilitate all the little
> odds and ends of transitioning, I've created a blueprint for the upcoming
> UDS:
>
> https://blueprints.launchpad.net/ubuntu/+spec/community-
> 1311-quality-bugsquad
>
> We'll discuss how to transition l

Fwd: Landing plan - Monday 4th November

[Nicholas Skaggs]

Just an FYI -- we have been trying to stage 1.4 ready branches for all 
of the core apps. Still there will be some turbelence as this happens 
and you might find yourself unable to merge code. Feel free to ping 
myself, balloons, on IRC or send an email if you get stuck. Otherwise be 
patient, and we'll all come out the other side in better shape :-)


Currently some of the core apps tests are failing, and that will be an 
issue with the transition as well. We need to stabilize all the core 
apps tests; it makes porting to 1.4 easier and will ensure our port work 
was successful. Please hold off on committing to trunk during the 1.4 
conversion time window. I'll send another email once it is complete and 
you can merge again.


In this last hours leading up to the merge, please check your autopilot 
tests. If they are failing, let's get them fixed in preperation for the 
1.4 migration.


http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/11:20131104:20131031.1/4885/


Nicholas


 Original Message 
Subject:Landing plan - Monday 4th November
Date:   Mon, 04 Nov 2013 11:47:05 +0100
From:   Didier Roche 
To: ubuntu-ph...@lists.launchpad.net
CC: 	Thomi Richards , Nicholas Skaggs 
, Bill Filler 
, Zoltan Balogh 
, Kevin Gunn , 
Francis Ginther , Julien Funk 





Hey everyone,

As you probably saw on the phone mailing list. We were finally available
to promote a new trusty image #10 (the last pieces making unity8 not
passing wasn't due to the image itself).
This image contains (from previous unpromoted ones) a lot application
design adjustments as well as transitions from trusty itself.
We are getting a very good autopilot test pass rate: 96% on both mako
and maguro.
We'll keep people on the stable channel on saucy until next week.

We kicked image #11 to check what the transition brought to us during
the week-end. In the meantime, we are checking the remaining tests not
passing (core apps for most of them).

As well, we prepare transitioning to autopilot 1.4, which is not
backward compatible with 1.3. The plan is:
- on Tuesday, we will release all impacted components (~15 of them).
Team leads are responsible, as discussed last week, to ensure their
trunk is releasable by then. The impacted components are mostly apps,
unity8 and sdk. I think balloon will coordinate the Core Apps side.
Then, nothing enters those trunks anymore.
- end of Tuesday, we put autopilot 1.4, autopilot-gtk 1.4, autopilot-qt
1.4 and xpathselect 1.4 in the daily-build ppa.
- Wednesday (NZ time): Thomi is going, with the QA team support, to
merge every 1.4 branch in those cmoponents
- Wednesday (Europe time), we are going to release those and kick off an
image.
- Finally, we'll give the green light to all upstreams telling that they
are ready to merge back to those trunks against.

Thanks for your cooperation during this transition.

Cheers,
Didier



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

Re: New member from India

[Jack Ramsay]

Yeah welcome hope you have fun


On Monday, November 4, 2013, Samuel Gabbay wrote:

> Welcome to the Team Shubham!
>
>
> 2013/11/4 Nicholas Skaggs 
>
>  Shubham, welcome to the team! Wonderful to have you. We like new people
> and new faces :-)
>
> For all the ways you can help now that you've got an install have a look
> at this page:
>
> https://wiki.ubuntu.com/QATeam/Roles/Tester#Activities
>
> I trust it will answer a few of your questions. Trusty is still early in
> development, but it's never too early to start testing.
>
> Thanks!
>
> Nicholas
>
>
> On 11/04/2013 03:02 AM, Shubham Rao wrote:
>
> Thanks to all for the links, I'll just be testing them now
>
> With Regards,
> *Shubham Rao*
>
>
> On 4 November 2013 00:06, Jackson Doak  wrote:
>
> Welcome Shubham,
>
>  The iso tests are up as elfy said, and the package tests are at
> http://packages.qa.ubuntu.com/qatracker/milestones/306/builds
> Looks like you might (just) be the youngest member of the QA team.
>
>
>  On Mon, Nov 4, 2013 at 5:13 AM, Elfy  wrote:
>
>   On 03/11/13 17:01, Shubham Rao wrote:
>
> When will the testcases arrive? Its nice to get into semi-robotic mode and
> test images!!
>
> With Regards,
> *Shubham Rao*
>
>
>
>
>  First - welcome to the team :)
>
> Not quite sure what you mean by that?
>
> We are still pre-Alpha, but daily images are there in some state and the
> testcase for those derivatives I look at are already at the tracker [1].
>
> Elfy
>
> [1] http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
>
> --
> Ubuntu Forum Council Member
> Xubuntu QA Lead
>
>
>  --
> Ubuntu-quality mailing list
>
>

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

Re: New member from India

[Samuel Gabbay]

Welcome to the Team Shubham!


2013/11/4 Nicholas Skaggs 

>  Shubham, welcome to the team! Wonderful to have you. We like new people
> and new faces :-)
>
> For all the ways you can help now that you've got an install have a look
> at this page:
>
> https://wiki.ubuntu.com/QATeam/Roles/Tester#Activities
>
> I trust it will answer a few of your questions. Trusty is still early in
> development, but it's never too early to start testing.
>
> Thanks!
>
> Nicholas
>
>
> On 11/04/2013 03:02 AM, Shubham Rao wrote:
>
> Thanks to all for the links, I'll just be testing them now
>
> With Regards,
> *Shubham Rao*
>
>
> On 4 November 2013 00:06, Jackson Doak  wrote:
>
>> Welcome Shubham,
>>
>>  The iso tests are up as elfy said, and the package tests are at
>> http://packages.qa.ubuntu.com/qatracker/milestones/306/builds
>> Looks like you might (just) be the youngest member of the QA team.
>>
>>
>>  On Mon, Nov 4, 2013 at 5:13 AM, Elfy  wrote:
>>
>>>   On 03/11/13 17:01, Shubham Rao wrote:
>>>
>>> When will the testcases arrive? Its nice to get into semi-robotic mode
>>> and test images!!
>>>
>>> With Regards,
>>> *Shubham Rao*
>>>
>>>
>>>
>>>
>>>  First - welcome to the team :)
>>>
>>> Not quite sure what you mean by that?
>>>
>>> We are still pre-Alpha, but daily images are there in some state and the
>>> testcase for those derivatives I look at are already at the tracker [1].
>>>
>>> Elfy
>>>
>>> [1] http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
>>>
>>> --
>>> Ubuntu Forum Council Member
>>> Xubuntu QA Lead
>>>
>>>
>>>  --
>>> Ubuntu-quality mailing list
>>> Ubuntu-quality@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>>
>>>
>>
>> --
>> Ubuntu-quality mailing list
>> Ubuntu-quality@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>
>>
>
>
>
>
> --
> Ubuntu-quality mailing list
> Ubuntu-quality@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>
>
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Social Media Links on The Wiki Area

[Ali Linx (amjjawad)]

On Mon, Nov 4, 2013 at 7:11 PM, Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

>  oO, pretty! Thanks Ali! Definitely brightens up the page!
>
> Nicholas
>

Glad you liked it too, Nicholas :)


-- 
Remember: "All of us are smarter than any one of us."
Best Regards,
amjjawad 
Areas of Involvement 
My Projects 
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Social Media Links on The Wiki Area

[Ali Linx (amjjawad)]

On Sun, Nov 3, 2013 at 10:08 PM, Elfy  wrote:

>  On 03/11/13 17:16, Ali Linx (amjjawad) wrote:
>
>  Thanks :)
>
>  You welcome :)
>
>
>>
>>
>> If you've got smaller ones, more the size of icons already on the page,
>> they might look more in tune with the page.
>>
>> If you've not - no matter, I'll look at them over the next couple of days.
>>
>> Elfy
>>
>
>  How about now?
> https://wiki.ubuntu.com/QATeam/Contact#Social_Media
>
>
>  Here is where I got it from:
> https://wiki.ubuntu.com/UbuntuGNOME/Artwork/Graphics#Social_media
>  Thanks to our Artwork Team Leader (Alfredo) who made such very nice
> icons :)
>
>  Is it okay now?
>
> --
>   Remember: "All of us are smarter than any one of us."
> Best Regards,
>  amjjawad 
>  Areas of Involvement
>  My Projects 
>
>
> Yea that looks much more balanced, or at least to me it does :)
>
> Cheers - that's something I can forget about remembering then lol
>
> Elfy
>
> --
> Ubuntu Forum Council Member
> Xubuntu QA Lead
>
> Hi,

Glad you liked it, Elfy ;)

Thank you!

-- 
Remember: "All of us are smarter than any one of us."
Best Regards,
amjjawad 
Areas of Involvement 
My Projects 
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: New member from India

[Nicholas Skaggs]

Shubham, welcome to the team! Wonderful to have you. We like new people 
and new faces :-)


For all the ways you can help now that you've got an install have a look 
at this page:


https://wiki.ubuntu.com/QATeam/Roles/Tester#Activities

I trust it will answer a few of your questions. Trusty is still early in 
development, but it's never too early to start testing.


Thanks!

Nicholas

On 11/04/2013 03:02 AM, Shubham Rao wrote:

Thanks to all for the links, I'll just be testing them now

With Regards,
*Shubham Rao*


On 4 November 2013 00:06, Jackson Doak > wrote:


Welcome Shubham,

The iso tests are up as elfy said, and the package tests are at
http://packages.qa.ubuntu.com/qatracker/milestones/306/builds
Looks like you might (just) be the youngest member of the QA team.


On Mon, Nov 4, 2013 at 5:13 AM, Elfy mailto:ub.u...@btinternet.com>> wrote:

On 03/11/13 17:01, Shubham Rao wrote:

When will the testcases arrive? Its nice to get into
semi-robotic mode and test images!!

With Regards,
*Shubham Rao*





First - welcome to the team :)

Not quite sure what you mean by that?

We are still pre-Alpha, but daily images are there in some
state and the testcase for those derivatives I look at are
already at the tracker [1].

Elfy

[1] http://iso.qa.ubuntu.com/qatracker/milestones/308/builds

-- 
Ubuntu Forum Council Member

Xubuntu QA Lead


--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com

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



--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com

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






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

Re: Introduction

[Nicholas Skaggs]

Welcome Monika! I'll just echo what the others have said about starting 
off by getting a development install of ubuntu going. Once you are 
setup, have a look at this page to see what all you can do to help:


https://wiki.ubuntu.com/QATeam/Roles/Tester

After you've spent some time learning to be a tester you can explore 
some of the other roles and activities, 
https://wiki.ubuntu.com/QATeam/Roles/. Don't be afraid to try new things 
and ask questions! It's the best way to learn. Thanks for helping make 
ubuntu better!


Nicholas

On 11/03/2013 09:31 AM, Monika Schrenk wrote:

Hi everybody,

I'm new to the Ubuntu Quality Team, so I want to introduce myself to 
all of you.


I'm Monika from Austria, 26 years old, student of computer science and 
working at the service line of an Austrian telecommunication provider.


I'm using Ubuntu and Arch since a few months. Before, I was using Mac 
OSX. I want to help improving Ubuntu on Apple devices and to help to 
make Ubuntu even better than it is already in general ;) I have no 
experience in testing yet, but I'm willing to learn all about it and 
start from scratch.


Hope to have a good cooperation with you!

Yours, Monika






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

Re: Social Media Links on The Wiki Area

[Nicholas Skaggs]

oO, pretty! Thanks Ali! Definitely brightens up the page!

Nicholas

On 11/03/2013 01:08 PM, Elfy wrote:

On 03/11/13 17:16, Ali Linx (amjjawad) wrote:

Thanks :)

You welcome :)



If you've got smaller ones, more the size of icons already on the
page, they might look more in tune with the page.

If you've not - no matter, I'll look at them over the next couple
of days.

Elfy


How about now?
https://wiki.ubuntu.com/QATeam/Contact#Social_Media


Here is where I got it from: 
https://wiki.ubuntu.com/UbuntuGNOME/Artwork/Graphics#Social_media
Thanks to our Artwork Team Leader (Alfredo) who made such very nice 
icons :)


Is it okay now?

--
Remember: "All of us are smarter than any one of us."
Best Regards,
amjjawad 
Areas of Involvement 


My Projects 


Yea that looks much more balanced, or at least to me it does :)

Cheers - that's something I can forget about remembering then lol

Elfy
--
Ubuntu Forum Council Member
Xubuntu QA Lead




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

Re: Ubuntu for Tablets Testing

[Nicholas Skaggs]

Frank,

It sounds like you already have installed ubuntu touch? If not, here's 
the information you need: https://wiki.ubuntu.com/Touch/Install


Then have a look at how you can help test the image: 
https://wiki.ubuntu.com/QATeam/TouchTesting


Use it regularly and provide feedback and bug reports. Thanks for 
helping make ubuntu better!


Nicholas

On 11/03/2013 05:37 PM, Frank Slezak wrote:

Hello.

I am an avid user of Ubuntu and simply love it.

Recently I downloaded Ubuntu Touch onto my Asus Nexus 7 and thought it 
was pretty impressive.


However, I noticed you had a "Ubuntu Tablets" project going on.

I wonder if it would be possible for me to get a "Preinstalled ROM" of 
the Ubuntu Tablet project for my Nexus 7. I am interested in testing 
the OS and potentially developing on it.


Thank you,
Frank Slezak






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

Re: [Ubuntu-phone] Trusty image 10 (20131031.1) now available

[Jani Monoses]

Hi,

how hard would it be to provide merged changelog files between released
images as opposed to the separate daily builds?
For regression testing it may help easily finding the changes that
introduced a bug based only on users reporting the image number they were
using.

Jani


On Mon, Nov 4, 2013 at 12:06 PM, Alan Pope  wrote:

> Hi,
>
> Trusty image #10 is now available. The following changelogs detail the
> updates since the last promoted image #5 (20131024).
>
> http://people.canonical.com/~j-lallement/touch/changes/20131025.html
> http://people.canonical.com/~j-lallement/touch/changes/20131029.html
> http://people.canonical.com/~j-lallement/touch/changes/20131029.1.html
> http://people.canonical.com/~j-lallement/touch/changes/20131031.html
> http://people.canonical.com/~j-lallement/touch/changes/20131031.1.html
>
> Please update your device and test.
>
> Cheers,
> --
> Alan Pope
> Engineering Manager
>
> Canonical - Product Strategy
> +44 (0) 7973 620 164
> alan.p...@canonical.com
> http://ubuntu.com/
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to : ubuntu-ph...@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> 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

Re: [Ubuntu-phone] Trusty image 10 (20131031.1) now available

[Jean-Baptiste Lallement]

On 11/04/2013 11:15 AM, Jani Monoses wrote:

Hi,

how hard would it be to provide merged changelog files between released
images as opposed to the separate daily builds?
Not hard, it is essentially a matter of spending time on this script 
which was was not supposed to survive 13.10 :)
But since it is still alive I'll do the update, and try to move it to a 
more reliable place than my desktop.



For regression testing it may help easily finding the changes that
introduced a bug based only on users reporting the image number they
were using.

Jani


On Mon, Nov 4, 2013 at 12:06 PM, Alan Pope mailto:alan.p...@canonical.com>> wrote:

Hi,

Trusty image #10 is now available. The following changelogs detail the
updates since the last promoted image #5 (20131024).

http://people.canonical.com/~j-lallement/touch/changes/20131025.html
http://people.canonical.com/~j-lallement/touch/changes/20131029.html
http://people.canonical.com/~j-lallement/touch/changes/20131029.1.html
http://people.canonical.com/~j-lallement/touch/changes/20131031.html
http://people.canonical.com/~j-lallement/touch/changes/20131031.1.html

Please update your device and test.

Cheers,
--
Alan Pope
Engineering Manager

Canonical - Product Strategy
+44 (0) 7973 620 164 
alan.p...@canonical.com 
http://ubuntu.com/

--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-ph...@lists.launchpad.net

Unsubscribe : https://launchpad.net/~ubuntu-phone
More help   : https://help.launchpad.net/ListHelp







--
Jean-Baptiste
IRC: jibel

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

Trusty image 10 (20131031.1) now available

[Alan Pope]

Hi,

Trusty image #10 is now available. The following changelogs detail the
updates since the last promoted image #5 (20131024).

http://people.canonical.com/~j-lallement/touch/changes/20131025.html
http://people.canonical.com/~j-lallement/touch/changes/20131029.html
http://people.canonical.com/~j-lallement/touch/changes/20131029.1.html
http://people.canonical.com/~j-lallement/touch/changes/20131031.html
http://people.canonical.com/~j-lallement/touch/changes/20131031.1.html

Please update your device and test.

Cheers,
-- 
Alan Pope
Engineering Manager

Canonical - Product Strategy
+44 (0) 7973 620 164
alan.p...@canonical.com
http://ubuntu.com/

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

Ubuntu for Tablets Testing

[Frank Slezak]

Hello.

I am an avid user of Ubuntu and simply love it.

Recently I downloaded Ubuntu Touch onto my Asus Nexus 7 and thought it 
was pretty impressive.


However, I noticed you had a "Ubuntu Tablets" project going on.

I wonder if it would be possible for me to get a "Preinstalled ROM" of 
the Ubuntu Tablet project for my Nexus 7. I am interested in testing the 
OS and potentially developing on it.


Thank you,
Frank Slezak



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

Re: New member from India

[Shubham Rao]

Thanks to all for the links, I'll just be testing them now

With Regards,
*Shubham Rao*


On 4 November 2013 00:06, Jackson Doak  wrote:

> Welcome Shubham,
>
> The iso tests are up as elfy said, and the package tests are at
> http://packages.qa.ubuntu.com/qatracker/milestones/306/builds
> Looks like you might (just) be the youngest member of the QA team.
>
>
> On Mon, Nov 4, 2013 at 5:13 AM, Elfy  wrote:
>
>>  On 03/11/13 17:01, Shubham Rao wrote:
>>
>> When will the testcases arrive? Its nice to get into semi-robotic mode
>> and test images!!
>>
>> With Regards,
>> *Shubham Rao*
>>
>>
>>
>>
>> First - welcome to the team :)
>>
>> Not quite sure what you mean by that?
>>
>> We are still pre-Alpha, but daily images are there in some state and the
>> testcase for those derivatives I look at are already at the tracker [1].
>>
>> Elfy
>>
>> [1] http://iso.qa.ubuntu.com/qatracker/milestones/308/builds
>>
>> --
>> Ubuntu Forum Council Member
>> Xubuntu QA Lead
>>
>>
>> --
>> Ubuntu-quality mailing list
>> Ubuntu-quality@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>
>>
>
> --
> Ubuntu-quality mailing list
> Ubuntu-quality@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>
>
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality