On Apr 20, 2010, at 12:24 AM, David Greaves wrote: > > > So is this area managed by the core project? > How can it be? MeeGo core is a distro, not an app-store or sourceforge. It has > no policies or processes for handling non-affiliated applications. There isn't > even community access to the core build system.
If there is no access to the build system, MeeGo is effectively closed. We'll have to evaluate the efficacy of MeeGo as a distribution in that case for our project. A clear, unequivocal statement about the build system's accessibility to outside developers, including submission of sources, timely availability of resources, as well as documentation and input into toolchain is critical for our evaluation of a platform to build on. > > Build > ===== > Having outlined what repositories are covered we need to look at how community > code gets into those repositories; the build service. > > The build service is a crucial part of both packages and surrounds; the > selection of the OBS allows effective integration between build, QA and > publication (and potentially DVCS too). This is another key reason for the > end-2-end scoping for the RWG in the proposal. At this point, lack of access to OBS and the lack of documentation of OBS are two risks for the wider adoption of MeeGo. Is there work being done in this regard? Particularly interesting is thorough OBS documentation. > > Whilst a case can be made to limit access to the core MeeGo build system to > ensure finite compute resources are available to the core developers, it makes > no sense for the community to have independent build systems for both packages > and surrounds; a single service would cover both; this is another reason why > applications and surrounds are both within the RWG. I strongly suspect that separate independent build systems will blossom anyway due to the closed nature of proprietary code being placed in so-called "app stores." I think that a lot of application vendors see their build systems as strategic, MeeGo will have to convince them that they can build in the open. > > Document > ======== > > The community already puts a lot of effort into the documentation; the RWG > would > provide a focus for areas within its scope. > > Much of the RWG's work would result in additional documentation; indeed it is > quite likely that issues arising would not be considered closed until they > were > documented appropriately. Good documentation will make MeeGo much more valuable to vendors as well as upstream. > > I hope this provides some foundation for discussion and enables the TSG to > consider the proposal further. Thank you David, good stuff. Jeremiah ============================================= Jeremiah C. Foster Core Integration Team Lead, GENIVI Pelagicore AB Ekelundsgatan 4, 6tr, SE-411 18 Gothenburg, Sweden Mobile: +46 (0)730 93 0506 E-Mail: [email protected] =============================================
_______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
