Re: Package QA Tracker

[flocculant]

On 18/08/15 21:44, Nicholas Skaggs wrote:
It can be setup anyway you wish. Historically it's been found useful 
to retain the results for an entire cycle at once for packages. When 
we removed older results, we got duplicate bugs and it was harder to 
see what had been touched and what had not. It would be interesting to 
have a discussion about how you want to use the tracker and what would 
be the most useful to you. It's likely we can make the changes you 
want without needing to make changes to the site/code. It would simply 
require a quorum among those who use it.



Or.

Something not needing quorum would be to have to work like the image 
tracker.


Xubuntu have both types at our bit of that tracker.

http://iso.qa.ubuntu.com/qatracker/milestones/340/builds

64 and 32 bit refresh daily. The core package doesn't - just sits there 
for a whole cycle.


If we did that then one flavours preference wouldn't affect anyone else.

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

Re: Package QA Tracker

[Simon Quigley]

I guess it would be great if the Package QA Tracker worked like this in my
opinion.

People can submit QA results like usual. Every 24 hours minimum(when all
the results are submitted for each individual set, passed or failed, like
for Lubuntu Desktop, Ubuntu GNOME, etc) the QA tracker could go through
this cycle:

If a result is passed, just a reset of that specific test case. Allow for
new submissions. If a package is working perfectly fine, why hold it back?

If a result is failed, until the bug is fixed, the test case would stay the
same, but no duplicate test results(if the same bug is found, just a "me
too" in Launchpad, if it is a new bug, a new test case like normal). We
could use the existing function that you can view the details of the bug
with when you hover to get that running. Another alternative option for
this would be to just have a history and before submitting test cases with
bugs, you had to take a look at the history to see what bugs were reported.
Although this alternative option probably wouldn't work, a history
nonetheless is a good idea.

And for the release cycles, if one of these cycles(the proposed cycle)
happen to fall in between these checkpoints, then there should be a way to
indicate, "This was in Alpha, this was in Beta", etc.

I am open to any and all ideas, so feel free to leave feedback.

-- 
Have a nice day,
Simon Quigley
-- 
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality

Re: Package QA Tracker

[Nicholas Skaggs]

It can be setup anyway you wish. Historically it's been found useful to
retain the results for an entire cycle at once for packages. When we
removed older results, we got duplicate bugs and it was harder to see what
had been touched and what had not. It would be interesting to have a
discussion about how you want to use the tracker and what would be the most
useful to you. It's likely we can make the changes you want without needing
to make changes to the site/code. It would simply require a quorum among
those who use it.

So do you want the package tracker to have milestones during the cycle?
Reset once a month? Something else? What about having the old results
bothers you?

On Sun, Aug 16, 2015 at 1:26 PM, Walter Lapchynski  wrote:

> I'm all ears, Nick!
>
> @wxl | http://polka.bike
> Lubuntu Release Manager & Head of QA
> Ubuntu PPC Point of Contact
> Ubuntu Oregon Team Leader
> Ubuntu Membership Board & LoCo Council Member
> Eugene Unix & GNU/Linux User Group Co-organizer
> On Aug 16, 2015 9:44 AM,  wrote:
>
>> On 16/08/15 17:27, Walter Lapchynski wrote:
>>
>>>
>>> so it resets every month?
>>>
>>> No.
>>
>> It doesn't reset at all. Just finishes at cycle end and then starts again.
>>
>> Nick can tell you more about why it was set up as it is.
>>
>>>
>>> @wxl | http://polka.bike
>>> Lubuntu Release Manager & Head of QA
>>> Ubuntu PPC Point of Contact
>>> Ubuntu Oregon Team Leader
>>> Ubuntu Membership Board & LoCo Council Member
>>> Eugene Unix & GNU/Linux User Group Co-organizer
>>>
>>> On Aug 16, 2015 12:16 AM, >> floccul...@gmx.co.uk>> wrote:
>>>
>>> On 15/08/15 16:35, Simon Quigley wrote:
>>>
>>>
>>> If a test result for a package in week 1 of a dev cycle
>>> shows a
>>> fail and has a bug filed against it why is that invalid in
>>> week 20
>>> if it hasn't been fixed?
>>>
>>> My point wasn't that. Then the QA person would have to
>>> reattach the bug(not so hard if there was somewhat of a history).
>>>
>>> I'm not really sure how removing test results for a cycle
>>> is useful.
>>>
>>> I would expect QA people to know if a bug reported against a
>>> package is still relevant or not.
>>>
>>> ​
>>> ​Because of regression. If there is package regression and the
>>> QA tracker shows a passed result, then it would be a little
>>> confusing to see a bug report
>>> ​ concerning the same package ​
>>> by the same person, don't you think?​
>>> ​
>>>
>>> Or I would be pleased to be in a position to know that it was a
>>> regression because I could simply see that the same thing passed
>>> last month ;)
>>>
>>>
>>> -- Have a nice day,
>>> Simon Quigley
>>>
>>>
>>> -- 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