Re: Cadence Testing For Saucy (Craig Hrabal)
On 22/05/13 19:34, Craig Hrabal wrote:
The mockups are pretty excellent. I would argue that the second
choice is better, and combining them into one looks better visually.
I think the "packages we care about" list should refer mainly to
default pre-installed packages within Ubuntu, obviously with a few
exceptions, as the intent is to make sure the packages that will ship
by default in saucy are as stable as possible.
+1 from me.
-Craig Hrabal
I'd suspect that not everyone will feel quite the same - other than us
/all/ releasing good systems to the world at large, I'd much prefer
that the packages we care most about related to Xubuntu ;)
Message: all
Date: Tue, 21 May 2013 17:48:22 -0400
From: Nicholas Skaggs
To:"ubuntu-quality@lists.ubuntu.com"
Subject: Cadence Testing for Saucy
Message-ID:<519beba6.5010...@canonical.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
So vUDS is behind us and it's time to solidify the cadence testing
schedule for Saucy. I've update the cadence page with actual dates now,
starting June 15th. See the schedule here:
https://wiki.ubuntu.com/QATeam/Cadence/Saucy
Now in addition to that, as part of the
https://blueprints.launchpad.net/ubuntu/+spec/community-s-quality-coverage
blueprint we discussed the idea brought up by crhrabal and smartboyhw
(thanks guys!). The outcome was an idea to change the way we do cadence
testing. The iead was to track all the packages that we care about for
the entire cycle -- things like our list of default applications
firefox, thunderbird, nautilus, etc. As a new build of the package is
published to the archive a new build is entered into the tracker and all
subscribers to that package are notified. I promised to mock up the
idea, and that's what I'm including below for discussion :-)
Let's step back quickly for a moment though. For those not familiar with
last cycle's cadence testing, let me describe it quickly. Every cadence
week we created a milestone and chose packages to test. In addition we
always tested the daily images during that week, as well as sometimes
including a bit of hardware testing against the milestone. The cadence
milestone was only open for the cadence week, after which the results
would be frozen.
Onto the mockups for the new idea! I've laid out two examples of how we
could implement the new idea.
The first shows the idea of lumping all packages into one milestone;
http://packages.qa.dev.stgraber.org/qatracker/milestones/252/builds. If
you then view the history
http://packages.qa.dev.stgraber.org/qatracker/milestones/252/history you
can see every package we're tracking, test results, and bugs. Clicking
on any old build let's you see the details as well.
The second shows the idea of giving each package a milestone;
http://packages.qa.dev.stgraber.org/qatracker/milestones/253/builds. If
you then view the history
http://packages.qa.dev.stgraber.org/qatracker/milestones/253/history you
can see only that package, test results, and bugs. Clicking on any old
build let's you see the details as well.
So what does this new idea do for us?
-- Let's us follow a package for the entire cycle, and provides bugs
linked to versions, and allows you to 'track' the status of the package
in ubuntu
-- Provides a summary report of bugs specific to that package that we've
opened
-- Allows you to subscribe to a package you like/care about and make
sure it's tested
-- Allows you to filter test results / versions / bugs by time
What I'm looking to gather now is if we should switch how we test our
packages as part of our cadence testing to the new system. Let me
describe how it would work.
Each cadence week we would:
-- Test the daily images
-- (Optionally, when requested) Perform laptop/hardware tests against
specific image
-- Test the packages we're tracking and ensure results are entered for
the current builds
The difference is that the milestones would be availible outside of the
'designated' cadence weeks and thus you are free to test the packages at
any time, as always, but you can also now report your results! The
cadence weeks stay a rallying cry towards us committing to test
regularly to ensure the archive, images and packages are in good shape
all throughout the cycle.
So, in summary, let's hear your feedback on:
1) Switching to the new idea for tracking packages all cycle
2) Lumping the packages together or making a milestone for each one
If we do decide to switch, we'll need to create a list of "packages we
care about" :-)
Nicholas
-- next part --
An HTML attachment was scrubbed...
URL:<https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20130521/0726ad4f/attachment.html>
--
I'm in favour of the more detailed options. I assume
Re: Cadence Testing for Saucy
On 05/21/2013 11:48 PM, Nicholas Skaggs wrote: [..] So, in summary, let's hear your feedback on: 1) Switching to the new idea for tracking packages all cycle Well we could give it a try for Saucy and see how it works. The availability of milestones outside of the designated cadence weeks sounds a good idea too. 2) Lumping the packages together or making a milestone for each one I prefer making a milestone for each package, it looks more neat and clear to lookup. If we do decide to switch, we'll need to create a list of "packages we care about" :-) Nicholas Carla -- Carla Sella email: carla.se...@gmail.com https://launchpad.net/~carla-sella http://qa.ubuntu.com/ -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Cadence Testing For Saucy (Craig Hrabal)
The mockups are pretty excellent. I would argue that the second choice
is better, and combining them into one looks better visually.
I think the "packages we care about" list should refer mainly to default
pre-installed packages within Ubuntu, obviously with a few exceptions,
as the intent is to make sure the packages that will ship by default in
saucy are as stable as possible.
+1 from me.
-Craig Hrabal
Message: 5
Date: Tue, 21 May 2013 17:48:22 -0400
From: Nicholas Skaggs
To: "ubuntu-quality@lists.ubuntu.com"
Subject: Cadence Testing for Saucy
Message-ID: <519beba6.5010...@canonical.com>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
So vUDS is behind us and it's time to solidify the cadence testing
schedule for Saucy. I've update the cadence page with actual dates now,
starting June 15th. See the schedule here:
https://wiki.ubuntu.com/QATeam/Cadence/Saucy
Now in addition to that, as part of the
https://blueprints.launchpad.net/ubuntu/+spec/community-s-quality-coverage
blueprint we discussed the idea brought up by crhrabal and smartboyhw
(thanks guys!). The outcome was an idea to change the way we do cadence
testing. The iead was to track all the packages that we care about for
the entire cycle -- things like our list of default applications
firefox, thunderbird, nautilus, etc. As a new build of the package is
published to the archive a new build is entered into the tracker and all
subscribers to that package are notified. I promised to mock up the
idea, and that's what I'm including below for discussion :-)
Let's step back quickly for a moment though. For those not familiar with
last cycle's cadence testing, let me describe it quickly. Every cadence
week we created a milestone and chose packages to test. In addition we
always tested the daily images during that week, as well as sometimes
including a bit of hardware testing against the milestone. The cadence
milestone was only open for the cadence week, after which the results
would be frozen.
Onto the mockups for the new idea! I've laid out two examples of how we
could implement the new idea.
The first shows the idea of lumping all packages into one milestone;
http://packages.qa.dev.stgraber.org/qatracker/milestones/252/builds. If
you then view the history
http://packages.qa.dev.stgraber.org/qatracker/milestones/252/history you
can see every package we're tracking, test results, and bugs. Clicking
on any old build let's you see the details as well.
The second shows the idea of giving each package a milestone;
http://packages.qa.dev.stgraber.org/qatracker/milestones/253/builds. If
you then view the history
http://packages.qa.dev.stgraber.org/qatracker/milestones/253/history you
can see only that package, test results, and bugs. Clicking on any old
build let's you see the details as well.
So what does this new idea do for us?
-- Let's us follow a package for the entire cycle, and provides bugs
linked to versions, and allows you to 'track' the status of the package
in ubuntu
-- Provides a summary report of bugs specific to that package that we've
opened
-- Allows you to subscribe to a package you like/care about and make
sure it's tested
-- Allows you to filter test results / versions / bugs by time
What I'm looking to gather now is if we should switch how we test our
packages as part of our cadence testing to the new system. Let me
describe how it would work.
Each cadence week we would:
-- Test the daily images
-- (Optionally, when requested) Perform laptop/hardware tests against
specific image
-- Test the packages we're tracking and ensure results are entered for
the current builds
The difference is that the milestones would be availible outside of the
'designated' cadence weeks and thus you are free to test the packages at
any time, as always, but you can also now report your results! The
cadence weeks stay a rallying cry towards us committing to test
regularly to ensure the archive, images and packages are in good shape
all throughout the cycle.
So, in summary, let's hear your feedback on:
1) Switching to the new idea for tracking packages all cycle
2) Lumping the packages together or making a milestone for each one
If we do decide to switch, we'll need to create a list of "packages we
care about" :-)
Nicholas
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20130521/0726ad4f/attachment.html>
--
--
Ubuntu-quality mailing list
Ubuntu-quality@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
Re: Cadence Testing for Saucy
make sure testdrive is in it and i'm happy. On Wed, May 22, 2013 at 7:48 AM, Nicholas Skaggs < nicholas.ska...@canonical.com> wrote: > So vUDS is behind us and it's time to solidify the cadence testing > schedule for Saucy. I've update the cadence page with actual dates now, > starting June 15th. See the schedule here: > https://wiki.ubuntu.com/QATeam/Cadence/Saucy > > Now in addition to that, as part of the > https://blueprints.launchpad.net/ubuntu/+spec/community-s-quality-coverageblueprint > we discussed the idea brought up by crhrabal > and smartboyhw (thanks guys!). The outcome was an idea to change the way we > do cadence testing. The iead was to track all the packages that we care > about for the entire cycle -- things like our list of default applications > firefox, thunderbird, nautilus, etc. As a new build of the package is > published to the archive a new build is entered into the tracker and all > subscribers to that package are notified. I promised to mock up the idea, > and that's what I'm including below for discussion :-) > > Let's step back quickly for a moment though. For those not familiar with > last cycle's cadence testing, let me describe it quickly. Every cadence > week we created a milestone and chose packages to test. In addition we > always tested the daily images during that week, as well as sometimes > including a bit of hardware testing against the milestone. The cadence > milestone was only open for the cadence week, after which the results would > be frozen. > > Onto the mockups for the new idea! I've laid out two examples of how we > could implement the new idea. > > The first shows the idea of lumping all packages into one milestone; > http://packages.qa.dev.stgraber.org/qatracker/milestones/252/builds. If > you then view the history > http://packages.qa.dev.stgraber.org/qatracker/milestones/252/history you > can see every package we're tracking, test results, and bugs. Clicking on > any old build let's you see the details as well. > > The second shows the idea of giving each package a milestone; > http://packages.qa.dev.stgraber.org/qatracker/milestones/253/builds. If > you then view the history > http://packages.qa.dev.stgraber.org/qatracker/milestones/253/history you > can see only that package, test results, and bugs. Clicking on any old > build let's you see the details as well. > > So what does this new idea do for us? > -- Let's us follow a package for the entire cycle, and provides bugs > linked to versions, and allows you to 'track' the status of the package in > ubuntu > -- Provides a summary report of bugs specific to that package that we've > opened > -- Allows you to subscribe to a package you like/care about and make sure > it's tested > -- Allows you to filter test results / versions / bugs by time > > What I'm looking to gather now is if we should switch how we test our > packages as part of our cadence testing to the new system. Let me describe > how it would work. > > Each cadence week we would: > -- Test the daily images > -- (Optionally, when requested) Perform laptop/hardware tests against > specific image > -- Test the packages we're tracking and ensure results are entered for the > current builds > > The difference is that the milestones would be availible outside of the > 'designated' cadence weeks and thus you are free to test the packages at > any time, as always, but you can also now report your results! The cadence > weeks stay a rallying cry towards us committing to test regularly to ensure > the archive, images and packages are in good shape all throughout the cycle. > > So, in summary, let's hear your feedback on: > > 1) Switching to the new idea for tracking packages all cycle > 2) Lumping the packages together or making a milestone for each one > > If we do decide to switch, we'll need to create a list of "packages we > care about" :-) > > Nicholas > > -- > 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
Cadence Testing for Saucy
So vUDS is behind us and it's time to solidify the cadence testing schedule for Saucy. I've update the cadence page with actual dates now, starting June 15th. See the schedule here: https://wiki.ubuntu.com/QATeam/Cadence/Saucy Now in addition to that, as part of the https://blueprints.launchpad.net/ubuntu/+spec/community-s-quality-coverage blueprint we discussed the idea brought up by crhrabal and smartboyhw (thanks guys!). The outcome was an idea to change the way we do cadence testing. The iead was to track all the packages that we care about for the entire cycle -- things like our list of default applications firefox, thunderbird, nautilus, etc. As a new build of the package is published to the archive a new build is entered into the tracker and all subscribers to that package are notified. I promised to mock up the idea, and that's what I'm including below for discussion :-) Let's step back quickly for a moment though. For those not familiar with last cycle's cadence testing, let me describe it quickly. Every cadence week we created a milestone and chose packages to test. In addition we always tested the daily images during that week, as well as sometimes including a bit of hardware testing against the milestone. The cadence milestone was only open for the cadence week, after which the results would be frozen. Onto the mockups for the new idea! I've laid out two examples of how we could implement the new idea. The first shows the idea of lumping all packages into one milestone; http://packages.qa.dev.stgraber.org/qatracker/milestones/252/builds. If you then view the history http://packages.qa.dev.stgraber.org/qatracker/milestones/252/history you can see every package we're tracking, test results, and bugs. Clicking on any old build let's you see the details as well. The second shows the idea of giving each package a milestone; http://packages.qa.dev.stgraber.org/qatracker/milestones/253/builds. If you then view the history http://packages.qa.dev.stgraber.org/qatracker/milestones/253/history you can see only that package, test results, and bugs. Clicking on any old build let's you see the details as well. So what does this new idea do for us? -- Let's us follow a package for the entire cycle, and provides bugs linked to versions, and allows you to 'track' the status of the package in ubuntu -- Provides a summary report of bugs specific to that package that we've opened -- Allows you to subscribe to a package you like/care about and make sure it's tested -- Allows you to filter test results / versions / bugs by time What I'm looking to gather now is if we should switch how we test our packages as part of our cadence testing to the new system. Let me describe how it would work. Each cadence week we would: -- Test the daily images -- (Optionally, when requested) Perform laptop/hardware tests against specific image -- Test the packages we're tracking and ensure results are entered for the current builds The difference is that the milestones would be availible outside of the 'designated' cadence weeks and thus you are free to test the packages at any time, as always, but you can also now report your results! The cadence weeks stay a rallying cry towards us committing to test regularly to ensure the archive, images and packages are in good shape all throughout the cycle. So, in summary, let's hear your feedback on: 1) Switching to the new idea for tracking packages all cycle 2) Lumping the packages together or making a milestone for each one If we do decide to switch, we'll need to create a list of "packages we care about" :-) Nicholas -- Ubuntu-quality mailing list Ubuntu-quality@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
