(Add Graham Cobb) |
(→Contributors) |
||
| (24 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
The role of MeeGo working groups are explained at http://meego.com/about/governance | The role of MeeGo working groups are explained at http://meego.com/about/governance | ||
| - | This is a request to the Technical Steering Group to approve the creation of a Repository working group. There is no procedure defined but we | + | This is a request to the Technical Steering Group to approve the creation of a Repository working group. There is no procedure defined but we can improvise with some common sense. |
| + | |||
| + | To set the context: like most linux distros, MeeGo will inevitably consist of "MeeGo supported packages" and "Community supported packages" this proposal is about the latter. | ||
| + | |||
| + | === Announcement === | ||
| + | |||
| + | The (so far un-official) Repository Working Group (RWG) held its [http://meego.mkdir.name/logs/meego-meeting/2010/meego-meeting.2010-03-21-20.02.html first meeting on Sunday, 21. March 2010]. | ||
| + | |||
| + | N.b. It has been suggested that the name is not quite right - maybe "Community Repository WG"... but since MeeGo aims to be a community project then phrases like Non-Core or Unsupported or "Surrounding Repository WG". At this point lets focus on the objective, not the name. | ||
=== Mission === | === Mission === | ||
| - | The | + | |
| + | The Repository Working Group (RWG) would define and oversee implementation of the strategy for publishing community created software with the MeeGo project. | ||
| + | |||
| + | The goal of the RWG would be to unite the various community contributions interested in applications & libraries, packaging, policy, QA processes, building, etc **and integrate them with Core release engineering*** | ||
| + | |||
| + | We realize this is a wide scope but feel it should have coherent representation in the community. | ||
| + | |||
| + | We propose 3 sub-groups to cover: | ||
| + | * Repository: take responsibility for maintaining the applications repository, the community supported packages repository (cf Ubuntu Universe) and associated QA and policies for MeeGo, | ||
| + | * Build: support administrative implementation with the Build System team in coordination with these goals, | ||
| + | * Document: take responsibility for the MeeGo community packaging documentation | ||
| + | |||
| + | The nature of this area means it would likely form a gateway to the inclusion of packages in MeeGo Core and a community maintainable location for packages removed from the Core. | ||
=== Areas === | === Areas === | ||
| - | |||
| - | * ''' | + | The proposed repositories would cover distinct areas: |
| - | * ''' | + | |
| - | * ''' | + | * '''Applications repository''' |
| + | This area would provide a home for more discrete applications with individual release cycles. | ||
| + | This brings something equivalent to the maemo.org Extras repository to MeeGo. | ||
| + | |||
| + | * '''MeeGo Surrounds repository''' | ||
| + | MeeGo plans to be a first class distribution and should not prevent packages from being made available. Cf MeeGo:Universe and MOTU. | ||
| + | Surrounds therefore provides a more coherent set of inter-related or depended-upon libraries and applications. The entire collection would follow the same release cycle (which may be the same as MeeGo Core). | ||
| + | The surrounds area would probably support historical releases of MeeGo for situations where vendors didn't provide updates for devices. | ||
| + | |||
| + | It may make sense for the Surrounds area to establish relationships (close, arms-length, formal or informal) to maintainers in other community distros to share the burden of maintaining some packages. | ||
| + | |||
| + | Policy would cover: | ||
| + | * '''Community Package QA''': Quality Assurance on packages. | ||
* '''Packaging policy''': Define a clear packaging policy for MeeGo, and keeping the packaging system open to the community | * '''Packaging policy''': Define a clear packaging policy for MeeGo, and keeping the packaging system open to the community | ||
* '''Package maintaining''': Provide an interface for maintainers of a package to maintain their package. | * '''Package maintaining''': Provide an interface for maintainers of a package to maintain their package. | ||
* '''Documentation''': Document package contribution, creation and maintenance. | * '''Documentation''': Document package contribution, creation and maintenance. | ||
| + | * '''Managing dependencies''': Make sure dependencies for user applications are maintained by maintainers. The 'Surrounds' area will prevent developers from having to maintain their whole dependency chain. | ||
| + | |||
| + | This WG area would also provide a support function for other teams and workgroups. | ||
| + | |||
| + | Provide a community interface into the core release engineering activity to align with Release Managers and a handle the impact of changes in Core. Gather issues seen by the community and relay those to Core. | ||
=== Contributors === | === Contributors === | ||
| + | |||
MeeGo members interested in taking an active role in this working group. Please detail your interests and what you can contribute to the group: | MeeGo members interested in taking an active role in this working group. Please detail your interests and what you can contribute to the group: | ||
* [http://meego.com/users/xfade Niels Breet] - maemo.org webmaster and long time maemo.org community member. Liberated by Nokia to work on community infra and community repository infrastructure for maemo.org. Interested in doing the same for meego.com. | * [http://meego.com/users/xfade Niels Breet] - maemo.org webmaster and long time maemo.org community member. Liberated by Nokia to work on community infra and community repository infrastructure for maemo.org. Interested in doing the same for meego.com. | ||
* [http://meego.com/users/stskeeps Carsten Munk] - maemo.org distmaster and Mer lead developer. Liberated by Nokia to work on OS development facilitation in the community. Interested in helping shape packaging policy and distribution level choices. | * [http://meego.com/users/stskeeps Carsten Munk] - maemo.org distmaster and Mer lead developer. Liberated by Nokia to work on OS development facilitation in the community. Interested in helping shape packaging policy and distribution level choices. | ||
| - | * [http://meego.com/users/jeremiah Jeremiah Foster] - maemo.org debmaster and Core Integration Team Lead for | + | * [http://meego.com/users/jeremiah Jeremiah Foster] - maemo.org debmaster and Core Integration Team Lead for GENIVI. Interested in keeping the packaging process transparent and open with greater community participation at all levels using best practices. |
* [http://meego.com/users/th0br0 Andreas Osowski/th0br0] - Fedora packager(RPM) (and ambassador) and new maemo.org community member --> Interested in getting the packaging process started, working on packaging policies and helping with packaging | * [http://meego.com/users/th0br0 Andreas Osowski/th0br0] - Fedora packager(RPM) (and ambassador) and new maemo.org community member --> Interested in getting the packaging process started, working on packaging policies and helping with packaging | ||
| - | * [http://meego.com/users/gcobb Graham Cobb/gcobb] - Maemo Community Council member and long term maemo.org community member and developer. Interested in avoiding the "repository hell" we had early on in the Maemo world and in learning from maemo.org experience with the extras-* structure. | + | * [http://meego.com/users/gcobb Graham Cobb/gcobb] - former Maemo Community Council member and long term maemo.org community member and developer. Interested in avoiding the "repository hell" we had early on in the Maemo world and in learning from maemo.org experience with the extras-* structure. |
| + | * [http://meego.com/users/lbt David Greaves/lbt] - Mer build guy and maemo.org member. Introduced OBS to Maemo and working on Nokia build infrastructure. | ||
| + | * [http://meego.com/users/slaine Glen Gray/slaine_] - Moblin commity member. Provides a repo of Moblin packages at [http://slaine.org slaine.org]. | ||
| + | * [http://meego.com/users/clay Clay Carey/Clay] - Moblin community member. Interested in helping with packaging | ||
| + | * [http://meego.com/users/clintcan Clint Christopher Cañada/clintcan] - Uses Moblin extensively on his netbook. Helped a little bit in introducing [http://apt4rpm.sourceforge.net apt4rpm] to [http://www.alinux.tv aLinux] a few years ago through [http://pnutproject.org pnutproject]. Also set up a small repo of Moblin and CentOS packages at [http://ostalks.com ostalks.com]. Interested in helping out with packaging. | ||
| + | * [http://meego.com/users/gaveen Gaveen Prabhasara/gaveen] - a DevOps guy. Planning to become a Fedora packager soon. Can help with RPM packaging and Linux infrastructure. | ||
| + | * [http://meego.com/users/kimitake Kimitake] - long time maemo.org community member and have maintained Qt for diablo (for N8x0) package. | ||
| + | * [http://meego.com/users/zigbee Kozinov Ivan/ZigBee] - MeeGo community member. Interested in packaging. Maintainer of [http://forum.meego.com/showthread.php?t=1451 Community repo] | ||
| + | * [http://meego.com/users/sage Marko Saukko/Sage] - MeeGo community member. Interested in packaging and reviewing packages. | ||
| + | |||
| + | The initial representatives are: lbt (David Greaves) and th0br0 (Andreas Osowski) | ||
| + | |||
| + | === How to contribute === | ||
| + | |||
| + | Volunteer to work in a particular area, participate constructively in conversations and help develop code, docs, processes or community spirit... | ||
| + | Add your name to the list above and dive in - this is a community project. As usual, respect the status quo until you understand why it exists - but then feel free to offer constructive criticism. | ||
| + | |||
| + | Feel free to ask for help on irc, the mailing lists or the forums. | ||
[[Category:Community]] | [[Category:Community]] | ||
The role of MeeGo working groups are explained at http://meego.com/about/governance
This is a request to the Technical Steering Group to approve the creation of a Repository working group. There is no procedure defined but we can improvise with some common sense.
To set the context: like most linux distros, MeeGo will inevitably consist of "MeeGo supported packages" and "Community supported packages" this proposal is about the latter.
Contents |
The (so far un-official) Repository Working Group (RWG) held its first meeting on Sunday, 21. March 2010.
N.b. It has been suggested that the name is not quite right - maybe "Community Repository WG"... but since MeeGo aims to be a community project then phrases like Non-Core or Unsupported or "Surrounding Repository WG". At this point lets focus on the objective, not the name.
The Repository Working Group (RWG) would define and oversee implementation of the strategy for publishing community created software with the MeeGo project.
The goal of the RWG would be to unite the various community contributions interested in applications & libraries, packaging, policy, QA processes, building, etc **and integrate them with Core release engineering***
We realize this is a wide scope but feel it should have coherent representation in the community.
We propose 3 sub-groups to cover:
The nature of this area means it would likely form a gateway to the inclusion of packages in MeeGo Core and a community maintainable location for packages removed from the Core.
The proposed repositories would cover distinct areas:
This area would provide a home for more discrete applications with individual release cycles. This brings something equivalent to the maemo.org Extras repository to MeeGo.
MeeGo plans to be a first class distribution and should not prevent packages from being made available. Cf MeeGo:Universe and MOTU. Surrounds therefore provides a more coherent set of inter-related or depended-upon libraries and applications. The entire collection would follow the same release cycle (which may be the same as MeeGo Core). The surrounds area would probably support historical releases of MeeGo for situations where vendors didn't provide updates for devices.
It may make sense for the Surrounds area to establish relationships (close, arms-length, formal or informal) to maintainers in other community distros to share the burden of maintaining some packages.
Policy would cover:
This WG area would also provide a support function for other teams and workgroups.
Provide a community interface into the core release engineering activity to align with Release Managers and a handle the impact of changes in Core. Gather issues seen by the community and relay those to Core.
MeeGo members interested in taking an active role in this working group. Please detail your interests and what you can contribute to the group:
The initial representatives are: lbt (David Greaves) and th0br0 (Andreas Osowski)
Volunteer to work in a particular area, participate constructively in conversations and help develop code, docs, processes or community spirit... Add your name to the list above and dive in - this is a community project. As usual, respect the status quo until you understand why it exists - but then feel free to offer constructive criticism.
Feel free to ask for help on irc, the mailing lists or the forums.