[Mageia-webteam] Webteam peers, bootstrapping

[Maât]

Le 06/01/2011 14:27, Romain d'Alverny a écrit :
> On Thu, Jan 6, 2011 at 13:19, Michael Scherer <misc at zarb.org> wrote:
>> Le jeudi 06 janvier 2011 à 12:09 +0100, Romain d'Alverny a écrit :
>>> What do peers have that non-peers do not?
>>> [...]
>> How are access to $VCS will be handled ?
>>
>> The possibility of having access to server to either read logs or run
>> some limited commands was also asked, how would it articulate with this
>> scheme ?
> I had written a § about it but thought it was too early here. Anyway,
> here are my thoughts:
>
>  * VCSes:
>    - read access for everyone (peers & non-peers);
>    - write access for:
>      - webmasters (specific role, see below)
>      - app manager, who should in turn be able to provide a write
> access to other peers (developers), on demand? if that's possible
>      - or for all peers, with each developer/app manager having a
> careful look at what happens.
Indeed integration and merging need to be controlled by a restricted number of people

but we could also provide branches or repos with write access to developpers (subversions sub-repos are perfect for that unless we decide to use things like git or mercurial)

but if i'm not mitaken there is nothing available offering such a fine grained access control :-/

>      - or maybe it can be app-specific (depending on the app-criticity)
>      - of course, something making push/merge requests possible could
> help (writable only by manager+webmasters, leaving everyone else push
> changes to be merged after review)
>
Have we designed the standard lifecycles for patches and the standard merge/qualification processes ?
>  * server logs:
>    - read access to webmasters
>    - some limited commands? what type? rsync/svn/git types?
>
for example : forums we'll be deploying forums versions with git
>  * server deployment:
>    - staging from a branch available to all peers
??
>    - production push from staging available to webmasters only
ok
> Webmasters are necessarily peers; they do master the whole websites,
> deploy into production with the assistance of app developers (in
> short, with sysadm, they are the ones having the production-push
> button and the ability to check on logs). Of course, this requires
> webmasters & sysadm to go along well.
yup
>  So sysadm would have at least a
> consultative say on who can become a webmaster.
>
agreed
> At this time, this role is managed by (non-sysadm people): me and
> damsweb for blog/www (editorial stuff), I believe all the rest is
> pushed by sysadm at this time.
>
> Advice?
>
> Romain
OK with the schema but i wonder how we'll manage ACL part without pain :-/

Maât