Meeting Focus is on *Policies* - please keep potential solutions for a follow-up meeting.
This meeting is to be used as brainstorm for policies regarding community repositories inside the MeeGo Community OBS. Feel free to add ideas, comments, questions to this page. Make sure you end your line with
--~~~~
so it is clear who posted what.
lbt wrote this blog post which may help with ideas: http://mer-l-in.blogspot.com/2011/01/meego-community-development-apps.html some ideas from there are identified below.
Mechanics of QA
What basic rules should we test for to move from the Apps:Testing and Apps repos promotion?
Proposal here:
http://wiki.meego.com/MeeGo_Apps#Promotion
- Quality: Do we insist on a valid bugtracker being identified for all Surrounds packages? Must it proxy via a bmc#?
- more ideas here ...
Surrounds
http://wiki.meego.com/Community_Office/Task_Forces/MeeGo_Surrounds_and_Extras/Surrounds#QA_and_Releases
Note that this is probably out-of-scope for this initial meeting; but ideas can be collected here.
Control and Management: Fixing mistakes and setting the boundaries
- Should we start off with a small group of people who have total control over this area (ie can remove/reject packages, accounts, teams etc) for a given time (6-12 months?) and who should be tasked with documenting policy and a management structure to replace them. As per Andrew's email : http://lists.meego.com/pipermail/meego-community/2010-December/003021.html One example is mistakenly giving someone admin rights for the KDE Team area when they turn out not to be affiliated with KDE, just some wannabe hacker.
- more ideas here ...
Policy for Teams (python, kde, etc etc)
More info: http://wiki.meego.com/Community_Office/Task_Forces/MeeGo_Surrounds_and_Extras/Community_OBS#Team_Areas
- Only for large and complex projects?
- What stops a random bod from grabbing a well known name? Should we veryify some kind of association with upstream?
- Commercial: I've had commercial organisations enquire about using the community OBS. I've had them ask to sponsor it. How do we deal with this? My first reaction is "no commercial work"... but why not?
- more ideas here ...
Acceptable content
- Licenses: OSI only licenses? GPL3 (considering the "promotion to core" target).
- Legal : Do we accept mp3 players? libdecss? What about porn? What about apps with a rather rude splash screen? Any patent issues? (Don't forget the system physically lives in the "land of the free" so is subject to state seizure by the RIAA).
- more ideas here ...
random policy questions
Starting list from lbt's email:
- People: What's the process for absent devs? If someone says "hey, lbt, let me upload a new version of that library Shane uploaded" ... do I just let her? What if there's a security issue in it? What if you've not been seen in 3 months? Do maintainers need to demonstrate reliability to handle timely updates?
- Can we rebuild MeeGo with some different compiler flags (think non-ssse3 ... yay ... I can run MeeGo on my AMD desktop at last!)
- Do we sign any of the community repos? What does that mean?
- Acceptable Use Policy : at what point do we ask users to stop doing what they're doing?
- Non-MeeGo targets? When Smeegol becomes Sogmeel will we allow it to be a target?
- more ideas here ...