[FFmpeg-devel] [MPlayer-dev-eng] [RFC] roots duties and rights
Mon Oct 11 14:09:42 CEST 2010
On 10/11/2010 01:23 PM, Michael Niedermayer wrote:
> Attila asked me to start a discussion about what duties and rights root should
> What things people have to provide for the various requests. What they expect
> from root and so on.
> also please keep both ML in the CC in case of replies
> Heres a quick dump of /dev/brain
> * Keep the system running smoothly so all "users" can do their work.
> -Keep the system secure so its not hacked
> -Recognize problems early and take preemtpive action, aka a mail to
> the MLs with "we only have 100 mb space left in incoming" for example
> -Replace hardware when it fails, search for possible donations on ML/IRC
> ask the foundation to fund hw where needed.
> -Install security updates quickly
> -Make regular backups and store them off site, keep past backups so
> undetected corruption does not make them useless
> * Do all the administrative things that normal users dont have the right to
> and that havnt been delegated to volunteers.
> - Create mailinglists that are related to the project when requested by the
> project leader
> - Open and Close SVN/GIT accounts if requested by the project leader (root can
> not reject such requests)
> - Install software that is requested by project members for their work with
> the FOSS projects
> - Open SSH accounts for project members when their FOSS-project related work
> needs such account
> - help with forgotten passwords after the user proofes his identity
> - Root shall attempt to work on requests approximately in order and not ignore
> requests for months
> - Root shall in case of ambiguity of a request ask instead of guessing.
> * Have plans in place for total hardware failure (fire / earthquake / ...)
> * Have plans in place for the system being successfully hacked
> * Root must not involve itself deeply in any of the hosted projects, that is
> to ensure roots impartiality and avoid conflict of interest
> This conflict of interest exists both in form of making decisions as root
> to favor ones personal preference in a project. As well as participating
> in project internal discussions while implicating ones authority.
> * Each project shall have its own incoming directory and who has access to
> move and delete files from this directory shall be the project leaders
> decission. Its each projects duty to move files out of there.
> * Root must have public GPG keys and they must be published where users can
> easily find them. These keys checksums must be available in SVN/GIT of the
> hosted projects so that people who work with the code have means to verify
> roots (and the developers) public GPG keys.
> * Root must before expiration of the previous SSL key either generate SSL keys
> signed by an upstream CA or put self signed SSL keys signed with their
> gpg key on the webpage and ML
> -Reject software installation when there is risk to the security or stability
> of the server
> -Root may resign, in which case new candidates shall be found and a vote
> amongth all developers who had write access prior to the resignation shall be
> held. The project leader of each project has a veto right against candidates.
> This veto right is necessary as root is a service provider and not a power
> position and if one asks for candidates for root the most power hungry people
> in the projects come forward. And it is also important that root is trusted
> by all, more so than root being the one with the prettiest face.
> -Like everyone root can be busy with family, military, jail, girls, pizza,
> in which case it is understood that root cannot attend to their duties for a
> while. But its expected that the roots at least try to have 1 person of them
> reachable by some means of communication within reasonable time intervals
> who has then some kind of internet access within reasonable distance in case
> of emergencies.
> -Root may close an account if
> -(ssh) the account appears unused since a long time and the user doesnt
> awnser email/ML. For project specific accounts like SVN/GIT the project
> leader makes the decision about closing.
> -(any) There is reason to believe that the account is used by someone else
> than the intended user without his agreement and knowledge.
> -(any) The account is used for criminal or malicious activity
> -Root shall if there is no immedeate danger and there is doubt about the
> malliciousness of someones activities try to contact that person before
> account closure to confirm that there really is no misunderstanding and a
> legitimate intent.
> -Root may temporary disable any service if its misbehaving in a way
> that causes harm like a ML sending hundreads of mails, ftp being used for
> warez, ...
> -Root may ban any IP, IP range if accesses from these ranges have happened
> that cause unreasonable stability, security or bandwidth issues.
> -Root may reject requests that are unrelated to the FOSS project from which
> the request is made. Root of course should not unreasonable do so but be
> nice unless there is a reason to reject (like bandwidth, space, time ...)
> root should elaborately explain such rejections to the requesting user
> -Root may reject any request that is missing needed information, that is
> root does not have to go hunting missing details that the user should have
> -Root may delegate any work/rights to other people of roots choice but root is
> fully responsible for that persons actions. Such delegations must be made public.
> root may revoke any such delegation without specifying reasons at any time.
> Duties of the users
> -If the user has reason to belive that ones pland action could affect other
> users or the stability or security of the system then he should contact the
> public mailinglists or root first and or the affected users if its just one
> -Shared files (like incoming and samples) should not be moved or deleted
> without prior public dicsussion on the mailinglists
> -Users shall try to provide all information root needs when making requests
> -For Mailing list creation ML name and ML admin email are needed
> -For creating of SSH accounts a public SSH key and wanted username must be
> submited by secure means
> -For recovering a forgotten password proof of identity and the username is
Given the current list of roles and duties, I found missing the part
regarding "Leader" and other side roles, given the current discontent
among volunteers, it might be useful state them as well.
- He is a developer, thus ALL the developer rules apply to him
- During discussions if the outcome is uncertain he has the last word.
- He can ask root to do administrative tasks (e.g. manage accounts)
- He is a developer, thus ALL the developer rules apply to him
- During discussions regarding his area of influence, he has the last word.
- If the Leader and the Maintainer during discussion cannot agree, the
Maintainer decision takes precedence.
- You can have a hierarchy of Maintainers (e.g. libavcodec -> single codec)
- He has commit access to the common trees
- He can be a Maintainer for a specific area of the project
- He can be the Leader for the project
- He agrees to respect the project policies and rules.
- He proposes patches or patchsets that are approved either by the
Maintainer or the Leader
Agreement Not Reached:
- The discussion lasts more than a week w/out a definite outcome.
Leader and Maintainer roles are agreed by the whole group of developers.
Key ideas: the Leader is a primus inter pares, so the Maintainer within
his area, Leaders and Maintainers should strive to not to stomp over
fellow Developers. Root are developers with more duties. A Release
Officer is a Maintainer. The Maintainer is assumed to have a deeper
expertise than the Leader within his specific field, thus his opinion
wins if agreement could not be reached.
More information about the ffmpeg-devel