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 _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
