It's almost hard to believe, but the new cycle is starting to ramp up. In just over one week's time, we'll be putting out an alpha 1 iso for quantal! If you will remember last cycle, I began an adopt an iso campaign to help insure precise got the iso testing coverage it needed to be an awesome release. This cycle, that campaign will continue with an open call for folks to adopt an iso and help test it all cycle long. Instead of managing and updating all of our excellent testers myself via email, I am asking instead for you to subscribe to the iso your interested in adopting and helping to make sure it's in a ready state for each milestone release. Subscribing to the iso will alert you via email when there is a new build for you ready to test, so you don't need to watch the page or await an email from me. If you miss the email from me, you may of course contact me for personal interactions at anytime you wish :-)
Interested? Awesome! This wiki page should detail everything you need to get started. Specifically, you should ensure you subscribe to the testcases for the iso you wish. For example, if I am interested in Ubuntu Desktop i386, I would head over to this page. See that button at the bottom called subscribe? Hit it and you should be subscribed to new builds for that iso. Please note the subscription feature is a work in progress, and there is not (yet!) a management page for subscriptions. Additionally, there is no visual indication on the page that your subscription is active (contributions welcome, contact me if you know drupal and wish to help!). Please read the wiki page on ISO Testing for more information on confirming your subscription in the interim period.
Ok, great, so now your subscribed. There's just one piece left in making sure things go well for your iso. This cycle we are trying something new to help make the alpha, beta, final release process smoother for all of our iso's (and you!). We would like to have our adopters run the daily iso before we spin the first candidate for release. What this means for you is that the week before each milestone release date, go ahead and try testing out the daily version of the iso. Think of it as warm-up for the big day. After all, you don't want your iso to be the one causing the re-spin do you?
This schedule will come in handy. It shows the timeline for how and when we'll be undertaking this testing. I know it looks big and scary, but focus on just the first column called 'Community Testing'. See the week of May 31st with the 'Q-D' listed by it in the 'Community Testing' column? If you glance at the 'Legend' at the top you will notice that 'Q' stands for quantal, and 'D' stands for daily. You will also notice that the Alpha 1 release for quantal is schedule one week after. So our goal is to spend this week getting our iso's in shape for the first spins for Alpha 1. The good news is time spent now is respins saved later. Happier isos make happier users!
Before I close I do want to remind everyone that each cycle is a marathon. We spoke at UDS about burnout, and that is something to keep in mind. Pace yourself and share the work. We'll have a wonderful cycle together. As always, contact me if you need any help. Your response was overwhelming for ubuntu precise, let's keep going strong for quantal. Thanks for helping make ubuntu better for everyone!
Tuesday, May 29, 2012
Quality in Quantal: A community perspective
I originally posted this wonderful wall of text on the ubuntu-qa mailing list. If you want to get invovled in QA on ubuntu this cycle, you should subscribe to that list. Additionally, sign-up for the ubuntu testing team. Monitoring this blog and @UbuntuTesting will also keep you informed.
ISOTesting
My goal is to help ensure things are smooth before milestones, and
before isotesting events. Before we spin an iso, we want to feel good
about what's going on that iso. And we as a community can help make that
happen. Overall, I want each individual to have a lighter workload than
last cycle, despite having a similar amount of overall work we need to
achieve. To do this I'd like to help enable more people to be testing,
and to expand the 'adopt an iso' program so that folks can focus on
testing things they like and are able to test without becoming
overwhelmed or burnt out. Additionally, respins will be a continuous
focus and communication of what has changed and what needs tested will
be a priority. As a community we want to avoid doing re-work/extra work
and dedicate ourselves to performing quality testing, not merely having
a large quantity of testing.
Application Testing
Last cycle we utilized checkbox to deliver manual application tests.
During UDS, we spoke of expanding the isotracker to do our testcase
management, and thus consolidate our application testing by using the
same tool used for the isotracker to create an application tracker. This
work is on-going, but should be finished at some point during the cycle
so we can adopt it and use it. In the interim period will be continue
utilizing checkbox or doing manual testing via blogs or mailing lists, etc.
SRU Verification
SRU verification is currently a manual process with a high learning
curve and little visibility for many people. During the cycle, we hope
to help change that but also utilizing a new tracker to do SRU testing.
This testing will involve running the stable version (currently precise)
of ubuntu, but testing fixes to individual packages. This makes it a
good fit for those who aren't living on the bleeding edge but wish to
help. When this process is ironed out (sometime during the cycle) I will
contact everyone again with information on howto get involved.
General Testing (eg, Day-to-Day running of the development version)
Some good feedback was given on how to help make this better. There are
a few things we would like to do to help improve this process. First,
day to day changes should be able to be followed easier with some
proposed changes to update-manager to better display changelogs for
updated packages. I'll be detailing some information about how
'whoopsie' works and what it means to you. In addition, keeping the
development release stable at all times will continue to be a priority
for the development teams.
Calls for testing (specific feature or new features of critical package
or focused testing on a specific package)
Last cycle this typically involved me posting and laying out a basic
testplan on my blog with instructions on how to help test. This cycle,
again we hope to consolidate this onto a tracker where the tests and
results can be recorded. I will still be utilizing my blog, the
@ubuntutesting twitter account, this mailing list and our IRC meeting to
publicize events like this for people to get involved and contribute.
It's always fun to see new features before they come to everyone else,
and the feedback loop with the developers was welcome on both sides.
QATracker Development
With these changes to the qatracker, there is room for some folks who
know python and django to get involved and help improve the qatracker
codebase to make testing and reporting easier Contact me, or simply
have a look at the code on launchpad and start hacking.
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite-testcase-management
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker-testcase-management
Hardware Database
The idea for having a hardware database for testing is not a new one,
but work has begun anew. This is work that will go beyond this cycle,
but ideas are being explored at using ubuntu friendly and other tools to
make this a reality.
Testcases
As a testcase management system will soon be in place (hurray!), we'll
be migrating all of the testcases over to this system. That means will
have much better visibility and ease of maintenance for all of our
testcases. Cleanup and expansion of the number of testcases is
definitely a goal for the cycle, and expect to hear more about getting
involved in this area.
Whew, that's a wall of text, but I hope it helps outline what the plans
are for the cycle. Feedback appreciated and encouraged Happy Testing!
ISOTesting
My goal is to help ensure things are smooth before milestones, and
before isotesting events. Before we spin an iso, we want to feel good
about what's going on that iso. And we as a community can help make that
happen. Overall, I want each individual to have a lighter workload than
last cycle, despite having a similar amount of overall work we need to
achieve. To do this I'd like to help enable more people to be testing,
and to expand the 'adopt an iso' program so that folks can focus on
testing things they like and are able to test without becoming
overwhelmed or burnt out. Additionally, respins will be a continuous
focus and communication of what has changed and what needs tested will
be a priority. As a community we want to avoid doing re-work/extra work
and dedicate ourselves to performing quality testing, not merely having
a large quantity of testing.
Application Testing
Last cycle we utilized checkbox to deliver manual application tests.
During UDS, we spoke of expanding the isotracker to do our testcase
management, and thus consolidate our application testing by using the
same tool used for the isotracker to create an application tracker. This
work is on-going, but should be finished at some point during the cycle
so we can adopt it and use it. In the interim period will be continue
utilizing checkbox or doing manual testing via blogs or mailing lists, etc.
SRU Verification
SRU verification is currently a manual process with a high learning
curve and little visibility for many people. During the cycle, we hope
to help change that but also utilizing a new tracker to do SRU testing.
This testing will involve running the stable version (currently precise)
of ubuntu, but testing fixes to individual packages. This makes it a
good fit for those who aren't living on the bleeding edge but wish to
help. When this process is ironed out (sometime during the cycle) I will
contact everyone again with information on howto get involved.
General Testing (eg, Day-to-Day running of the development version)
Some good feedback was given on how to help make this better. There are
a few things we would like to do to help improve this process. First,
day to day changes should be able to be followed easier with some
proposed changes to update-manager to better display changelogs for
updated packages. I'll be detailing some information about how
'whoopsie' works and what it means to you. In addition, keeping the
development release stable at all times will continue to be a priority
for the development teams.
Calls for testing (specific feature or new features of critical package
or focused testing on a specific package)
Last cycle this typically involved me posting and laying out a basic
testplan on my blog with instructions on how to help test. This cycle,
again we hope to consolidate this onto a tracker where the tests and
results can be recorded. I will still be utilizing my blog, the
@ubuntutesting twitter account, this mailing list and our IRC meeting to
publicize events like this for people to get involved and contribute.
It's always fun to see new features before they come to everyone else,
and the feedback loop with the developers was welcome on both sides.
QATracker Development
With these changes to the qatracker, there is room for some folks who
know python and django to get involved and help improve the qatracker
codebase to make testing and reporting easier Contact me, or simply
have a look at the code on launchpad and start hacking.
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/drupal7-rewrite-testcase-management
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker
lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker-testcase-management
Hardware Database
The idea for having a hardware database for testing is not a new one,
but work has begun anew. This is work that will go beyond this cycle,
but ideas are being explored at using ubuntu friendly and other tools to
make this a reality.
Testcases
As a testcase management system will soon be in place (hurray!), we'll
be migrating all of the testcases over to this system. That means will
have much better visibility and ease of maintenance for all of our
testcases. Cleanup and expansion of the number of testcases is
definitely a goal for the cycle, and expect to hear more about getting
involved in this area.
Whew, that's a wall of text, but I hope it helps outline what the plans
are for the cycle. Feedback appreciated and encouraged Happy Testing!
Wednesday, May 23, 2012
Executing on an idea; a UDS story
UDS is now behind us, and the excitement of the work that lies before us for the next cycle is fresh on our minds and hearts. Last cycle I solicited and received some amazing ideas for improving how we as a community do QA inside of ubuntu. As UDS neared I encouraged many of those with ideas to participate in UDS by attending, signing up for work items, and advocating their ideas.
This is a key portion of being a part of the community -- you must be willing to act. If you are unwilling to act upon your own idea, why would anyone else? If you don't believe in it, no one else will. Own the problem you wish to solve and you will find others who share your passion along the way to help you achieve your goals. This is the heart of open source.
But how? How can I act? What if the problem is outside of my skillset? Because of the greater community and the nature of open source, you don't have to solve all of the problem by yourself. As you undertake work to execute your idea, you will find it attracts those who are of like-mind and similar persuasion to you. The best part is that they will have different skillsets to bring to the problem and can help you accomplish more than you could alone.
In a previous job, I was given the freedom to spend a percentage of my time on anything I chose; provided I could convince two of my workmates to help out. The idea behind the requirement was a litmus test for my idea. If the idea has merit, I should be able to convince my colleagues to work on it with me. Ubuntu is one of several open source projects to operate on this idea of 'meritocracy'. The basic premise is to have the best people making the most informed decisions possible about problems specific to there expertise. This is achieved by granting authority to make decisions to anyone who demonstrates there ability to do so by contributing to the project.
So, returning to UDS I would like to tell you a small story of just one example of executing on an idea. Let me introduce Paolo Sammicheli to you. Paolo is from the Italian Loco team, and has been active in driving growth in the localized iso community. He began his work by starting an "Italian Testing Team" several UDS's ago, and has been advocating greater testing and community participation for several cycles now. This past UDS, Paolo wanted to help kickstart a localized iso community beyond just his Italian loco iso. Before UDS, he had already produced a set of wiki pages documenting how to use the isotracker admin features with a bent towards running your own localized iso tracker. Additionally, the Italian loco team planned and tested during the 12.04 cycle to create a localized ubuntu 12.04 image for release. Finally, Paolo came to UDS and created a blueprint so he could share his idea with others. Have a look at it yourself:
https://blueprints.launchpad.net/ubuntu/+spec/community-q-localized-iso-community-growth
Paolo was able to generate good ideas, and see other people attempt to replicate his work within their own locos. Plans were made to have two other loco teams produce localized isos this cycle, and ultimately use there findings as a model for future loco teams. Although the work is on-going this cycle, Paolo, I think, has been successful at bringing his idea to life.
How can you replicate Paolo's example? A couple key points I see in what happened.
This is a key portion of being a part of the community -- you must be willing to act. If you are unwilling to act upon your own idea, why would anyone else? If you don't believe in it, no one else will. Own the problem you wish to solve and you will find others who share your passion along the way to help you achieve your goals. This is the heart of open source.
But how? How can I act? What if the problem is outside of my skillset? Because of the greater community and the nature of open source, you don't have to solve all of the problem by yourself. As you undertake work to execute your idea, you will find it attracts those who are of like-mind and similar persuasion to you. The best part is that they will have different skillsets to bring to the problem and can help you accomplish more than you could alone.
In a previous job, I was given the freedom to spend a percentage of my time on anything I chose; provided I could convince two of my workmates to help out. The idea behind the requirement was a litmus test for my idea. If the idea has merit, I should be able to convince my colleagues to work on it with me. Ubuntu is one of several open source projects to operate on this idea of 'meritocracy'. The basic premise is to have the best people making the most informed decisions possible about problems specific to there expertise. This is achieved by granting authority to make decisions to anyone who demonstrates there ability to do so by contributing to the project.
So, returning to UDS I would like to tell you a small story of just one example of executing on an idea. Let me introduce Paolo Sammicheli to you. Paolo is from the Italian Loco team, and has been active in driving growth in the localized iso community. He began his work by starting an "Italian Testing Team" several UDS's ago, and has been advocating greater testing and community participation for several cycles now. This past UDS, Paolo wanted to help kickstart a localized iso community beyond just his Italian loco iso. Before UDS, he had already produced a set of wiki pages documenting how to use the isotracker admin features with a bent towards running your own localized iso tracker. Additionally, the Italian loco team planned and tested during the 12.04 cycle to create a localized ubuntu 12.04 image for release. Finally, Paolo came to UDS and created a blueprint so he could share his idea with others. Have a look at it yourself:
https://blueprints.launchpad.net/ubuntu/+spec/community-q-localized-iso-community-growth
Paolo was able to generate good ideas, and see other people attempt to replicate his work within their own locos. Plans were made to have two other loco teams produce localized isos this cycle, and ultimately use there findings as a model for future loco teams. Although the work is on-going this cycle, Paolo, I think, has been successful at bringing his idea to life.
How can you replicate Paolo's example? A couple key points I see in what happened.
- Lay the groundwork
- Start proving the idea out as best you can. Perhap's it's a demo or prototype -- maybe even just a specification or a storyboard. You need to convince yourself (and others!) your idea makes sense and can be done
- Tell others
- Let others know about your work. Blog about it, come to UDS, present it at a Ubuntu user days event, post it to the forums, talk to people on IRC about it, etc
- Do it
- This is key. You need to start executing your idea as best you can. People are not going to make your idea a reality without you! (and why would you want them to? It's your idea! Own it :-) )
- Share your work
- Invite others to work with you on your idea. It's helpful to have specific and easy ways to get involved, but don't limit people. You want to work openly in a way that anyone can participate at any level.
Go forth and own your ideas! I empower all of you to do so. Who knows, maybe your OS also won't "just be a hobby, won't be big and professional like gnu".
Wednesday, May 16, 2012
UDS Highs and Lows
As you may have seen or heard, I attended UDS-Q last week in Oakland, California. I was privileged to serve as the track lead for the QA track. I trust I served all of you brave souls willing to attend the QA track sessions well enough ;-) A big thank you to everyone who participated. We set some big goals for this next cycle, which I'd like to share over the coming days. For now, I'm going to provide the list (perhaps not comprehensive, but I tried) of blueprints I have work items on as a sneak peak at what we discussed:
You can see more of the 'qa' blueprints here:
A few key takeaways can be found in them:
- Expansion of the isotracker capabilities to do testcase management
- Ideas around helping reduce burnout, duplication of work, and in general make the testing experience easier and more fun
- Utilizing ubuntu friendly for testing
- Scrapping of the team organization ideas I proposed earlier in the cycle; instead focusing on communicating between groups will be pursued
- Ideas for community involvement in automated and regression testing
One thing you won't find in the blueprints, but which is still an important goal, is QA representation at the next UDS. I want to see more of you there next time!
So, this post was intended to be about the highs and lows of UDS. Well, let's call the first night dinner and jetlag a definite low, and the closing party a definite high :-) After 5 days of discussing I was ready to head home, but the closing party (despite the soberness of leaving) lifted my spirits and helped UDS end on a positive note.
Hmm, perhaps an image or two would better explain it..
This was high, and below is the low :-)
Labels:
canonoical,
me,
ubuntu
Subscribe to:
Posts (Atom)