Posts Tagged with “code”

I’ve proposed a change in the current policy for how we grant commit access to the main Mozilla source code repositories. The details are in the mozilla.governance newsgroup, which can also be read through a browser at http://groups.google.com/group/mozilla.governance/browse_thread/thread/68bdd4d7f82d4c03?hl=en#

Feedback welcome in the newsgroup or here.

Stuart recently described the need to allow improved collaboration with groups of people in specific circumstances: changes to Mozilla code that are larger (and possibly more experimental) than individual patches and where the new contributors don’t yet have commit access to the source tree and where existing Mozilla contributors want that collaboration to occur within a Mozilla-hosted source repository.

At the same time, our policies for determining who has commit access are critical to maintaining the quality of our work; we certainly don’t want to change that.

We (Brendan, Stuart and I) have come up with a proposal that we think gives us some flexibility without changing the rules for obtaining commit access to mozilla-central. It includes a mechanism for allowing such collaboration plus a description of the logistics such as how to file a bug for individual access and get it closed. Comments are welcome here or in the mozilla.org Governance newsgroup. (You can also participate through the mozilla.governance Google Group. )

Incubator Repositories

Incubator Repositories are a tool available to module owners in the following circumstances:

1. the module owners are engaged in significant cooperative development with contributors who are not yet experienced enough with Mozilla to have commit access to the Mozilla source tree; and
2. it is impractical to break contributions into bug-sized patches and follow the standard review and check-in process, either because the scope of work makes this difficult, or the work is experimental and a precursor to patches that will eventually end up in Mozilla-central or another reason the module owners can describe persuasively.

In other words, an Incubator Repository is a temporary repository hosted by Mozilla where we allow people to check code in before they have official source code write access for our production code base. An Incubator Repository is not needed for repositories where all contributors have full source code commit access.

An Incubator Repository should meet the following conditions:

• An incubator repository requires 2 module owners to be committed as sponsors.
• The work is important to Mozilla’s stated development roadmap; Incubator Repositories are not a hosting site for potentially-related work.
• The work is not duplicative of work in mozilla-central. There is some possibility that duplicative incubator repositories are possible, we can look at that if the setting arises.
• Incubator branches are temporary. In general, an incubator branch probably shouldn’t last longer than six months. By that time it should be clear whether the work has potential. And if it is an effective branch, there should be enough activity from the contributors to determine which if any of them are ready for commit access. However, setting a one-size-fits-all date for all which must be tracked for its own sake requires a bureaucracy to track and manage that. Instead, we’ll say that six months is the general timeframe. For a branch to last longer, the sponsors should have a good rationale why this is the case, they should ideally make that rationale to the Incubator Repositories module owner, and they must make that case effectively if the Incubator Repositories module owner or peers ask.
• Incubator Repositories are publicly available repositories just like mozilla-central.
• Incubator Repositories incubate both code and people. They are not training branches where the code doesn’t matter. They are not intended to provide examples of coding to evaluate someone’s readiness for commit access; we have policies for that. They are intended to help the sponsors make progress that otherwise wouldn’t be possible while new contributors learn about Mozilla and become known to Mozilla.
• Participants in an Incubator Repository may also develop patches that relate to the work in mozilla-central, for example a patch relating to start-up performance. When this happens, the patch or patches in question should be submitted through the standard process. This not only improves our code, but it provides a chance for the author’s work to become known, which is necessary for commit-access outside the Incubator Repository. The sponsors are responsible for encouraging this process.
• There is no right of potential contributors to have an incubator repository because it is easier for them. There is the ability of existing module owners to sponsor one.
• The sponsors are responsible for the operation of the Incubator Repository.

Logistics and Operational Parameters

• The creation of an Incubator Repository must be approved by the owner (or a designated peer) of the Incubator Repository module. (This is a new module which we will create as part of the implementation of this policy assuming it is approved.)
• The proposal should describe why the Incubator Repository meets the required conditions, who the sponsors are, hoped-for results of the Incubator Repository, the approximate number of people likely to be given check-in access through this process, and any possible effects on other parts of Mozilla.
• The proposal should also be filed as a bug and also posted in the relevant newsgroup.
• The sponsors are responsible for figuring out a reasonable system for getting code from the Incubator Repository into mozilla-central. “Reasonable” generally does not mean dropping six months of work on reviewers and asking for code review. Sponsors may meet this responsibility by using Mozilla code-review techniques in the Incubator Repository or by other means, but they are responsible for getting code review in reasonable increments.
• Anyone checking into an Incubator Repository must have signed a CVS Contributor Form on file with the Mozilla Foundation.
• Once approval for an Incubator Repository has been granted and recorded in the appropriate bug, the sponsor or Incubator participants should file a bug asking for commit access for that person for the Incubator Repository. Details on filing the bug and getting it closed are below.

