(→Contributors) |
(→Contributors) |
||
| (4 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, | + | 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 === | === Announcement === | ||
| Line 9: | Line 9: | ||
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]. | 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 === | ||
| Line 17: | Line 17: | ||
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*** | 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 | + | We realize this is a wide scope but feel it should have coherent representation in the community. |
We propose 3 sub-groups to cover: | We propose 3 sub-groups to cover: | ||
| Line 24: | Line 24: | ||
* Document: take responsibility for the MeeGo community packaging documentation | * 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 | + | 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 === | ||
| Line 34: | Line 34: | ||
This brings something equivalent to the maemo.org Extras repository to MeeGo. | 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 | + | 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 | + | 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. | 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. | ||
| Line 60: | Line 60: | ||
* [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/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/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/slaine Glen Gray/slaine_] - Moblin commity member. Provides a repo of Moblin packages at [http://slaine.org slaine.org]. | ||
| Line 67: | Line 67: | ||
* [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/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/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) | The initial representatives are: lbt (David Greaves) and th0br0 (Andreas Osowski) | ||
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.