[maemo-community] [Council] First community issue

[From: Andrew Flegg]

On Mon, Sep 15, 2008 at 4:01 PM, Ryan Abel <rabelg5 at gmail.com> wrote:
> Well, the Maemo Summit seems like a good time for the council to pick
> up its first community issue (actually, for this particularly issue,
> it's more important than most).

Indeed.

> Unfortunately, and as usual, Nokia decided to nullify most of the
> beneficial side-effects by making things more complicated than they
> needed to be. For whatever reason, they've decided to give each update
> its own update repository (diablo/, diablo-1/, etc.).

Presumably, this is the cause of me not being able to reinstall
osso-software-version-rx44, or microb-engine, after a slightly broken
"upgrade" at the Maemo booth?

> 1. All updates are kept in a single repository for that release
> (diablo/ for Diablo, fremantle/ for Fremantle, etc) and all of the
> latest system packages are available there. This means all system
> packages are recoverable through apt, o-s-v is always available and
> the world is generally a happier place.

Sounds ideal.

> So, council members, if this sounds like a reasonable issue to you,
> think you can hunt down the Maemo release team while your there and
> see what sort of a compromise can be reached. :)

We discussed this, and a few other things at the summit. Here's a list
of various goals, aims, projects and tasks that were mentioned or
suggested by community members (within my earshot):

    * Updates in same repositories.
    * Hold root account details for maemo.org.
    * Review election process & electorate requirements.
    * maemo.org communication guidelines (e.g. logo colours,
      presentation templates etc.)
    * Help make maemo.org recruitment decisions.
    * Push through community-led decisions on package section
      mess.
    * Reduce Quim's workload by an hour per week/month.
    * Define a Council "code of conduct".
    * Start process for Maemo Summit 2009 planning.
    * Help with Maemo Community budgetary requirements.
    * Eduardo/Tim/Simon: any others?

Some of these are aspirational, others more concrete. I think the
feeling during the summit was that the first item above (and the cause
of the thread) may be a little too big to start with for three
reasons: let's see what Nokia do with the /next/ SSU; let's get our
own house in order first and let's pick up the easier ones first.

We did a strawpoll of who'd voted: it was about 50-60%, I'd say
(E/T/S: did you get a better count?[2]). Before the results, there was
a lot of strength of feeling about the election process[3]. I'd
suggest this should be our first order of business; especially with
the requirement for a referendum and the possibility of software
changes.

> [1] The interesting thing here is what this says about Nokia's ability
> (or inability) to handle frequent small-scale point releases. . . .

This is a very good point, and when we pick this issue up, we should
ask Nokia if they know the right thing and aren't doing it for
pragmatic reasons; or require some community assistance in determining
the best solution. Even in the former, I'd like to think we've got
enough lateral thinkers in the community to come up with a better
approach.

Cheers,

Andrew

[2] Not you, Eduardo - you probably couldn't see straight ;-)

[3] Although, brontide did kindly say that the turnout - and
    spread of votes - did validate the existing approach is
    workable, even if sub-optimal.

-- 
Andrew Flegg -- mailto:andrew at bleb.org | http://www.bleb.org/
maemo.org Community Council member