Postponing Ubuntu User Days

With the second Ubuntu User Day being less than a week away, and in going over our final checklist, it has come to our attention it would be a better event, both in attendance and in the choice of session if we were to postpone this event.

While we understand that you may have scheduled time on the June 5th, 2010, to facilitate a session or participate by attending we want the experience of both session leaders and participants to be the best possible.

Keeping in mind we want to present the best possible learning opportunity, we have made the decision to postpone this event until July 10, 2010.

It is our, the User Days Planners, sincere hope that this will not be an inconvenience to you or any helpers with your session.

Thank you so much for you understanding! We are looking forward to another great second Ubuntu User Day (but a few weeks later and with more planning, promotion, participants, and more awesome session leaders like yourselves).

[Discuss Postponing Ubuntu User Days on the Forums]

Originally posted to the ubuntu-classroom mailing list

Call for Testing: Hardy Firefox Users (or willing to install Hardy in a VM)

Background

Firefox 3.0 and xulrunner 1.9 are now unsupported by Mozilla. Rather than backporting security fixes to these now, we are moving to a support model where we will be introducing major new upstream versions in stable releases. The reason for this is the support periods from Mozilla are gradually becoming shorter, and it will be more and more difficult for us to maintain our current support model in the future.

What we are going to do

We are going to release Firefox 3.6.4 as a minor update to the 3.6 series in Lucid. This will also be rolled out to Hardy, Jaunty and Karmic (along with xulrunner 1.9.2.4). The update for Lucid is quite trivial, but the update in Hardy, Jaunty and Karmic is not quite as simple.

Before releasing these updates to the public, we need testing in Firefox, the extensions in the archive and distributions upgrades after those updates. We have published all these packages in a PPA and we will track test results before moving anything to the archive.

How you can help

We need people running *Hardy* (Jaunty and Karmic will see a similar call for testing in the following days) in bare metal or a virtual machine. If you are willing to help, you can follow the instructions below:

  1. Add the Mozilla Security PPA to your software sources

    You need to manually edit your /etc/apt/sources.list and add the following lines:

    deb http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu hardy main

    deb-src http://ppa.launchpad.net/ubuntu-mozilla-security/ppa/ubuntu hardy main

    After saving the file, you have to run:

    sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 7EBC211F

    sudo apt-get update

    sudo apt-get dist-upgrade

  2. You have to have an account in our tracking system. Go to http://mozilla.qa.ubuntu.com and click on “Log In” and “Create New Account”
  3. Explore your Firefox installation

    Basically we want people to perform the same activities that the do daily, without issues. In order to make testing easier, this is a checklist of things worth looking:

    • The upgrade to Firefox 3.6.4 goes smoothly.
    • The extensions get upgraded as well.
    • All the Firefox plugins (i.e. Flash, Java) still work.
    • The extensions work correctly.
    • Full distributions upgrades are not broken.
    • Upgrades work with only the security pocket enabled (ie, hardy-updates disabled)

To report your findings you need to use the test tracker.

Once you have selected the Hardy image, you will see a set of “testcases”, with a summary of how many reports have been sent. Obviously, the most important one is “Firefox”.

List of testcases

Once you open one of the testcases, you will be able to report back your findings if something went wrong. Even if everything went fine, it is always good to report back the success (“Passed”) with a comment on the activities you performed.

Report back

Use the “Firefox” testcase for general testing (upgrade, rendering, plugins, etc.) and the rest of the testcases if you want to report something more specific (Upgrades to Lucid, specific extensions errors, etc.)

IMPORTANT!! How to file bugs

As we are testing a PPA, not an official Ubuntu package, if you find an issue is NOT OK to file a bug in Launchpad. Rather than doing so, please, just explain your issue in the Comments field of the tracker and mark the test as Failed.

The tracker requires a bug number in order to mark a test as Failed. To bypass this requirement, just use the bug number “1″ ';-)'

Thanks for helping to maintain secured Ubuntu stable releases!

[Discuss Call for Testing: Hardy Firefox Users (or willing to install Hardy in a VM) on the Forums]

Originally posted here by Ara Pulido on Tue, June 1, 2010

New Firefox Support Model and Coming Changes in Stable Updates

The desktop team has been working since the Karmic UDS on the following blueprint: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-new-firefox-support-model

The upshot of the blueprint is that there will be some changes to users’ desktops if they are currently Hardy, Jaunty or Karmic users.

