Hi,
sajolida wrote (06 Apr 2015 13:46:32 GMT) :
> intrigeri:
>> sajolida wrote (05 Apr 2015 19:46:22 GMT) :
>>> intrigeri:
>>>> Regarding blueprints.tails.b.o: do you plan to take care of the
>>>> migration once root@??? has set it up, or do you expect -sysadmins@ to
>>>> do so? If the latter, please specify your ideal and worst
>>>> case deadlines.
>>
>>> I would have to understand better what this implies. If this implies
>>> manipulating Git history, I'm not sure I can do it without guidance but
>>> I would be interested to learn.
>>
>>> What would imply rescuing what's currently in wiki/src/blueprint along
>>> with its corresponding history? Do we want this folder to be at the root
>>> of the new repo (moving Git files usually break their history)?
>>
>> It does involve creating a new Git repo that 1. only contains the
>> blueprint directorie's content, and 2. inherits the current Git repo's
>> history for that content, and nothing else.
>>
>> git-filter-branch(1) should get you started:
[...]
> I'll try to do this myself then.
Great.
>> Other than that:
>>
>> * if we want to manage the ACLs ourselves for that new blueprints
>> repo: it requires a master copy of that new repo, somewhere, that's
>> able to push to boum.org whenever it's updated;
>> * otherwise, it can be setup just like our main repo at b.o.
> I think this is getting quite beyond what I'm willing to learn a fits
> better the knowledge and role of tails-sysadmins. What about having
> tails-sysadmins do the Git infrastructure and ACLS and me do the Git
> content and ikiwiki configuration (and learn new Git powers along the way)?
Fine with me. Please create whatever tickets are necessary, and I'll
see with bertagaz what kind of ETA we can aim for.
>> * in any case, we'll need rewrite rules and rewriting links, but that
>> should be all I think.
> Rewrite rules to point https://tails.boum.org/blueprint to
> https://blueprint.tails.boum.org? Anything else?
Yes, same for actual blueprints, that is something like:
^/blueprint/(.*)$ ->
https://blueprint.tails.boum.org/$1
(otherwise, links from Redmine, ML archives etc. will be broken in
the end.)
>>>>> Then staging.tails.b.o will be helpful to work on the real stuff, but
>>>>> this can be set up in the second halt of April.
>>>>
>>>> Same question: who's going to make it happen (expect the parts only
>>>> root@??? can take care of)?
>>
>>> That sounds easier for me technically speaking:
>>
>>> - Have a copy of our main repo at immerda.
>>
>> Well, this only works if you find a way to have a hook in that repo
>> that pushes to boum.org whenever it's updated. To the best of my
>> knowledge, the Git hosting infrastructure immerda provides us is not
>> ready to do that yet, but we can ask them if it's easy for them to set
>> it up. Please Cc -sysadmins@ when you'll do that.
>>
>> Otherwise, we can surely host the master copy of that staging repo on
>> lizard somewhere (this will require to set up some stuff, as right now
>> our only Git hosting infra there isn't for this kind of things, so
>> we'll need to move it or to set up another one).
> The second option sounds easier, but I'll let tails-sysadmins decide.
Works for me => same here, please create the tickets and we'll see
when we think we can do that.
>>> I can send them an email.
>>
>> Uh, no: we (-sysadmins@) are managing our repos and ACLs at immerda
>> ourselves => no need to bother immerda folks with repo
>> creation requests.
> Same here, does that sound ok to let tails-sysadmins do the Git
> infrastructure? It will probably be less work for both of parties in the
> end...
OK.
>> - Add a banner to staging.t.b.o that makes it clear that its content
>> MUST NOT be trusted. E.g. by replacing the logo, or something.
> Ok, I'll take that but this will imply additional Git complexity I
> guess. Another option would be to put that website behind a dummy
> .htaccess password documented along with the new toy in our contributors
> documentation.
I like your KISS solution :)
>> - Decide who's gonna get write access to the new toy via the web, and
>> via Git.
> Via 'web' and via 'Git'? I only thought about Git access, my use case
> being tchou working on the web assistant.
Let's go for Git access only, then. CGI-- :)
Glad we basically have a solution + tasks sharing designed!
Cheers,
--
intrigeri
