Re: [Tails-dev] underlay for UX or blueprints

Delete this message

Reply to this message
Autor: sajolida
Data:  
A: The Tails public development discussion list
Assumpte: Re: [Tails-dev] underlay for UX or blueprints
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