Help
Leonardo Liao
blue_w1nter at hotmail.com
Wed Jan 22 21:50:07 UTC 2014
On Jan 23, 2014 7:13 AM, ubuntu-quality-request at lists.ubuntu.com wrote:
Send Ubuntu-quality mailing list submissions to
ubuntu-quality at lists.ubuntu.com
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
or, via email, send a message with subject or body 'help' to
ubuntu-quality-request at lists.ubuntu.com
You can reach the person managing the list at
ubuntu-quality-owner at lists.ubuntu.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ubuntu-quality digest..."
Today's Topics:
1. Re: Freshman to mail list (Peng An)
2. Some points on the Wiki for Bug(squad|control) (C de-Avillez)
3. Re: Some points on the Wiki for Bug(squad|control)
(Brendan Donegan)
4. Fwd: [Ubuntu-phone] Core app hack days are coming back!
(Nicholas Skaggs)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Jan 2014 21:35:39 +0800
From: Peng An <wenpengan at gmail.com>
To: Jackson Doak <noskcaj at ubuntu.com>
Cc: "ubuntu-quality at lists.ubuntu.com"
<ubuntu-quality at lists.ubuntu.com>
Subject: Re: Freshman to mail list
Message-ID:
<CAJ6_He1QKubaZAB=Z=uxDWn_xOkHOG2yHvdUVBOh3sYGFxqA5A at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Jackson,
Sorry for later, I have just COB now. I have not used the irc before, I am
reading the manu..
2014/1/22 Jackson Doak <noskcaj at ubuntu.com>
> Welcome Alex,
> Is there anything in particular you'd like to do in the QA team?
> https://wiki.ubuntu.com/QATeam/Roles has a decent overview of what we do.
> If you know python, both testdrive and autopilot have a lot of stuff in
> progress.
>
> If you have any questions about this, ask. Most of us are also on irc, if
> you want to contact us that way.
>
>
> On Wed, Jan 22, 2014 at 5:16 PM, Peng An <wenpengan at gmail.com> wrote:
>
>> Hi,
>>
>> Glad to meet you.
>>
>> First, let me introduce myself.
>> 1, I have worked at a Server Vendor 5+ years.
>> 2, I have 5+ years QA experience, about HW/BMC/Windows/Linux/BIOS.
>> 3, I have 3+ years Test plan/Case writing, and familiar with Test Drive.
>> 4, I have coworked with Dell, HP, Lenovo and Google for many years
>> 5, I have used Ubuntu for more 3 years.
>>
>> And now, I want to contribute to Open Source, so I want to join the QA
>> team.
>> If you have any questions and suggestions, please donot hesitate to
>> contact me.
>>
>> Alex,
>>
>>
>>
>> --
>> Ubuntu-quality mailing list
>> Ubuntu-quality at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/651f7741/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 22 Jan 2014 08:51:04 -0600
From: C de-Avillez <hggdh2 at ubuntu.com>
To: <ubuntu-quality at lists.ubuntu.com>,
<ubuntu-bugsquad at lists.ubuntu.com>
Subject: Some points on the Wiki for Bug(squad|control)
Message-ID: <20140122085104.57ce8400 at icatu>
Content-Type: text/plain; charset="us-ascii"
Hello folks
TL;DR -- do not assign bugs to other people.
I noticed, a few days ago, some edits on the Bugs/* namespace. In
general, good work, and a good consolidation on the multiple (and
almost, but not completely identical) pages.
There was, though, a edit that I do not agree with. So, to start, let's
posit two principles (and I am talking about triaging here):
* 1. The documentation about how to deal with bugs in Ubuntu is
contained (or pointed to from) in the Wiki, under the Bugs namespace;
* 2. NOWHERE else is a good place.
Simple principles. The whole idea, after all, is to allow anyone,
either starting to help or trying to remember things, a *single* place
to go to find information.
So, back to the issue at hand. This edit dealt with Bug
status and, on reading it, I noticed that a restriction we had in
place for quite a long time was not there anymore.
This restriction goes as follows: "in general, NEVER assign a bug to
somebody else."
So I edited the page, and added it back [1].
I was surprised to find, later, a re-edit of the page with this
restriction taken out again [2], with a a comment "As seen it
<tinyurl.com/pm76zuw>, this is not true in all cases."
That is not the issue. The issue is one should NOT assign bugs to other
people. There are some reasons for this:
* I see no problem with assigning bugs to teams (or projects): teams
(and projects) usually survive changes. People join, and leave,
teams and projects -- their interests changes --, but the teams (and
projects) tend to stay.
* this has been heavily abused in the past; we were all tired of
finding ourselves with a new bug assigned to us *even* when it was
not our area/interest/responsibility.
* in the same vein, I do not need other people to decide what I have
to do *without* contacting me first to see if I agree. This is
really, really, bad manners.
The restriction was there for a reason. It should be back there (but I
am not going to re-edit the page, and start a silly "you are wrong; no
YOU are wrong" wiki edit battle).
And on the comment ("As seen it <tinyurl.com/pm76zuw>, this is not true
in all cases."): It does not matter. We may see a series of rules on How
To Assign A Bug To Other People in thousands of pages in the web.
But, for triaging, the ONLY VALID PLACE is under the Bugs/* namespace,
at https://wiki.ubuntu.com.
This also show WHY having a single point for triaging (and, in general,
for documentation) is a better option. I , personally, cannot understand
why would anyone have thought to go to askubuntu.com to ask how to
triage a bug. And, worse, why would anyone answer there giving a
*different* process, and NOT update the wiki?
And this brings another point: these pages provide GENERAL guidance. I
certainly do not want to see them grow without limit so that evey
single minuscule aspect of triaging can be documented. But I can
accept redirection to more specific pages (as long as we do not grow
*these* pages without bounds).
This is it. It is partially a rant, partially a -- for me -- reasonable
request.
Cheers,
..C..
[1]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html
[2]
https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html
--
ab alio expectes alteri quod feceris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/7d203719/attachment-0001.pgp>
------------------------------
Message: 3
Date: Wed, 22 Jan 2014 15:15:54 +0000
From: Brendan Donegan <brendan.donegan at canonical.com>
To: ubuntu-quality at lists.ubuntu.com
Subject: Re: Some points on the Wiki for Bug(squad|control)
Message-ID: <52DFE0AA.8020309 at canonical.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 22/01/14 14:51, C de-Avillez wrote:
>
> Hello folks
>
> TL;DR -- do not assign bugs to other people.n
Looks like a poor interpretation of the wiki. If we say 'in *general*
NEVER assign a but to somebody else' that actually means that there may
be specific cases where it can be done, such as the entry on askubuntu
http://askubuntu.com/questions/231230/how-do-i-get-design-input-on-a-paper-cut/231231#231231
which discusses a *very* specific case where assigning to a user is
allowed - which should be interpreted as 'in this specific case, the
user 'Nick Tait' gives you his implicit permission to assign papercut
bugs to him' - not 'oh hey, in general you can just assign bugs to
whoever you want'. Anyway having a process where a bug is assigned to a
named user is dubious so that should be changed.
>
> I noticed, a few days ago, some edits on the Bugs/* namespace. In
> general, good work, and a good consolidation on the multiple (and
> almost, but not completely identical) pages.
>
> There was, though, a edit that I do not agree with. So, to start, let's
> posit two principles (and I am talking about triaging here):
>
> * 1. The documentation about how to deal with bugs in Ubuntu is
> contained (or pointed to from) in the Wiki, under the Bugs namespace;
> * 2. NOWHERE else is a good place.
>
> Simple principles. The whole idea, after all, is to allow anyone,
> either starting to help or trying to remember things, a *single* place
> to go to find information.
>
> So, back to the issue at hand. This edit dealt with Bug
> status and, on reading it, I noticed that a restriction we had in
> place for quite a long time was not there anymore.
>
> This restriction goes as follows: "in general, NEVER assign a bug to
> somebody else."
>
> So I edited the page, and added it back [1].
>
> I was surprised to find, later, a re-edit of the page with this
> restriction taken out again [2], with a a comment "As seen it
> <tinyurl.com/pm76zuw>, this is not true in all cases."
>
> That is not the issue. The issue is one should NOT assign bugs to other
> people. There are some reasons for this:
> * I see no problem with assigning bugs to teams (or projects): teams
> (and projects) usually survive changes. People join, and leave,
> teams and projects -- their interests changes --, but the teams (and
> projects) tend to stay.
> * this has been heavily abused in the past; we were all tired of
> finding ourselves with a new bug assigned to us *even* when it was
> not our area/interest/responsibility.
> * in the same vein, I do not need other people to decide what I have
> to do *without* contacting me first to see if I agree. This is
> really, really, bad manners.
>
> The restriction was there for a reason. It should be back there (but I
> am not going to re-edit the page, and start a silly "you are wrong; no
> YOU are wrong" wiki edit battle).
>
> And on the comment ("As seen it <tinyurl.com/pm76zuw>, this is not true
> in all cases."): It does not matter. We may see a series of rules on How
> To Assign A Bug To Other People in thousands of pages in the web.
> But, for triaging, the ONLY VALID PLACE is under the Bugs/* namespace,
> at https://wiki.ubuntu.com.
>
> This also show WHY having a single point for triaging (and, in general,
> for documentation) is a better option. I , personally, cannot understand
> why would anyone have thought to go to askubuntu.com to ask how to
> triage a bug. And, worse, why would anyone answer there giving a
> *different* process, and NOT update the wiki?
>
> And this brings another point: these pages provide GENERAL guidance. I
> certainly do not want to see them grow without limit so that evey
> single minuscule aspect of triaging can be documented. But I can
> accept redirection to more specific pages (as long as we do not grow
> *these* pages without bounds).
>
> This is it. It is partially a rant, partially a -- for me -- reasonable
> request.
>
> Cheers,
>
> ..C..
>
>
> [1]
> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004438.html
> [2]
> https://lists.ubuntu.com/archives/ubuntu-bugsquad/2014-January/004436.html
>
>
>
------------------------------
Message: 4
Date: Wed, 22 Jan 2014 15:12:32 -0500
From: Nicholas Skaggs <nicholas.skaggs at canonical.com>
To: "ubuntu-quality at lists.ubuntu.com"
<ubuntu-quality at lists.ubuntu.com>
Subject: Fwd: [Ubuntu-phone] Core app hack days are coming back!
Message-ID: <52E02630.4070304 at canonical.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
I'll be around during these hack days as well. If you want to help
contribute some autopilot tests or hack on the existing tests for these
apps, plan to attend :-)
Nicholas
-------- Original Message --------
Subject: [Ubuntu-phone] Core app hack days are coming back!
Date: Wed, 22 Jan 2014 19:36:26 +0100
From: David Planella <david.planella at ubuntu.com>
To: ubuntu-touch-coreapps <ubuntu-touch-coreapps at lists.launchpad.net>
CC: ubuntu-phone <ubuntu-phone at lists.launchpad.net>
Hi all,
Given the success of the previous Core Apps Hack Days last cycle, we've
decided to bring them back!
Tomorrow we will publish a detailed announcement, but I thought I'd give
an initial heads up to all teams not to catch anyone off-guard.
The tentative schedule is to focus to 2 apps per hack day, as follows:
Friday 24th January:
* Reminders
* Music
Monday, 3rd February
* Calendar
* Shorts
Tuesday, 4th February
* Clock
* Calculator
Wednesday, 5th February
* File Manager
* Doc Viewer
Thursday, 6th February
* Weather
* Terminal
If you're a core app developer and want to help with the preparation,
things that might be useful to lower the barrier of contribution could be:
- Triage bugs in your project, assigning them the priorities you judge
appropriate
- Add tags to group bugs that you can point new contributors too (e.g.
'bitesize', 'ui', etc.)
- ...
You're all very talented and creative developers, so I'm sure you have
your own ideas to bring to the mix too :)
Looking forward to seeing the contributions during the Hack Days!
Cheers,
David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140122/8240904b/attachment.html>
-------------- next part --------------
--
Mailing list: https://launchpad.net/~ubuntu-phone
Post to : ubuntu-phone at lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-phone
More help : https://help.launchpad.net/ListHelp
------------------------------
--
Ubuntu-quality mailing list
Ubuntu-quality at lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
End of Ubuntu-quality Digest, Vol 75, Issue 22
**********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20140123/8c0656a5/attachment-0001.html>
More information about the Ubuntu-quality
mailing list