Incubator Commit Access

Here’s a list of the steps that need to happen to get Incubator Commit Access.

1. Make sure the creation of the Incubator Repository to which you wish access has been approved.
2. File a bug. Product: mozilla.org; Component: CVS AccountRequest. Don’t change the Default Assignee or the Default QA Contact. Your summary should say something about creating an Incubator Account (“Incubator Account Request – John Doe <jdoe@example.com> “). You should also include in the bug a pointer to the earlier bug in which the creation of the Incubator Repository in question was approved.
3. Each of the two sponsors should comment in the bug saying s/he’s sponsoring the Incubator Repository and your participation in it.
4. Make sure to include your CVS SSH public key as an attachment to the bug. (Please mark it as text/plain when attaching it!) Note that you will need to attach an SSH key for all types of access.
5. Complete the Contribution Form and fax it to the location specified on the Form.
6. Update the bug to note that you’ve faxed in the Form.
7. An appropriate Mozilla representative will update the bug to say whether s/he has received the faxed Form.
8. Update the bug when all the needed info is in the bug. This way, Bugzilla can send off mail to the Mozilla representative tending to accounts.
9. The Mozilla representative will double-check that the needed info is recorded and, if so, create an account.
10. The Mozilla representative will then reassign the bug to IT to have your SSH public key added.
11. A Mozilla IT representative will update the bug with account creation information and close the bug.

I’ve been following the news reports that Symantec has decided to change the way it counts security threats for browsers. Symantec is moving from a system which counted only vendor-acknolwedged problems to two categories. One is vendor-acknowledged and one is both acknowledged and not-acknowledged.

I want to applaud Symantec for making this change and for noting that this is a better methodology. The new method is better because it reports serious problems whether or not the vendor has acknowledged them. The information citizens get should not be so dependent on what the software vendor chooses to tell them, so this is a good step.

The new method is also better because it removes an insidious (and I’m sure absolutely unintended) side effect of rewarding software vendors for not acknowledging problems. Acknowledging problems is hard enough in any setting — for companies, for people, for most organizations. Symantec’s new system removes this unintentional public relations reward for not acknowledging problems.

The Mozilla project creates its own internal incentives for acknowledging security issues in a timely way to protect consumers. We do this through our community and our open source development process. We open our code to people who are not employees. By doing so we make sure that we have independent experts involved in improving Mozilla products and acting as consumer advocatees. These experts monitor our performance constantly and provide an expert voice in getting security information from the Mozilla project to our user base.

Security in the Internet era is a complex, constant process. No one is perfect today, and no one will be perfect tomorrow. Internet security will be a hard problem requiring vigilance for a long time. Protecting consumers over the long run requires a software vendor to have appropriate motivations, effective policies and develpment methods, and of course, good results. In this setting a strong, open process with built-in consumer protections is critical.

We’ve pioneered such a process and we see its results in our products.

A while back I wrote a bit about search. One of the comments to that post was a suggestion / request that it would be helpful if the “Mozilla Foundation published some sort of guidelines about the processes they go through when considering and entering into these relationships.” Rather than wait until we have a full set of guidelines I think I’ll just plunge in with the first and most obvious and then keep adding.

The first and most basic guideline concerns the source code development itself: The Mozilla Foundation does not enter into agreements that try to affect what goes into our shared source repository.

The source code is a community resource. A relationship between the Mozilla Foundation and another organization cannot try to control the source tree for the benefit of that relationship. The source code is developed by a set of people far broader than the Mozilla Foundation. The Mozilla project has a long history of distributing authority to module owners, reviewers and other respected people. The job of the Mozilla Foundation is to provide coordination, guidance and leadership to these groups to produce the best possible shared resource.

The Mozilla Foundation does make decisions about the branded versions that the Mozilla Foundation distributes and might enter into agreements regarding the branded version. We would do this sparingly with a focus on user experience and user choice, but we might make some agreements about our branded versions. Future posts and resulting discussions will work through the guidelines for how we think, and should think, about this.

But the basic principle is that any such agreement do *not* bleed over into the unbranded source repository. What goes into the source tree is a community-based decision. I’ve had a number of conversations with various businesses interested in Mozilla technology, the Mozilla project and how the Mozilla Foundation operates. One thing comes through loud and clear: the Mozilla community generates respect. People often don’t understand the details of how we operate, or how leadership and distributed authority work in practice. But they do understand that the Mozilla community is greater than the Mozilla Foundation, and that working with this community is critical.

This is a big change from when I started having these discussions years ago (before the Mozilla Foundation). It reflects the growing awareness of our development methodology, and the respect for what the Mozilla project has accomplished.