This page is used to discuss and plan community OBS structure, teams, PPAs etc. We have a MeeGo Community OBS already; and it builds apps for MeeGo.
It is currently managed by Niels Breet (X-Fade) and David Greaves (lbt) - but we need more help. In part this whole post is a way to structure what we'd like to achieve and to make it easier to identify tasks.
So what project structure do we need? We've not assumed MeeGo at the top level namespace to allow us to support additional distros such as Fremantle and hopefully others.
One common use for structure is to provide a QA route. Packages go from some sub-project in a developer's home: area to a 'Team' area and then into a Testing area. Each transition is subject to policy and quality checks. Defining these workflows and structures correctly will make life easier.
It makes sense for teams to have collaboration for things like KDE, Gnome, Python, LibreOffice, Emacs etc. This would allow more thorough testing to take place before releasing either to Surrounds or Apps
However, what's needed to form a team? Can anyone just step up and claim Team:KDE or should we ask for some relationship with upstream? Do we just want to assess a proposal? Who does the assessment? Do we announce this and give time for the community to raise objections or considerations?
The general policy for *home* projects is "OSI, nothing illegal and don't take the piss". We may (or may not) need a more formal one :)
Certainly these PPAs offer developers a huge amount of freedom. They can start by uploading and building a package in a "home" directory (which can have a structure underneath it for multiple projects). This will allow them to build against any of the main targets; any group/community projects or even any other community member home projects. Oh, and they can use each others code as a baseline too. Once built the packages are automatically published to a repo on the community downloads server.
AFAIUI this is a lot like the Ubuntu PPA solution (hence the heading).
At that point developers can stop if they want. They have a complete set of repositories (1 per subproject). No painful QA processes for them and no 'fragmentation' for the MeeGo community. But equally these repo(s) will needed to be manually added to a device in order for it to appear in any apt-get/zypper/yum etc. Oh, and the Apps downloader team really should pay attention here.
A huge benefit here is that to for a user to get at a development version of an application they use a specific repository, not a mishmash of randomly unstable packages (like the Maemo Extras-devel area).
What MeeGo targets do we support?
MeeGo 1.1 and above make sense. But what architectures? As released is fine - but what if there are community rebuilds of non-ssse3?
Also, when MeeGo releases distro updates, do we just rebuild all apps? What happens to QA at this point?
One area to look at is how often we import MeeGo snapshots - and incur the rebuild cost for any projects targeting them.
Frankly I'm a bit fed up that after a year I can't run MeeGo on my desktop. It has an AMD phenom chip and an ATI card - both well supported in the opensource world. It's time to build a community MeeGo :)
Do we need a community version targeting the DublinBook? What about the O2 Joggler? Are there any policy issues here? Can anyone ask for this - there's potentially a lot of resource tied up doing this kind of rebuild.
What projects are needed in the Surrounds area? Certainly some unstable->testing->stable cycle makes sense; but this is not likely to be finalised until the workflow is understood.
The Fremantle migration. Mmmm. Well it might happen at some point :)