mozilla

Mozilla Nederland LogoDe Nederlandse
Mozilla gemeenschap

Abonneren op feed Mozilla planet
Planet Mozilla - http://planet.mozilla.org/
Bijgewerkt: 14 uur 27 min geleden

Pierros Papadeas: Systems and Data principles

vr, 07/11/2014 - 10:42

For a year now the Systems and Data Working Group of Mozilla has been meeting, brainstorming about community building systems, designing and implementing them and pioneering new ways to measure contribution activity across Mozilla.

In the process of evaluating existing systems (like mozillians.org) and creating new ones (like Baloo) it was obvious that we needed a common set of principles to apply on all systems that are in service of community building within Mozilla. That would enable Mozillians to easily access tools and contribute in a way that maximizes impact. We as the Systems and Data Working Group recommend these principles be adapted for all tools used by Mozilla.

The principles written in buckets are:

  • Unified Identity
    • Tools should have single source of truth for people data
      • Integration with HRIS
      • mozillians.org already has staff and volunteer information, so it is a good candidate at the single source of tr
    • Tools should de-duplicate people information by integrating with a single source of truth
    • e.g. Reps: Not integrated with Mozillians.org, lots of duplicate information on two profiles
  • Unified Authentication and Authorization
    • Tools should use a single identity platform that provides permissions-based access to tools (like Mozillians.org)
    • e.g Reps: add people to the Reps group on mozillians.org to give them permission to use rep.mozilla.org as a Rep
  • Accessible Metrics
    • Tools should track each contribution a Mozillian makes and provide it in an accessible way to create a holistic view of contributions
  • Localization
    • Tools should be localized so they are accessible to our global community
  • Education
    • Tools should teach the user how to use the tool, answer common usage questions, and have general documentation
  • Recognition
    • Tools should recognize the contributions that they enable
  • Participation
    • Tools should enable anyone to improve the tool by filing bugs, suggesting ideas and bringing those ideas to life
  • Content de-duplication
    • Tools should de-duplicate the content that is created in those tools, making it accessible to other systems
  • Fun
    • Tools should be personal and written in the Mozilla voice

This has been a collaborative effort involving various stakeholders of tools within Mozilla that have been reviewing those and providing feedback during our meetings. We are seeking more feedback moving forward especially with regards to how those impact the Roadmap of various tools and translate to actual features. Feel free to comment here or join our discussions in the community-building mailing list.

 

Categorieën: Mozilla-nl planet

Jared Wein: The Bugs Blocking In-Content Prefs

vr, 07/11/2014 - 02:23

Paper Firefox!If you’ve been following my blog, you know that there has been a long on-going project to rewrite Firefox’ preferences and move them to a page within the browser.

Work has continued on that front, but it has been moving at a slow pace. Today, representatives from engineering, user experience, and project management met together to form the remaining list of bugs that are blocking us from shipping in-content preferences to the Release channel.

In total, we have 20 bugs blocking the release. There are five different categories that the bugs fit in. Bugs that should be easy to pick up and finish for a new-comer are italicized.

If you’d like to work on one of the above bugs, please click on the bug and read the details. If you have any questions, please post the question in the bug and someone will get back to you. Thanks!


Tagged: firefox, planet-mozilla, ux
Categorieën: Mozilla-nl planet

L. David Baron: A possible approach to shorter release cycles

do, 06/11/2014 - 23:12

One of the problems we've been facing with Mozilla's release cycle is that it takes a relatively long time for code to get from commit to the mozilla-central repository to get into the hands of our users. It's currently 12-18 weeks, because the current process has four repositories (central, aurora, beta, release) with most code landing on central, and with code shifting from one repository to the next every six weeks, and shipping to Firefox release users when it reaches the release repository:

[Diagram showing flow of code across nightly, aurora, beta, and release repositories, with movement from one to the next every six weeks, and channel populations corresponding to each repository]

In addition to being slower than we'd like, we're not getting quite as much feedback as we'd like since the population of aurora users is relatively small and have habits much more similar to our nightly users than our release users. This means that we don't get feedback about many real-world problems until code reaches the beta channel.

One alternative that's been discussed a few times is to have one fewer channel. People have brought up some drawbacks with that approach, such as that code pulled from mozilla-central the previous day isn't necessarily ready to be shipped to large population of users on the beta channel.

To address that, I'd like to propose an alternative that shortens the path by six weeks (and removes one of the four repository stages), but keeps the four separate populations:

