1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-webteam] Webteam peers, bootstrapping
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Webteam%20peers%2C%20bootstrapping&In-Reply-To=%3C4D25D0E9.3060704%40vilarem.net%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="000096.html">
<LINK REL="Next" HREF="000099.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-webteam] Webteam peers, bootstrapping</H1>
<B>Maât</B>
<A HREF="mailto:mageia-webteam%40mageia.org?Subject=Re%3A%20%5BMageia-webteam%5D%20Webteam%20peers%2C%20bootstrapping&In-Reply-To=%3C4D25D0E9.3060704%40vilarem.net%3E"
TITLE="[Mageia-webteam] Webteam peers, bootstrapping">maat-ml at vilarem.net
</A><BR>
<I>Thu Jan 6 15:25:45 CET 2011</I>
<P><UL>
<LI>Previous message: <A HREF="000096.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI>Next message: <A HREF="000099.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#97">[ date ]</a>
<a href="thread.html#97">[ thread ]</a>
<a href="subject.html#97">[ subject ]</a>
<a href="author.html#97">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>Le 06/01/2011 14:27, Romain d'Alverny a écrit :
><i> On Thu, Jan 6, 2011 at 13:19, Michael Scherer <<A HREF="https://www.mageia.org/mailman/listinfo/mageia-webteam">misc at zarb.org</A>> wrote:
</I>>><i> Le jeudi 06 janvier 2011 à 12:09 +0100, Romain d'Alverny a écrit :
</I>>>><i> What do peers have that non-peers do not?
</I>>>><i> [...]
</I>>><i> How are access to $VCS will be handled ?
</I>>><i>
</I>>><i> The possibility of having access to server to either read logs or run
</I>>><i> some limited commands was also asked, how would it articulate with this
</I>>><i> scheme ?
</I>><i> I had written a § about it but thought it was too early here. Anyway,
</I>><i> here are my thoughts:
</I>><i>
</I>><i> * VCSes:
</I>><i> - read access for everyone (peers & non-peers);
</I>><i> - write access for:
</I>><i> - webmasters (specific role, see below)
</I>><i> - app manager, who should in turn be able to provide a write
</I>><i> access to other peers (developers), on demand? if that's possible
</I>><i> - or for all peers, with each developer/app manager having a
</I>><i> careful look at what happens.
</I>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 :-/
><i> - or maybe it can be app-specific (depending on the app-criticity)
</I>><i> - of course, something making push/merge requests possible could
</I>><i> help (writable only by manager+webmasters, leaving everyone else push
</I>><i> changes to be merged after review)
</I>><i>
</I>Have we designed the standard lifecycles for patches and the standard merge/qualification processes ?
><i> * server logs:
</I>><i> - read access to webmasters
</I>><i> - some limited commands? what type? rsync/svn/git types?
</I>><i>
</I>for example : forums we'll be deploying forums versions with git
><i> * server deployment:
</I>><i> - staging from a branch available to all peers
</I>??
><i> - production push from staging available to webmasters only
</I>ok
><i> Webmasters are necessarily peers; they do master the whole websites,
</I>><i> deploy into production with the assistance of app developers (in
</I>><i> short, with sysadm, they are the ones having the production-push
</I>><i> button and the ability to check on logs). Of course, this requires
</I>><i> webmasters & sysadm to go along well.
</I>yup
><i> So sysadm would have at least a
</I>><i> consultative say on who can become a webmaster.
</I>><i>
</I>agreed
><i> At this time, this role is managed by (non-sysadm people): me and
</I>><i> damsweb for blog/www (editorial stuff), I believe all the rest is
</I>><i> pushed by sysadm at this time.
</I>><i>
</I>><i> Advice?
</I>><i>
</I>><i> Romain
</I>OK with the schema but i wonder how we'll manage ACL part without pain :-/
Maât
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="000096.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI>Next message: <A HREF="000099.html">[Mageia-webteam] Webteam peers, bootstrapping
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#97">[ date ]</a>
<a href="thread.html#97">[ thread ]</a>
<a href="subject.html#97">[ subject ]</a>
<a href="author.html#97">[ author ]</a>
</LI>
</UL>
<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-webteam">More information about the Mageia-webteam
mailing list</a><br>
</body></html>
|
