[FFmpeg-devel] [RFC] roots duties and rights

[Michael Niedermayer]

On Mon, Oct 11, 2010 at 10:48:34PM +0200, Benjamin Larsson wrote:
> On 10/11/2010 01:23 PM, Michael Niedermayer wrote:
> > Hi
> > 
> > Attila asked me to start a discussion about what duties and rights root should
> > have.
> > 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
> > Duties:
> > * 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
> 
> Ok, but there could be just one security item, "Try to keep the system
> as secure as possible". Less items are better.
> 
> > * 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
> 
> in consensus with most of the main developers.


> 
> >   - Open and Close SVN/GIT accounts if requested by the project leader (root can
> >     not reject such requests)
> 
> in consensus with most of the main developers.

elaborate please.
Its sometimes needed to close someones account, the only person whos account
has been closed by me in ffmpeg was uotis and that was not in consensus with
anyone, it was only my decission because i knew it was for the better of the
project.
In mplayer uotis fate was decided by vote with 3/2 beiing in favor of
closing his account. Diego then called people on the phone until the
majority for closing was lost. Over the following years then one developer
after the other left citing uoti as reason. Until a new vote was done that
reached a unanimous result for permanent expellation.
I dont think its a good idea to change what worked better to something that
worked worse in practice. But iam not sure what exactly you propose.
I never would expell someone if there is consensus against it and i dont
mind that being written in some rules but in uotis case it surely was
worlds better to do it instead of long public votes and discussions. These
public votes and discussions about people do harm on their own no matter
what outcome ...


> 
> 
> >   - 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
> 
> Loose this.

I hoped i could prevent ffmpeg-windows creation request ignorance from
repeating



> 
> >   - Root shall in case of ambiguity of a request ask instead of guessing.
> 
> Loose this.

as people prefer, i tend to prefer to state the obvious but well ...



> 
> > * Have plans in place for total hardware failure (fire / earthquake / ...)
> > * Have plans in place for the system being successfully hacked
> 
> Merge this to one.
> 

> > * 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.
> 
> Loose this.

i dont think this is a good idea


> 
> > * 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.
> 
> Loose this.

as people prefer


> 
> > * 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
> > 
> 
> 
> Loose this.

elaborate why please, i see nothing bad or hard on this and its something root
has not done correctly in the past



> 
> > 
> > Rights:
> > -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.
> 
> Loose this. If the current root group thinks that they need more help
> candidates should be chosen by the main developers in consensus.
> 
[...]
> > -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.
> 
> Loose this.

I disagree, root is responsible for the system and root must have the right to
delegate where they need to people root trusts.
A mythical group of main developers, that in addition is spread over 2 and maybe
in the future more projects cannot do this
Its just neither practical nor IMHO a good idea.


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101012/d7b5cf61/attachment.pgp>