intrigeri:
> sajolida wrote (27 Mar 2015 14:16:15 GMT) :
>> I'm sending a copy to tails-ux to let them know that this discussion is
>> going on but I think that it belongs to tails-dev.
>
> Dropping -ux@ from Cc, then.
Yeah.
>> Our needs are:
>
>> - Sharing many files that are not plain text. We work a lot with
>> office documents of all kinds (Calc, Draw, Impress). We try to keep
>> them Git friendly by using flat XML but even that can quickly fill
>> megabytes. We will start working on web prototypes (development
>> HTML, images, CSS, JavaScript, etc.).
>
> 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?
> The way I see it,
> it's easier to work on our website by directly modifying the affected
> parts of it, rather than by duplicating the parts you need into
> blueprint/. (But more on that below.)
You're right. I had in mind the case of the web assistant which can be
conceived, to a great extent, as a *addition* to the website, but
indeed, when we will want to work on *modifications* to the website it
makes more sense to work on the affected parts directly.
>> - Keeping historical versions of documents available for comparison
>> without having to go through Git history (eg. available on the
>> website).
>
> OK. Note that ikiwiki does *not* support linking to a different VCS
> repo for pages generated thanks to its underlay plugin. The underlay
> plugin is essentially meant for stuff that's not under
> revision control.
>
>> - Allow more people (eg. tchou) to push web prototypes that can be
>> built by ikiwiki and viewed online.
>
> Ah, OK, that's the part I missed above. This part could be solved by
> having a https://staging.tails.boum.org/ ikiwiki, built from a fork of
> our official repo that more people could have write access to.
That would be perfect. I didn't mean to propose that at first because it
seemed more work than underlay idea. But I think that it would be better
actually.
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?
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?
>> The downsides I could identify so far are:
>
>> - Extra sysadmin and infrastructure complexity.
>> - Additional Git work when moving stuff from blueprint to production
>> (eg. design documents).
>> - Additional Git work when setting up a working environment for new
>> contributors.
>> - Possible security issues in case the underlay spills stuff out on
>> the production website. Could this happen?
>
> ikiwiki has a pretty good security track record, but I wouldn't bet on
> the fact that it is 100% free of security issues, so it's safe to
> assume that having write access to that underlay also may give write
> access to the website somehow.
And locking down the edit on our website looks like a good idea for the
same reason, then.
> Other than what you've already mentioned, the main concern I have with
> this idea is that it prevents editing blueprints via the web interface
> (unless I missed something about how the underlay plugin works).
> That's a blocker IMO.
Yes, I didn't think about that and that's definitely a blocker.
> 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.
> * 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, 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...
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.
--
sajolida
