Upstream
|
Size: 2786
Comment:
|
Size: 2737
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 7: | Line 7: |
| When dealing with others we who know us personally, our most valuable asset is often our individual reputations. When dealing with others who may not know us personally, we depend on the reputation of our community. | When interacting with others who know us personally, our most valuable asset is often our individual reputation. When interacting with others who may not know us personally, we depend on the reputation of our community. |
| Line 11: | Line 11: |
| The greatest strength of open source is the ability for every one to improve and modify their software as they see fit. As good community members we would like to insure that we are as faithful as possible about pushing our improvements upstream. | On the Mozilla Team, we will often be interacting with upstream communities whose members may not know us personally. As such, we will need to depend on our team reputation and Ubuntu reputation. |
| Line 13: | Line 13: |
| When upstreams receive issue reports from us, we want them to know that they are complete and well documented. When they receive patches from us we want them know that they are high quality and well tested. | |
| Line 14: | Line 15: |
| We want them to know we are good community members. | |
| Line 17: | Line 19: |
| One of the key ways in which our users can help improve our products is by submitting good bug reports. It is then our responsibility to forward these reports upstream as necessary. We have had varying results when contact upstream maintainers, ranging from from 'go away you don't have enough market share for us to worry about', to extremely receptive. | We can establish our team's reputation by submitting good bug reports upstream. ???? |
ContentsBRTableOfContents |
draft v1.1 DavidFarning
When interacting with others who know us personally, our most valuable asset is often our individual reputation. When interacting with others who may not know us personally, we depend on the reputation of our community.
Upstream
On the Mozilla Team, we will often be interacting with upstream communities whose members may not know us personally. As such, we will need to depend on our team reputation and Ubuntu reputation.
When upstreams receive issue reports from us, we want them to know that they are complete and well documented. When they receive patches from us we want them know that they are high quality and well tested.
We want them to know we are good community members.
Bug Triage
We can establish our team's reputation by submitting good bug reports upstream.
????
Launchpad already has the capability to monitor upstream bug tracking systems. To insure that we are pushing high quality reports, we should appoint shepherds to work with upstream maintainers.
For more details on how we organize upstream triage, read the discussion of state Confirmed on page ["MozillaTeam/Bugs/States"].
Patches
Ideally, all Ubuntu issues will be correctly pushed upstream or promptly resolved with patches.
From a Ubuntu perspective, we have two types of patches 'common' and 'distro specific'.
Common patches are those that we feel are applicable for inclusion upstream. These patches should be pushed upstream. If the patch is rejected, we need to carefully consider why we are keeping it.
Distro Specific are those that we include to add Ubuntu specific features, these patches should be kept locally.
In order to keep development as flexible as possible we should develop a clear method of identifying patches and pushing them in and out of build trees. The Debian package build system provides a very clean method of doing this by placing all patches in the Debian/patches directory. For Firefox, a clean patching system will be a necessity as well as benefit as we comply with Mozilla's new QA standards.
I propose that we go through our packages and implement a modular patch management system. This does not need to be any more complicated than storing patches in Bazaar so that they can easily be maintained.
I also propose that we develop a naming prefix structure to indicate if a patch is 'common' or 'distro specific'.
MozillaTeam/Upstream (last edited 2008-08-06 16:59:42 by localhost)