intrigeri: > sajolida wrote (05 Apr 2015 19:46:22 GMT) : >> 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. > > That's actually: > > git rebase -i origin/$BASE_BRANCH > > with BASE_BRANCH = the branch into which the current topic branch is > meant to be merged.
Ok, this should do in the documentation about staging.tails.boum.org. I'll give it a try. >>>> 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? > > We can have our main repo's master branch merged automatically into > that other repo e.g. daily, but then someone will have to receive the > notifications about merge conflicts, and act upon it. As you prefer. I think I prefer to merge the main repo into staging manually when needed. Otherwise stuff might break on staging by automatic pushes. >>> 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)? > > It does involve creating a new Git repo that 1. only contains the > blueprint directorie's content, and 2. inherits the current Git repo's > history for that content, and nothing else. > > git-filter-branch(1) should get you started: > > To rewrite the repository to look as if foodir/ had been its project > root, > and discard all other history: > > git filter-branch --subdirectory-filter foodir -- --all > > Of course, we're not going to rewrite our main repo's history in this > process, though. A simple `git rm -r wiki/src/blueprint' will do there. I'll try to do this myself then. > Other than that: > > * if we want to manage the ACLs ourselves for that new blueprints > repo: it requires a master copy of that new repo, somewhere, that's > able to push to boum.org whenever it's updated; > * otherwise, it can be setup just like our main repo at b.o. I think this is getting quite beyond what I'm willing to learn a fits better the knowledge and role of tails-sysadmins. What about having tails-sysadmins do the Git infrastructure and ACLS and me do the Git content and ikiwiki configuration (and learn new Git powers along the way)? > * in any case, we'll need rewrite rules and rewriting links, but that > should be all I think. Rewrite rules to point https://tails.boum.org/blueprint to https://blueprint.tails.boum.org? Anything else? >>>> 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. > > Well, this only works if you find a way to have a hook in that repo > that pushes to boum.org whenever it's updated. To the best of my > knowledge, the Git hosting infrastructure immerda provides us is not > ready to do that yet, but we can ask them if it's easy for them to set > it up. Please Cc -sysadmins@ when you'll do that. > > Otherwise, we can surely host the master copy of that staging repo on > lizard somewhere (this will require to set up some stuff, as right now > our only Git hosting infra there isn't for this kind of things, so > we'll need to move it or to set up another one). The second option sounds easier, but I'll let tails-sysadmins decide. >> I can send them an email. > > Uh, no: we (-sysadmins@) are managing our repos and ACLs at immerda > ourselves => no need to bother immerda folks with repo > creation requests. Same here, does that sound ok to let tails-sysadmins do the Git infrastructure? It will probably be less work for both of parties in the end... >> - Set up a first set of ACL there. I think that's a responsibility >> for tails-sysadmin. > > Right, once we have the list of users, SSH pubkeys, and desired access > level. Please check with us before asking their SSH pubkey to lots of > people, as we already have quite a few keys installed. > >> - Propose a reasonable configuration for that ikiwiki instance to boum. >> This I can do. > > Yay. > >> - Document and advertise the new toy. This I can do. > > Yay. > >> - Anything else? > > I would add: > > - Add a banner to staging.t.b.o that makes it clear that its content > MUST NOT be trusted. E.g. by replacing the logo, or something. Ok, I'll take that but this will imply additional Git complexity I guess. Another option would be to put that website behind a dummy .htaccess password documented along with the new toy in our contributors documentation. > - Decide who's gonna get write access to the new toy via the web, and > via Git. Via 'web' and via 'Git'? I only thought about Git access, my use case being tchou working on the web assistant. Do you think we need web access to modify that website? For which use cases? > - Have the official repo's master branch merged into staging.t.b.o on > a regular basis somehow, be it manually or automatically. I'd rather do that manually from time to time as people pushing stuff there feel the need to do so. -- 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].
