Hi,
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.
>>> 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.
>> Once we have that, you can simply use the master branch on that clone.
> Ok, make sense and sounds good.
Cool.
>> 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.
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.
* in any case, we'll need rewrite rules and rewriting links, but that
should be all I think.
>>> 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).
> 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.
> - 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.
- Decide who's gonna get write access to the new toy via the web, and
via Git.
- Have the official repo's master branch merged into staging.t.b.o on
a regular basis somehow, be it manually or automatically.
Cheers,
--
intrigeri