In Lucid, we put in a lot of effort to ensure these updates will be easier in the future (Firefox now uses bundled libraries rather than system libraries, we have reduced the number of applications in the archive using xulrunner, and dropped a lot of extensions too). The update for Lucid is quite trivial, but the update in Hardy, Jaunty and Karmic is not quite as simple. When we roll out the new version, we also need to update the following:

  • All the Firefox extensions that we ship in the archive
  • Language packs
  • In addition to this, we are going to be porting some applications which are currently using xulrunner 1.9 to either the latest version of xulrunner (1.9.2.4) or Webkit. However, this can happen after the Firefox rollout, as the 2 xulrunner versions can be installed in parallel. We have a list of the affected applications. We won’t be porting all of the applications on that list, but will be focusing on the applications which are exposed to insecure content (at the bottom of
    the page)
    .

    Why:

    Firefox 3.0 (and xulrunner 1.9) are now unsupported by Mozilla. Rather than backporting security fixes to these now, we are moving to a support model where we will be introducing major new upstream versions in stable
    releases. The reason for this is the support periods from Mozilla are gradually becoming shorter, and it will be more and more difficult for us to maintain our current support model in the future.

    When:

    Next week, Mozilla will release Firefox 3.6.4 as a minor update to the 3.6 series. This will be rolled out to Lucid, Hardy, Jaunty and Karmic (along with xulrunner 1.9.2.4).

    Call for Testing:

    Packages will be hosted in the Ubuntu Mozilla Security team PPA.

    As this is being rolled out as a security update (rather than a SRU), there is no bug report tracking this. The rollout is being covered (and will be announced) by USN-930-1.

    Clearly, there are significant risks associated with the update. In addition to ensuring that Firefox and all the extensions still function correctly after the update, we also need to ensure:

    1. All the Firefox plugins (eg, Flash) still work
    2. The actual upgrade to the latest version goes smoothly
    3. We don’t break Hardy -> Lucid and Jaunty -> Karmic upgrades
    4. The upgrade works with the *-updates pocket disabled

    Applications that are ported to the latest version of xulrunner (or to Webkit) will also need testing. However, we will also need to test every application on the list in (even the ones which aren’t being updated), with the latest version of xulrunner installed on the system. The reason for this is that most applications dynamically load one of the GRE’s on the system, and some of these applications will load 1.9.2.4 if it is present. I already know of 1 API change in 1.9.2.4 which had been causing me problems with applications I’ve been porting, so it’s possible that the same issue will affect applications we aren’t
    porting if they load the newest GRE.

    You can help testing the upgrade by following the instruction on https://lists.ubuntu.com/archives/ubuntu-devel/2010-June/030811.html

    [Discuss New Firefox Support Model and Coming Changes in Stable Updates on the Forums]

    Originally posted on the ubuntu-devel-announce by Sebastien Bacher on Tue Jun 1 11:59:25 BST 2010

Maverick Alpha 1 Freeze Ahead

The Meerkat wants to stick its head out to the world the first time! We haven’t really started landing new features from ourselves yet, but the first milestone is important for testing the new kernel on a variety of hardware, as
well as the result of the autosyncs from Debian and first wave of merges and package updates.

Alpha milestones in Ubuntu use a “soft freeze” for main, which means that developers are asked to refrain from uploading packages between Tuesday and Thursday which don’t bring us closer to releasing the alpha, so that these
days can be used for settling the archive and fixing any remaining showstoppers.

The list of bugs targeted for alpha-1 can be found here.

Per the policy described on the RC Bug Targetting Wiki, this list is used for tracking bugs that are blockers for the alpha 1 milestone – so as you can see, the list will be quite short (and is in fact empty right now).
If you know of bugs that should be considered blockers, please nominate them for release and set the milestone target for those bugs. If you have questions about whether a bug should be considered a blocker, please contact a member of the release team.

Beyond that short list of bugs that are blockers for Alpha 1, we have those bugs that are listed as release-critical for Maverick as a whole: https://bugs.launchpad.net/ubuntu/maverick/+bugs

If you aren’t among the small group of people who have milestoned bugs assigned to you, please consider helping with those bugs, using your best judgement with regard to the alpha freeze when uploading fixes.

Please also help us to get the archive in a consistent state for the alpha, as described on
https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Consistency.

There’s also plenty that can be done to help packages that aren’t included on the CDs: https://merges.ubuntu.com/main.html shows over 300 package merges still outstanding in main for maverick, and
https://merges.ubuntu.com/universe.html shows close to 400.

Finally, if you know of new features in Maverick that you think should be highlighted for Alpha 1, let a member of the release team know so that they can be added to the technical overview.

[Discuss Maverick Alpha 1 Freeze Ahead on the Forums]

Originally posted to the ubuntu-devel-announce mailing list by Martin Pitt on Mon May 31 07:07:41 BST 2010

Announcing this week's Bug Day target – Compiz- Thursday, June 3rd, 2010

This week’s Bug Day target is *drum roll please* Compiz!

  • 100 New bugs need a hug
  • 62 Incomplete bugs need a status check
  • 82 Confirmed bugs need a review

Bookmark it, add it to your calendars, turn over those egg-timers!

Are you looking for a way to start giving some love back to your adorable Ubuntu Project?

Did you ever wonder what Triage is? Want to learn about that?

This is a perfect time!, Everybody can help in a Bug Day! Open your IRC Client and go to #ubuntu-bugs (freenode) the BugSquad will be happy to help you to start contributing!

Wanna be famous? Is easy! remember to use 5-A-day so if you do a good work your name could be listed at the top 5-A-Day Contributors in the Ubuntu Hall of Fame page!

We are always looking for new tasks or ideas for the Bug Days, if you have one add it to the Planning page https://wiki.ubuntu.com/UbuntuBugDay/Planning

If you’re new to all this, head to https://wiki.ubuntu.com/Bugs

[Discuss Announcing this week’s Bug Day target – Compiz- Thursday, June 3rd, 2010 on the Forums]

Originally sent to the ubuntu-devel-announce Mailing List by Pedro Villavicencio Garrido on Wed Jun 2 13:58:06 BST 2010