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 [email protected] 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 >>>>> [email protected] 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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