[Diagram showing revised structure with three repositories, differing from current behavior by placing the beta user population on the release repository for the first part of the cycle but then on the aurora repository for the bulk of the cycle]

This model differs from what we do now by eliminating the mozilla-beta repository, and thus removing six weeks from the cycle. Users on the nightly, aurora, and release channels would get code like they do now, tied to one repository. Users on the beta channel, however, could get code from the release repository for the first week or so of the cycle (right after we ship that release), and then get code from the aurora repository (which will become the next release) for the rest of the cycle. In other words, users on the beta channel won't change the version that they're running on merge day, but instead a week (or maybe two) later.

Having the beta users switch repositories has two advantages. First, it means that beta users will be able to beta-test any point releases that we ship in the first week or so of the cycle. Second, it means that we'll have a week or so to fix any serious stability problems in the aurora repository before updating all beta users to it.

To be clear, this is just my proposal for what I think we could do, not something that anyone is already planning to do. But I think it could be a good way to get us a faster release cycle that would allow us to get our work faster into our users' browsers.

Categorieën: Mozilla-nl planet

Mozilla Fundraising: gear.mozilla.org: The New Public Face of Official Mozilla Gear

do, 06/11/2014 - 22:36
The new home of Official Mozilla Gear is coming soon! The site will official launch later this year, and many Mozillians know that this has been a long time coming. It will be built for the public — where anyone … Continue reading
Categorieën: Mozilla-nl planet

Armen Zambrano: Setting buildbot up a-la-releng (Create your own local masters and slaves)

do, 06/11/2014 - 15:02
buildbot is what Mozilla's Release Engineering uses to run the infrastructure behind tbpl.mozilla.org.
buildbot assigns jobs to machines (aka slaves) through hosts called buildbot masters.

All the different repositories and packages needed to setup buildbot are installed through Puppet and I'm not aware of a way of setting my local machine through Puppet (I doubt I would want to do that!).
I managed to set this up a while ago by hand [1][2] (it was even more complicated in the past!), however, these one-off attempts were not easy to keep up-to-date and isolated.

I recently landed few scripts that makes it trivial to set up as many buildbot environments as you want and all isolated from each other.

All the scripts have been landed under the "community" directory under the "braindump" repository:
https://hg.mozilla.org/build/braindump/file/default/community

The main two scripts:

If you call create_community_slaves_and_masters.sh with -w /path/to/your/own/workdir you will have everything set up for you. From there on, all you would have to do is this:
  • cd /path/to/your/own/workdir
  • source venv/bin/activate
  • buildbot start masters/test_master (for example)
  • buildslave start slaves/test_slave
Each paired master and slave have been setup to talk to each other.
I hope this is helpful for people out there. It's been great for me when I contribute patches for buildbot (bug 791924).
As always in Mozilla, contributions are always welcome!
PS 1 = Only tested on Ubuntu. If you want it to port this to other platforms please let me know and I can give you a hand.
PS 2 = I know that there is a repository that has docker images called "tupperware", however, I had these set of scripts being worked on for a while. Perhaps someone wants to figure out how to set a similar process through the docker images.

Creative Commons License
This work by Zambrano Gasparnian, Armen is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
Categorieën: Mozilla-nl planet

Henrik Skupin: Firefox Automation report – week 35/36 2014

do, 06/11/2014 - 11:08

In this post you can find an overview about the work happened in the Firefox Automation team during week 35 and 36.

Highlights

Due to a lot of Mozmill test failures related to add-on installation and search, we moved from the addons-dev.allizom.org website to the staging website located at addons.allizom.org. Since then we experiencing way lesser test failures, which are most likely network related.

In order to keep up with all test failures, and requests for new tests we started our Bug triage meeting on a weekly basis on Friday. For details we have created an etherpad.

If you are interested in helping us with Mozmill tests, you can now find a list of mentored and good first bugs on the bugsahoy web page.

Because of the app bundle changes on OS X, which were necessary due to the v2 signing requirements, we had to fix and enhance a couple of our automation tools. Henrik updated mozversion, mozmill, and mozmill-automation. We were close to releasing Mozmill 2.0.7.

Individual Updates

For more granular updates of each individual team member please visit our weekly team etherpad for week 35 and week 36.

Meeting Details

If you are interested in further details and discussions you might also want to have a look at the meeting agenda, the video recording, and notes from the Firefox Automation meetings of week 35 and week 36.

Categorieën: Mozilla-nl planet

Pagina's