Re: Package QA Tracker
On Wed, Aug 19, 2015 at 4:18 AM, Pasi Lallinaho p...@shimmerproject.org wrote: On 19/08/15 09:27, floccul...@gmx.co.uk wrote: 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. The package tracker can work in the same way as the ISO tracker already; you can add new builds per package at least manually. The problematic part with this are packages that are shared; you can only have one way with one package. In my opinion, if we want non-full-cycle builds, then the builds would have to update automatically and happen only when packages are actually updated. I don't think there is code that could do this currently. The code to do this can be seen in action on the debian installer. It does technically exist, but I'm not sure it's something we want to pursue. http://iso.qa.ubuntu.com/qatracker/milestones/340/builds/98875/testcases It's updated only when a new version is published. Instead of trying to change how the builds work, another option would be adjusting how the current data is laid out. I could see that a version field in the reporting form could get us to similar results as with fiddling with builds if that field was somehow shown in the reported bugs list. This would obviously need new code too, but updates to the bug list have been planned for a long time - this is easily done with those changes. Indeed. Folks interested in solving some of the longstanding bugs, please check out the bug tracker and get in touch here on the list. The site is in drupal. The wiki has everything you need to know to get started ( https://wiki.ubuntu.com/QATeam/Roles/Developer#Developing_the_QA_Trackers) -- 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
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
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
so it resets every month? @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
Re: Package QA Tracker
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 mailto: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 mailto: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
Package QA Tracker
To whom it may concern: Walter and I share a common concern about the packages QA tracker. It would be great if instead of just having the results pile up(therefore eventually making them invalid), if it would reset every so often(anywhere from 36 hours to a week would be phenomenal), then it would make those results more useful to the QA people. -- 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
