On Mon, Sep 15, 2008 at 4:01 PM, Ryan Abel <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] | http://www.bleb.org/
maemo.org Community Council member
_______________________________________________
maemo-community mailing list
[email protected]
https://lists.maemo.org/mailman/listinfo/maemo-community
