[maemo-developers] Public maemo repository

[From: Marius Vollmer]

> The steps for us to put this maemo unstable repository in place are
> not ordinary at all. Create and maintain a public repository is not
> an ordinary task in general. There must be clear reasons to do that
> and a crystal clear collection of needs and requirements.

Change means work and there needs to be a reason for it.  What I find
to be usually missing is however a good justification of the status
quo.

If you abstract enough, most issues can be characterized as:

 - Changing to the new thing means work and comes with risks since the
   new thing is new.

 - Staying with the old thing means no work and has no risks since it
   is old.

The new thing is always at a disadvantage.

But, what is the new thing and what is the old thing depends very much
on what you started with.  maemo _could_ have started with a public
distribution and developer support in the form of more beta releases
and could have implemented its own development processes around this.

Distributions are not a new thing at all and I would like to see the
crystal clear reasons why Nokia decided to derive from Debian sources,
including the packaging, but chose to build something out of it that
is very much unlike Debian.  ('Different needs' isn't a crystal clear
reason.)

We didn't start out with a distribution and now fixing this of course
means work to implement the changes.  This work is mainly caused by
missing the boat in the first place, in my opinion.  The boat was
there but we decided to swim instead.  Maybe because the whole concept
of something that is heavier than water but still floats without
effort seemed to be too good to be true.  Arguing against boats by
saying that it is extra work to climb into them and that you'd rather
continue swimming means that you either don't understand the concept
of boats or you don't plan to go a long way.

Continuing this leaky analogy, we should all be in the same boat of
course.


The work needed to maintain a distribution is not needed because you
maintain a distribution.  You will need to do the work anyway, and a
distribution is a good tool to reduce gratuitous work.  (Work here
includes things like integrating components to work well together,
managing API compatibility issues, defining supported configurations,
and providing smooth upgrades.)

A distribution is a organizational tool.  It significantly amplifies
synergistic effects since people will tend to work in the same
environment and can see and fix integration bugs in a coordinated way.

The thing that a distribution gives you is to be able to say for each
package whether it is 'in' or 'out'.  We could make the following
list:

  http://catalogue.tableteer.nokia.com/certified     $DIST user
  http://catalogue.tableteer.nokia.com/non-certified $DIST user
  http://repository.maemo.org                        $DIST free non-free
  http://repository.maemo.org/extras                 $DIST free non-free

That could be your maemo distribution right there, as a starting
point.  All packages in those repositories are 'in', the rest is
'out'.  It could really be as simple as that.

Looking at recent events, this particular but rather obvious way to
define the distribution would mean that the browser beta is in the
distribution, but neither the SIP beta nor the OpenedHand stuff are.
It is by pure chance that the SIP and OpenedHand packages have subtle
conflicts, and the browser stuff just works, but the distribution
gives you a good idea about what to do next: pull both the SIP and
OpenedHand stuff into the distribution.

The repository layout above is not particularily elegant, and it might
not be totally clear what the requirements are for the distribution
(i.e., should you be able to follow changes to it via apt-get, who is
supposed to be able to actually change it, how do we protect Joe
Couchclick from beta releases?), but it's a starting point and it is
important to have such a starting point so that discussions can
crystallize around something concrete and we don't need to talk so
much in the abstract.  Being concrete helps to understand how much
work you are actually talking about.