Sousou, Imad wrote: > >> On Behalf Of Dave Neary >> So, to rephrase the question Anas, are you aware of an independent >> repository which will be available to community developers to upload >> their applications & make it easy for MeeGo users to install them on >> their MeeGo devices? > > Our thinking (and we should discuss this at the next TSG meeting) is that > there are > two repositories; Two? I assume you mean two areas with a variety of QA-levels of repo in each area.
> first is the software platform which would include the software > platform itself including the reference user experience and applications; so "Core" Including Trunk, Testing, Stable, Archives? Also I assume this area is managed for security and provides Trunk:Security, Testing:Security, Stable:Security, Archives:Security? (although I note the core has no app-mgr and so won't have a deployment mechanism... OK) Also I'm assuming (until we see the codebase) that meego core will be relatively small. Enough to boot and run a reasonable set of reference apps but not likely to contain an ldap server or lighttpd & apache2. > then > another repository for the "extras" or "garage" where it will probably focus > more > on applications with the garage including a client side app allowing for installation > of apps and components into a MeeGo distro. Again I assume you mean an area with multiple QA levels. This one area contains all non-core libraries and applications. This is 'extras' & co in maemo and tbh, is probably one of the simplest areas to handle :) However, as I've been banging on : what about the 'expected infrastructure'? A developer writes/ports an app and finds a few dependencies missing. She ports the libraries too and pushes them into the garage. A little later another dev ports another app and uses/needs a newer version of the same dependency. Is the first dev the de-facto maintainer? How do we handle that? Maybe we have Core:Yolk (see above) and Core:White? Core:White may provide a mechanism to adopt packages into a community maintained area of 'supported' libraries and applications (cf Universe) Along these lines (and considering the automation mentioned a while back) I'd very much like to see a way to establish a relationship with other distros - sometimes 'upstream' doesn't cut it. Upstream may be dead or simply obnoxious and the patches and features are simply available from another distro. How is this handled? Especially because that will potentially impact version dependencies. Note that it's a community decision to implement and manage something like Core:White > Much more to come on this in the next > few days... and will certainly be topic of discussion at the next steering > group > meeting (which I believe is this friday) Ah, OK, so there's an announcement of a "Community Working Group" meeting on Sunday and the TSG decides to have a separate (private?) meeting on Friday. If you're not careful that will not be interpreted well :) There have been questions about how packages flow through build systems - TBH it's not 100% decided yet but certainly the work done on the Maemo Extras area will not be wasted and the new systems should look familiar (but will certainly address issues raised by people like Graham Cobb). Other key build system questions include: * Where will the main community builds take place? * Where will builds against Meego+vendor releases take place? I think this should all be done on the same build service instance which may or may not be the same instance used for the Core. David -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
