[cabfpub] GitHub: making rich diffs more reliable

Eric Mill eric at konklone.com
Wed Jul 6 01:12:11 UTC 2016


Can you characterize how often the rich diff times out? I've visited the
URL a few times now over the last hour and had no timeouts. I imagine it's
been cached. If the cache remains invalidated until the next commit, then
it might be an acceptable near-term tradeoff to allow the first visit or
two to timeout, if subsequent visits will work fine.

On Tue, Jul 5, 2016 at 8:19 PM, Jacob Hoffman-Andrews <jsha at letsencrypt.org>
wrote:

> Hi all,
>
> I posted an issue on GitHub:
> https://github.com/cabforum/documents/issues/27, and want to post here as
> well since I know many people do not follow that repository. Interested in
> feedback!
>
> Jacob Hoffman-Andrews said:
>
>> BR.md seems to be large enough that GitHub's rich diff generator takes
>> close to 5 seconds, which is their internal timeout per discussions with
>> GitHub Support. That means viewing the rich diff sometimes produces a
>> timeout, for example at
>> https://github.com/cabforum/documents/pull/24/files.
>> It sounds like GitHub won't change the timeout, and the code is not open
>> source so we don't have the option of optimizing it.
>> I'd like to split up BR.md into multiple files, one per section, and
>> recombine them at build time. That will probably make the rich diff
>> generator finish safely below the timeout.
>> Any objections? @pzb?
>
>
> Peter Bowen said:
>
>> Sounds good to me. However we need to figure out how to handle
>> in-progress ballots; several branches will need re-doing.
>
>
> Ryan Sleevi said:
>
>> My experiences in W3C and IETF suggest that, while understandably
>> well-motivated, such actions generally make the document significantly
>> harder to manage and keep consistent @jsha . Further, I think that's the
>> sort of change that might be better discussed in the Forum at large as part
>> of workflow.
>> It seems like you're making more work for people who want to contribute.
>> Is there a way to avoid that?
>
>
> Jacob Hoffman-Andrews said:
>
>> Good point about making it harder to contribute: People would need to
>> find the correct section to edit. I'm definitely interested in finding
>> alternate approaches that make it possible to continue to read rich diffs
>> (which many Forum members find useful) while also using a single doc. If
>> there's a third-party tool to generate rich diffs, we could run it
>> automatically from Travis and link to it from pull requests.
>> Will cross-post on cabfpub, thanks for the reminder.
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160705/ab1c60ed/attachment-0003.html>


More information about the Public mailing list