Hi,
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.
>>> - 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.
OK.
> 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.
Once we have that, you can simply use the master branch on that clone.
> 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 :)
>> 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.
>> * 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 root@??? has set it up, or do you expect -sysadmins@ to
do so? If the latter, please specify your ideal and worst
case deadlines.
> 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.
> 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
root@??? can take care of)?
Cheers,
--
intrigeri
