<div dir="ltr">Hi team,<div class="gmail_extra">
<br><br><div class="gmail_quote">2014-01-27 Jonas Smedegaard <span dir="ltr"><<a href="mailto:dr@jones.dk" target="_blank">dr@jones.dk</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


Greetings, fellow Javascript hackers,<br>
<br>
Quoting Jonas Smedegaard (2014-01-02 16:29:30)<br>
> Quoting Jérémy Lal (2014-01-02 13:01:12)<br>
>> I wonder if there is a minimum official requirement for granting SCM<br>
>> commit access to newcomers.<br>
><br>
> At most there is "common practice" and of that there is several:<br>
> Alioth is provided by Debian and has the requirement that its use<br>
> should be related to Debian, but apart from that we decide on our own<br>
> how we want to work internally in our team.<br>
><br>
> I like to avoid taking or giving orders from others, and since we use<br>
> Alioth only as central "hub" for distributed resources (git and<br>
> mailinglists) I see no need for hierarchy and routinely appoint "super<br>
> cow powers" to any newcomer to our team.<br>
><br>
> If others insist that we should have hierarchy and distrust newcomers<br>
> until they somehow prove themselves worthy of higher power, then I<br>
> will demote myself to the lowest power (and consider leaving the<br>
> group).<br></blockquote><div><br></div><div>That would be very sad, and a big loss to this team. Please don't do that ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



<br>
Noone commented on this part.<br>
<br>
Last call: If noone argues to the contrary, I will promote all team<br>
members to admin status one week from now.<br></blockquote><div><br></div><div>I have no issues with this. Benefit of SCM is that you could always revert to a previous version, if bad stuff were to happen.</div><div>The question is what would happen if folks with admin rights would delete entire repositories. Are they backed up somewhere, to be able to revert the bad action?</div>

<div><br></div><div>Committing to the SCN doesn't equate being able to upload packages. (see [0] for an example)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
> Speaking of which:<br>
><br>
> I have till now mostly used collab-maint instead of our own git area<br>
> to ease contributions from other Debian members.  Alioth now (since<br>
> some time) allows any team to grant write access to all official<br>
> Debian members, similar to the access rights of collab-maint.  Do<br>
> anyone in this team disagree with enabling that additional right to<br>
> our git, or is it ok that I enable it (and start move packages from<br>
> collab-maint to our own git)?<br>
<br>
I have now granted all DDs write access to our team git repository.<br>
<br>
I will start move packages there that I have previously maintained at<br>
collab-maint, and suggest others to do the same.<br></blockquote><div><br></div><div>If I understand this correctly, we're talking about moving away from doing our SCM work in collab-maint, but I guess I've missed to where we would be moving?</div>


<div><br></div><div>Cheers,<br>   +Emilien<br></div><div><br></div><div>[0] <a href="http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-February/004907.html">http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2013-February/004907.html</a></div>

<div><br></div></div></div></div>