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.
>> 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?
> Once we have that, you can simply use the master branch on that clone.
Ok, make sense and sounds good.
>> Do you think we could also use this infrastructure to review important
>> changes made to the documentation? And have doc writers push in there as
>> well when working on release notes for example?
>
> Adding a staging version of our website would surely open a lot of
> possibilities, I've no idea personally if/how doc writers or other
> teams will want to use them. I suspect the new tool will be quite
> popular, and perhaps we'll even need a bunch of staging websites at
> some point -- in which case, I think we should consider hosting them
> ourselves, instead of on boum.org, for more flexibility (no, I'm *not*
> promising to make this happen any time soon :)
Ok.
>>> Perhaps we should instead have:
>>>
>>> * An entirely different ikiwiki at https://blueprints.tails.b.o/.
>>> I believe it would fulfill the needs you described, without the most
>>> important drawbacks identified above. Also, it may allow us to fully
>>> disable the web interface on our website, which I've been longing
>>> for since years.
>
>> But then we won't be able to link from the blueprints back to our main
>> website using direct ikiwiki links anymore. That can probably be
>> mitigated by an ikiwiki shortcut but we will still have to fix many
>> historical content when doing the migration.
>
> Right. Depending on one's skills, it can be done by asking ikiwiki to
> dump information about backlinks of blueprint{,/*}, and/or with
> regexps, and or semi-manually with git grep's help. Can take a couple
> hours, but not a hard problem in itself.
Sure.
>>> * And, optionally, https://staging.tails.boum.org/ as suggested above,
>>> if you and tchou agree that it's a nicer way to work than
>>> copying'n'pasting large parts of our website into blueprints and
>>> then adapting it to repair links etc., and then do the same the
>>> other way once ready to merge.
>
>> Sure.
>
>> I think that blueprints.tails.b.o would be more urgent for us to publish
>> our ongoing work,
>
> Full ACK. Let's finalize the decision (or an even better one!) at
> tonight's monthly meeting, and then go for it.
>
> 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)?
>> but maybe we can allow ourselves to publish our last
>> stuff on the current system via /blueprint. I'll try to make them as
>> light as I can...
>
> Adding 1-2 MB to .git via blueprint/* now, for stuff that really needs
> versioning, would be totally acceptable to me, as long as there's
> a clear plan, with clearly defined responsibilies, to avoid
> reproducing it N weeks later because of $emergency.
>
> If it's any bigger, please don't: bloating our just-rewritten Git repo
> *now* would make me sad, especially just to remove it soon after.
> If you have large stuff to add *now*, please instead add it on Redmine
> (as was decided a few weeks ago when we had a discussion about a very
> similar topic on -ux@), or to a personal/team tails.git that won't get
> merged into the official one, or somewhere else.
With the 1-2MB limit in mind, I'll find a reasonable solution to be able
to wrap up and report on our UX sprint during next week.
>> 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. I can send them an email.
- Set up a first set of ACL there. I think that's a responsibility
for tails-sysadmin.
- Propose a reasonable configuration for that ikiwiki instance to boum.
This I can do.
- Document and advertise the new toy. This I can do.
- Anything else?
--
sajolida
