Upstream
|
Size: 2310
Comment:
|
Size: 2323
Comment: Me being fussy :)
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 5: | Line 5: |
| 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 improvments upstream. | 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. |
| Line 7: | Line 7: |
| The Mozillateam has several upstream products that have varying degrees of openness. These products range from Adobe's Flashplayer to Sun's JVM to the FSF's Gnash. | The MozillaTeam has several upstream products that have varying degrees of openness. These products range from Adobe's Flashplayer to Sun's JVM to the FSF's Gnash. |
| Line 11: | Line 11: |
| One of the key ways in which our users can help improve our product is submitting good issue report. It is then or responsibility to forward this issues upstream as necessary. I have had varying results when contact upstream maintainers. The results have ranged from 'go away you don't have enough market share for us to worry about' to very receptive. | 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. I 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. |
| Line 13: | Line 13: |
| 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. | 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. |
| Line 19: | Line 19: |
| From a Ubuntu perspective, we have two types of patches 'common' and 'distro specific.' | From a Ubuntu perspective, we have two types of patches 'common' and 'distro specific'. |
| Line 21: | Line 21: |
| 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. | 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. |
| Line 23: | Line 23: |
| Distro Specific are those that we include to add Ubuntu specif features. These patches will be kept locally. | Distro Specific are those that we include to add Ubuntu specific features, these patches should be kept locally. |
| Line 25: | Line 25: |
| I order to keep development as flexible we should develop a very 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. | 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. |
| Line 28: | Line 28: |
| I propse that we go through our packages break implement a modular patch management system. This does not need to be any more complicated than storing patches in bzr so that they can easily be maintained. | 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. |
| Line 30: | Line 30: |
| I also propose that we develop a naming prefix structure to indicated if a patch is common or distro specific. | I also propose that we develop a naming prefix structure to indicate if a patch is 'common' or 'distro specific'. |
| Line 32: | Line 33: |
| CategoryMozillaTeam | [:CategoryMozillaTeam] |
[draft proposal]
Upstream
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.
The MozillaTeam has several upstream products that have varying degrees of openness. These products range from Adobe's Flashplayer to Sun's JVM to the FSF's Gnash.
Bug Triage
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. I 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.
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.
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)