intrigeri:
> sajolida wrote (05 Apr 2015 19:46:22 GMT) :
>> intrigeri:
>>> sajolida wrote (02 Apr 2015 19:39:16 GMT) :
>>>> intrigeri:
>>>>> Web prototypes should probably live in branches forked off master,
>>>>> hosted in a non-official Git repo (to avoid .git growing too much)
>>>>> until they're ready to be squashed and merged, no?
>>>
>>>> I'm not sure to understand what you mean by "squashed". Is that a
>>>> special Git operation?
>>>
>>> It's not a Git command per-se. It means rewriting the history of
>>> a branch before merging it, e.g. to get rid of testing of hypothesis
>>> that lead nowhere, of debugging stuff added then removed, recompress
>>> images properly, and sometimes even merging all its remaining new
>>> commits together, depending on the Git workflow.
>>>
>>> I expect that such web prototypes branches may inject largish files,
>>> replace and modify them along the way, which would bloat the repo
>>> a lot, for no good reason, if they're not squashed before merging.
>
>> So this it something that I definitely don't know how to do and would
>> need explanation or training to perform.
>
> That's actually:
>
> git rebase -i origin/$BASE_BRANCH
>
> with BASE_BRANCH = the branch into which the current topic branch is
> meant to be merged.
Ok, this should do in the documentation about staging.tails.boum.org.
I'll give it a try.
>>>> People working on the "staging" website would have to coordinate to deal
>>>> with whatever is built by this ikiwiki. Would you recommend having a
>>>> dedicated canonical branch, say "staging" or "website" to do that?
>>>
>>> I think it needs to be built from a dedicated clone of our repo, not
>>> merely from a branch living in our official repo, so that we can 1.
>>> deal with different ACLs more easily; 2. squash branches before
>>> merging, or even cherry-pick stuff, or rewrite the history of the
>>> staging repo whenever needed.
>
>> So that would be a clone that is not automatically synchronized from our
>> main repo but only manually by people with push rights?
>
> We can have our main repo's master branch merged automatically into
> that other repo e.g. daily, but then someone will have to receive the
> notifications about merge conflicts, and act upon it. As you prefer.
I think I prefer to merge the main repo into staging manually when
needed. Otherwise stuff might break on staging by automatic pushes.
>>> 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:
>
> To rewrite the repository to look as if foodir/ had been its project root,
> and discard all other history:
>
> git filter-branch --subdirectory-filter foodir -- --all
>
> Of course, we're not going to rewrite our main repo's history in this
> process, though. A simple `git rm -r wiki/src/blueprint' will do there.
I'll try to do this myself then.
> 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)?
> * 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?
>>>> 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.
>> 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...
>> - Set up a first set of ACL there. I think that's a responsibility
>> for tails-sysadmin.
>
> Right, once we have the list of users, SSH pubkeys, and desired access
> level. Please check with us before asking their SSH pubkey to lots of
> people, as we already have quite a few keys installed.
>
>> - Propose a reasonable configuration for that ikiwiki instance to boum.
>> This I can do.
>
> Yay.
>
>> - Document and advertise the new toy. This I can do.
>
> Yay.
>
>> - Anything else?
>
> I would add:
>
> - 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.
> - 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. Do you think we need web
access to modify that website? For which use cases?
> - Have the official repo's master branch merged into staging.t.b.o on
> a regular basis somehow, be it manually or automatically.
I'd rather do that manually from time to time as people pushing stuff
there feel the need to do so.
--
sajolida
