(→Contributors) |
|||
| Line 56: | Line 56: | ||
* [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] - 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. | ||
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 can improvise with some common sense.
Contents |
The (so far un-official) Repository Working Group (RWG) held its first meeting on Sunday, 21. March 2010.
Please expand.
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.
We realise 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 1st class distro 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.
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)