intrigeri:
> 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.
Please review and adjust #9174 to your taste and our misunderstandings.
>>> * 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.)
That's what I thought.
>>>>>> 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.
Please review and adjust #9183 to your taste and our misunderstandings.
>>>> 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 :)
I've made this part of #9185 as maybe we can find an ikiwiki solution to
that, otherwise I'll propose some htaccess.
>>> - 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!
\o/
--
sajolida
