Hi,
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.
> 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? 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.)
> - 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.
> - Reduce the impact of our work on the size of the main repo while
> not refraining us to share as many documents as we like while
> working on a project. Those can be removed from the working tree
> and website once the project is over.
:)
> So I thought about having a second underlay for our blueprint section
> with more people allowed push rights. I think that would solve the needs
> expressed above.
... almost.
> 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.
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.
> Does this look like a good idea?
Given the above, I don't think so.
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.
* 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.
Cheers,
--
intrigeri
