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 [email protected] 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 > [email protected] 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 _______________________________________________ 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].
