The road to v0.10.1 or v0.11

2014-01-17 Thread Jason A. Donenfeld
Hi guys, Here's what I'm thinking about for the next release (or releases?): + FastCGI support + More malloc()/free() cleanups + git-blame support + git-grep support + HTML5 compliance + More filters everywhere + Expanded test suite + Line number anchors highlighting the current line +

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread John Keeping
On Fri, Jan 17, 2014 at 05:12:26PM +0100, Jason A. Donenfeld wrote: Here's what I'm thinking about for the next release (or releases?): + FastCGI support I really can't see this being sensible without moving to libgit2. As long as we stick with libgit.a then we need to fork for each request

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread Jason A. Donenfeld
On Fri, Jan 17, 2014 at 5:28 PM, John Keeping j...@keeping.me.uk wrote: I really can't see this being sensible without moving to libgit2. As long as we stick with libgit.a then we need to fork for each request so I'm not sure there's much benefit to supporting FastCGI without moving to

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread John Keeping
On Fri, Jan 17, 2014 at 06:09:15PM +0100, Jason A. Donenfeld wrote: On Fri, Jan 17, 2014 at 5:38 PM, Jason A. Donenfeld ja...@zx2c4.com wrote: On Fri, Jan 17, 2014 at 5:28 PM, John Keeping j...@keeping.me.uk wrote: I really can't see this being sensible without moving to libgit2. As long

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread Jason A. Donenfeld
On Fri, Jan 17, 2014 at 5:53 PM, John Keeping j...@keeping.me.uk wrote: But scan for repos is caught by the cache most of the time, and presumably even if we run persistently we still need to do that periodically (or use inotify); or do we just rely on the process being replaced when the set

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread Konstantin Ryabitsev
On 17/01/14 01:22 PM, Jason A. Donenfeld wrote: But scan for repos is caught by the cache most of the time, and presumably even if we run persistently we still need to do that periodically (or use inotify); or do we just rely on the process being replaced when the set of repositories

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread John Keeping
On Fri, Jan 17, 2014 at 02:29:19PM -0500, Konstantin Ryabitsev wrote: On 17/01/14 01:22 PM, Jason A. Donenfeld wrote: But scan for repos is caught by the cache most of the time, and presumably even if we run persistently we still need to do that periodically (or use inotify); or do we

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread Jason A. Donenfeld
On Fri, Jan 17, 2014 at 8:29 PM, Konstantin Ryabitsev mri...@kernel.org wrote: The process that updates the repositories may not have permissions to send SIGUSR1 to the fcgid process -- either because they are running as different users or because there are SELinux policies preventing it.

Re: The road to v0.10.1 or v0.11

2014-01-17 Thread Jason A. Donenfeld
On Fri, Jan 17, 2014 at 8:32 PM, John Keeping j...@keeping.me.uk wrote: Presumably you are OK with this having the same latency as the existing cache mechanism. The simplest implementation will probably be to keep the existing cache valid? check and re-scan repositories as we currently do.