Hi, I think we have a mismatch between the name and the content. "Repository Working Group" is a problematic denomination, while most if not all your points are clear and probably easy to agree upon.
"Repository" is a too broad concept: the whole MeeGo release sits in a repository and it's easy to get confused thinking that the scope is the whole repo = the whole release. The scope proposed is the repository/ies hosted at meego.com containing packages not officially supported in a MeeGo release. - The repos containing the MeeGo official release are out of scope. - The MeeGo compatible app stores managed by vendors or other third parties are out of scope BUT the tools and guidelines for those frontends would be within the scope of this team. Is this right? This is the first thing to agree upon. How to call this? Names carried from maemo.org or moblin.org would be "Downloads", "Extras" or "Garage". "Apps", "Addons", "Catalog" are also used in similar contexts. None of them is perfectly accurate but calling it "Universe/Multiverse" is probably not the best solution either. :) So what about "Downloads" as a compromise between clarity and accuracy? David Greaves wrote: > I think two main issues were raised: [2] > * Is a WG needed? At this point it is clear that "Working Groups" are being defined as teams primarily in charge of vision, strategy and roadmapping. The TSG plans to set up some of those for the different UX categories, and probably that's it. However, this doesn't affect the purpose, scope and "power" of this team if it gets up and running. Let's leave behing the "WG" and let's continuw with the definition work? "Downloads team". How does this sound necxt to the "Program Office"? (this is how the "Core team" could be called) > * Isn't this covered in the MeeGo 'Core' project structure? At least I don't see it. The Program Office has a clear mission which consists on shipping great MeeGo releases every 6 months. The proliferation of a great offering of additional software is a different mission that deserves its own focus. Can we discuss and agree first on all these general terms? Once they are clear and agreed it will be easier to agree on more specific details. Arjan said something in the MeeGo work group last week that got stuck in my little brain: any topic that ends up in the TSG is a failure in the system. :) There is no officially nominated responsible for this area but a key person is Bob Spencer from Intel. We discussed few weeks ago at Portland about how to approach the Downloads repository and how to introduce a reliable and community friendly QA process. All in all the maemo.org Extras process was seen as good source for inspiration - http://wiki.maemo.org/Extras For practical reasons, I would say that getting Bob on board and syncing with whatever are his ideas and plans is a first step in the right direction. If Bob is not in the loop or disagrees with the proposal then is quite pointless to jump to the TSG again. > [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 -- Quim Gil + N900 open source advocate MeeGo Devices @ Nokia _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
