[Mageia-webteam] Webteam peers, bootstrapping

[Michael Scherer]

Le jeudi 06 janvier 2011 à 14:27 +0100, 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);
the easy part

>    - write access for:
>      - webmasters (specific role, see below)
so we need a group in ldap for that, i guess ?

>      - app manager, who should in turn be able to provide a write
> access to other peers (developers), on demand? if that's possible

everything is possible, but IMHO, question is "wouldn't it be better to
have one single group". 

Historically at Mandriva, once you had commit right, you could commit
everywhere, and few problem arised from that. Same goes to gnome. I am
not keen on adding acl everywhere given the increased administrative
load it create ( for sysadmin as we either have to do it, or write some
delegation tools, for people who need to request before fixing anything,
and for app manager who need to approve requests ).

>      - or for all peers, with each developer/app manager having a
> careful look at what happens.
>      - 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)

I would let people decide, with a strong emphasis on letting people in
mga-commiters group by default. In 7 years at mdv, I never seen any
problem of mis commiting, and I think the potential problem a separation
would solve do not suffice to justify the cost.

Now, I only speak of a svn centric view and workflow, as for git, it
could be much more different ( or not ). 

For git like all dvcs, we are slightly more free in term of workflow, as
explained for example here
http://doc.bazaar.canonical.com/bzr.1.18-html/en/user-guide/bazaar_workflows.html .

And so I feel that industrialisation of project hosting ( as we are
somehow starting to do ) will be detrimental to the freedom of choice,
and we should agree on a few workflow before starting to deploy too much
things. ( ie, if we do want to automate thing, and that's one of the
sysadmin team goal ).

Deploying a simple git repository managed like a svn one would be easy
and fast. But that would be marginally better than git-svn.

Deploying a full system with workflow delegation is much more difficult,
but that's what we would want.

So a compromise would be to decide for 1 simple workflow, use for
everything in the first place, and postpone the deployment of a full
system to later.

>  * server logs:
>    - read access to webmasters
>    - some limited commands? what type? rsync/svn/git types?

Well, limited command could be hard to achieve. I assume that read logs
is just "set permission properly" ( easy to do ). Limitation of command
could be done with sudo, but wouldn't change much if we give access to
shell.

>  * server deployment:
>    - staging from a branch available to all peers
>    - production push from staging available to webmasters only

We can :
- use sudo + script + ldap group
- use $VCS based tags/branch + acl ( potentially based on ldap group
again )

> 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. So sysadm would have at least a
> consultative say on who can become a webmaster.
> 
> 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.

dams is sysadmin ( and I am picky, but sysadmin is the name of the team
in ldap, I do not know why people say sysadm everywhere, likely because
of the name of the list and irc channel  :/ ). 

So to summarize :
- external people
- webteam members 
- webmasters

So 1st step, adding 2 group to ldap ?
-- 
Michael Scherer