On 09/30/2015 08:47 PM, Stefan Kaltenbrunner wrote:
> On 09/30/2015 09:33 AM, Amir Rohan wrote:
>> On 09/30/2015 09:53 AM, Stefan Kaltenbrunner wrote:
>>
>> Did you notice that the file contains multiple patches?
>
> no missed that - makes reading it without applying not exactly easier :)
>
That's a culture thing, my bad. it's git-format-patch's default
behaviour, meant for use in conjunction with git-am to keep
git history.
postgres does things differently. I read the wiki and will follow
the native way in the future.
>>
>> This reads like a rejection for this whole "generate from db" approach.
>> And I can't help implement the static solution, as that's cron/root
>> stuff.
>
> no - that was not what I was trying to say - my proposal was to add the
> per-thread mbox generation (and maybe even the monthly ones longer term)
> as an option <... to loader/load_message.py ...>
What you are saying is that we shouldn't generate the thread mbox in
the web server per-request, because the perf implication are an
unknown, which amounts to the same thing.
That's ok, we all agree that static files are a better way to do this.
Let's recap:
a1. Original problem: "if you're not subscribed it's difficult to join
ongoing threads."
a2. Current solution: Participants should download the "raw" message and
import it into their email client.
I added a blurb to the wiki about this. What about the "Mail me this
message" proposed earlier? I'd be glad to help make that happen.
Independent of that, the discussion turned up:
b1. a wishist item for providing per-thread mboxes.
b2. a wishist item for providing per-commitfest mboxes.
b3. Possibly, a wishist item for a "commitfest TIP" branch/patchset.
to ease testing.
At this point, I'm leaving that for someone else to implement.
Cheers,
Amir