So it's been a while since the TSG meeting when the RWG was proposed [1]; not a lot of discussion has arisen naturally (not surprising, there's not a lot for the community to build around yet).
So maybe we can review what we think will be needed. I think two main issues were raised: [2] * Is a WG needed? * Isn't this covered in the MeeGo 'Core' project structure? I think there is general agreement that Imad was correct in saying "it is larger than a working group" - so I'd like to recap the proposal here and consider the points above for each of the areas. The main interest areas for the RWG are, naturally, the repositories and arising from that, build and documentation. So lets review the scope and relate that to the MeeGo Distribution. Repositories ============ The proposal is that the RWG take responsibility for managing the applications repository and the community supported packages repository; more specifically the associated QA, policies and processes. The first thing to notice is that there are 2 kinds of repository areas. a) Individual packages b) Community non-core packages : Surrounds The individual packages have a development/release cycle which is independent of other packages and independent of MeeGo itself. Indeed they may support multiple releases of MeeGo over time (eg the GPE suite). This part of the RWG is comparable to a community app-store and has roots in Maemo's Extras and the Moblin garage. As we've seen in Maemo Extras we can provide a lot of community support to this area; but that support needs to adapt to the dynamic needs of a growing community. I suggest that a decision making group is needed to enforce, accept, review and agree changes to policy covering: * QA * package acceptance/removal * security * delivery * infrastructure requirements 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. This is clearly an area where independent application developers are growing out of the community and providing an ecosystem around MeeGo. However it is equally clear that the success of this ecosystem is crucial to the successful growth of a development community around MeeGo that clearly does not exist yet. Both corporate and individual members of the MeeGo family should be looking to allocate resource to this area. Yes a group is needed; Finally, IMHO this is a technical working group, and I would be surprised to see it within the CWG. The second major area is the community non-core packages; this area provides a more coherent set of inter-related or depended-upon libraries and applications. This entire collection would follow the same release cycle (which may well be the same as MeeGo core). The Surrounds area would also probably support historical releases of Meego for situations where vendors didn't provide updates for devices. As originally proposed, it may make sense for the Surrounds area to establish relationships (close, arms-length, formal or informal) to maintainers in other community distros to share the burden of maintaining some packages. So first "Isn't this covered in the MeeGo 'Core' project structure?". No; this is, pretty much by definition, a wider and community managed set of applications. MeeGo cannot possibly accept every library, application or subsystem that is requested by random community members; nor do we want to create a multitude of independent repositories or one-shot packages. However, it does make sense to have an area where code is evaluated and may eventually be sponsored into the core distribution. Packages which become (by some metric) popular and which demonstrate a suitable level of maintainer-ship whilst in the Surrounds may be promoted into the core repository. Additionally, packages which, for whatever reason, are deprecated from the core may continue to be supported in the Surrounds. Similar bi-directional migration paths may apply to people as well as code! Secondly, is a WG neede? Clearly there is a relationship between core, surrounds and individual packages; managing them in a consistent manner seems rational. The purpose of a working group is to provide that consistency and focus. 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. 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 would once again like to clarify: the RWG is not meant be the team managing the day-to-day operations of any autobuilder-like infrastructure; they would instead be providing community objectives and goals to that team. With this in mind the RWG would be the place where the community would work with the build service implementation team to realise the polices and processes outlined above. Whilst it is possible to segregate the repository work described above from the build activity it would appear to make more sense to collaborate closely; certainly a close relationship between the Maemo community and the autobuilder teams has been very successful. 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. I hope this provides some foundation for discussion and enables the TSG to consider the proposal further. David/lbt [1]http://wiki.meego.com/Proposal_for_a_Repository_working_group [2]http://trac.tspre.org/meetbot/meego-meeting/2010/meego-meeting.2010-03-31-19.58.log.html#l-100 -- "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
