Re: SUSCRIBE PLEASE

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Re: SUSCRIBE PLEASE

cecilca

Juan cesar martinez
----- Original Message -----
From: <[hidden email]>
To: <[hidden email]>
Sent: Monday, June 01, 2009 8:00 PM
Subject: dev-planning Digest, Vol 42, Issue 1


> Send dev-planning mailing list submissions to
> [hidden email]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.mozilla.org/listinfo/dev-planning
> or, via email, send a message with subject or body 'help' to
> [hidden email]
>
> You can reach the person managing the list at
> [hidden email]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of dev-planning digest..."
>
>
> Today's Topics:
>
>   1. Testday: Find Out about MozQA's Website Testing Project,
>      Friday 6/5 from 7AM to 5pm PDT (Aakash Desai)
>   2. Thunderbird Weekly Status meeting: Tuesday June 2nd, 2009
>      (Mark Banner)
>   3. SeaMonkey Status Meeting - Tue, June 2 (Robert Kaiser)
>   4. Super-review: policy draft (Mike Connor)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 31 May 2009 12:26:45 -0700 (PDT)
> From: Aakash Desai <[hidden email]>
> To: communityqateam <[hidden email]>, macqa
> <[hidden email]>, vistaqa <[hidden email]>,
> [hidden email], dev-apps-firefox
> <[hidden email]>, dev-planning
> <[hidden email]>, dev-quality
> <[hidden email]>
> Subject: Testday: Find Out about MozQA's Website Testing Project,
> Friday 6/5 from 7AM to 5pm PDT
> Message-ID:
> <[hidden email]>
> Content-Type: text/plain; charset=utf-8
>
> Hey all you awesome Mozilla Community Members out there!
>
> I'm here to inform you that the we're going to be holding our FIRST
> WEBSITE TESTING PROJECT test event of 2009 this Friday, 6/5, from 7AM to
> 5pm PDT! It'll be a day completely devoted to exploring/testing/playing
> the new project and learning about what they do and how they do it!
>
> To get started, just head over to the project page on QMO:
>
> http://quality.mozilla.org/website-testing
>
>
> ...and start participating at any time!
>
> Thanks in advance to everyone that's able to make it as it's going to be a
> lot of fun!
>
> See You All on Friday,
> aakashd
> Mozilla QA
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 31 May 2009 22:21:35 +0100
> From: Mark Banner <[hidden email]>
> To: [hidden email]
> Subject: Thunderbird Weekly Status meeting: Tuesday June 2nd, 2009
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> [Followups aimed to mozilla.dev.planning]
>
> The usual meeting in the usual venue. See
> https://wiki.mozilla.org/Thunderbird/StatusMeetings/2009-06-02 for
> details, and please add anything you wish to discuss to the agenda.
>
> Standard8
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 01 Jun 2009 03:02:19 +0200
> From: Robert Kaiser <[hidden email]>
> To: [hidden email]
> Subject: SeaMonkey Status Meeting - Tue, June 2
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-15; format=flowed
>
> Agenda: https://wiki.mozilla.org/SeaMonkey:StatusMeetings:2009-06-02
> * June 2, 12:00 UTC, 8am Eastern, 1pm UK, 2pm Central Europe
> * Other timezones:
> http://www.timeanddate.com/worldclock/fixedtime.html?day=02&month=06&year=2009&hour=12&min=0&sec=0&p1=0
> * IRC channel #seamonkey - irc://irc.mozilla.org/seamonkey
>
>
> Hi everybody,
>
> We're doing another instance of our biweekly SeaMonkey Status meetings
> on IRC.
>
> Please add agenda items we should discuss, we're trying to get a good
> view there where the SeaMonkey project is right now, what's the progress
> compared to last time and where we are headed.
>
> Thanks,
>
> Robert Kaiser
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 1 Jun 2009 09:02:24 -0700
> From: Mike Connor <[hidden email]>
> To: [hidden email]
> Cc: "[hidden email] planning"
> <[hidden email]>
> Subject: Super-review: policy draft
> Message-ID: <[hidden email]>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Sorry for the much-delayed aspect, writer's block sucks sometimes.
> ("But I'm doing _much_ better now.")
>
> This will probably replace http://www.mozilla.org/hacking/
> reviewers.html, with the existing super-reviewer list bits kept intact
> (and the 21 rules moved to MDC in an appropriate list).
>
> -- Mike
>
> =========================
>
> Introduction
>
> Mozilla has required code review from the beginning, and it is a key
> factor in our success.  Code review helps us produce better code and
> better products in many ways, from catching bugs early, teaching and
> mentoring new contributors, and keeping progress going in the right
> directions.  Strong module ownership and strong domain expertise are
> essential, and we continue to work to improve these capabilities
> within the project.
>
> Super-review has its roots in the early days of Mozilla, when we
> needed a core group of hackers to bring even the early module owners
> up to speed.  This group helped improve quality across the board, and
> acted as a safety net against the tendency of a large group of hackers
> to move in widely varied directions.  Over time, we have learned a lot
> about how to work fast and effectively, and in many parts of the code
> we've done away with super-review in favour of deferring to strong
> module ownership.  This has been both a blessing and a curse, and it
> has become clear over time that there was room to improve the review
> process across our codebase to get the best of both worlds.
>
> At this point, the super-reviewers group continues to be composed of
> senior, experienced hackers who can add value across the codebase in
> some specific ways separate from domain expertise.  We have been
> bouncing around the problem for quite some time, and the conclusion
> has been to modify the review policy across the board to be a single
> policy, using super-review where it will have the biggest impact, and
> no longer using it where it is unnecessary.  This will apply to all
> code maintained in the mozilla-central repository, as well as any
> release branch repositories based on mozilla-central.
>
>
> What needs super-review?
>
> * Significant architectual refactoring
>
> All changes that involve significant changes to how code works and
> interacts must be submitted for super-review.  Code design is hard,
> and getting more input helps us in the areas of maintainability.
>
>
> * All changes involving security
>
> For security bugs, and changes to security models or mechanisms, we
> want extra experienced eyes to be involved with those changes.
>
>
> * Any change to any API or pseudo-API
>
> APIs are not just XPCOM APIs, but include global JS utility functions
> and the like.  Designing these better up front makes it easier to
> build things on top of these APIs, and helps us avoid compatibility-
> killing "API cleanup" down the road.
>
>
> * All changes that affect how code modules interact
>
> Any other changes that fall outside of the above rules, but affect how
> two or more code modules function, must have super-review.
>
>
> =========================
>
>
> ------------------------------
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>
>
> End of dev-planning Digest, Vol 42, Issue 1
> *******************************************

---------------------------------------
    Red Telematica de Salud - Cuba
     CNICM - Infomed

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning