(Add porting vs maintaining) |
Contents |
As we know, the open source world is a world of sharing; we regularly stand on the shoulders of our peers and it's considered very bad taste to just 'bundle' a library into a monolithic application. (Notice how I didn't mention any kind of compliance programme by name - aren't I good!)
Surrounds provides a collection of libraries and tools that encourages this best practice way of working in MeeGo and delivers MeeGo-extra apps. The most obvious area would be for languages like perl, python and ruby. These languages have large numbers of useful libs that clearly are not going to be present in core MeeGo. Of course there will be many other tools and applications that would also be at home in Surrounds.
Over time, packages may migrate into core MeeGo and equally, some are going to be deprecated. Hopefully Surrounds makes both of those actions a little easier but we do need to decide how we handle deprecation/promotion of applications/libs between core and Surrounds.
There are many complexities when dealing with a collection of packages like this:
The fundamental question is "How is Surrounds QA'ed and released?".
This is a significant undertaking and needs a lot of resource and users. This alone means that Surrounds should probably start off slowly and ramp up as MeeGo users and developers arrive in larger numbers. The important thing is to prepare for the main issues we're likely to face.
I propose that Surrounds is actually only populated on an "as needed" basis; tools can be submitted directly but libraries have to be needed by a tool or by an application submitted to the Apps area.
For example: let's look at a device that has MeeGo 1.2 installed on it and an application "Wowee" built against an imaginary libvisual-1.0 which is in the Surrounds-1.2-A stable release of Surrounds.
9 months later many libraries have been updated and developers want to use the latest versions... it's time to release a new version of Surrounds-1.2. Sadly libvisual is up to version 1.0a with a minor tweak which would break Wowee; not only that but the Wowee developer has gone awol (so there's no-one to test it) and no-one's stepped up to update it. Even worse there are 50,000 users using Wowee which is working like a dream.
Looking at the large number of apps in Maemo Extras I think problems like this will arise and are beyond the resources of the community to handle at this point.
A technical solution may be that when Surrounds-1.2-A is installed it goes into /opt/surrounds/1.2-A/... and any apps use the appropriate path to find their dependencies.
This allows apps that use libraries from Surrounds-1.2-A and Surrounds-1.2-B to be installed concurrently even if they use different versions.
I'm not sure how Surrounds-1.2 handles upgrades from MeeGo 1.2 to 1.3.
The message however is that there are many issues like this that it would be good to identify in advance. Just ask a maemo developer about the "optification" hack :)
When it comes to populating Surrounds we need to look to the larger linux ecosystem.
Some tools and libraries will have comitted maintainers who have time to monitor their packages and fix bugs and security issues in a timely manner. This is the classic distribution 'maintainer' role.
Some libraries won't. Developers will simply need a particular library and 'grab' a source rpm that looks like it's good-enough. They throw it at the OBS and a few minutes later have an installable package for their application. This is what happens in Maemo Extras.
I call this activity 'porting'.
The problem arises when another developer does the same thing a few weeks later with a slightly different version of the package. This may cause the original app to fail.
Equally, none of those developers want to commit to maintaining the library. So when a security issue arises, no-one is ready to update the package.
I'm actually a little concerned about prolific porting - and sadly this is the bit that gets the fame and glory : "look how many packages he's ported". The truth is that this doesn't bode well for MeeGo in the long run.
My suggestion for this group of packages is to nominate an upstream or partner distro with a good security record and a wide base of packages. Surrounds releases would closely track this distro (and will likely differ from core MeeGo). Packages taken from this distro would be fast tracked as 'ported' rather than 'maintained' and only minimal packaging changes would be allowed. This would allow Surrounds to leverage the partner-distro's security efforts (and hopefully offer benefits to the partner in return).
For obvious reasons I propose openSUSE as the partner distro. (For the record I'm a Debian guy - but lets be sensible here!)
For equally obvious reasons this is a political minefield :)