Re: No easy way to join discussion in existing thread when not subscribed

On 10/01/2015 07:59 AM, Amir Rohan wrote:
> 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.

no problem ;)

> 
>>>
>>> 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.

yeah

> 
> 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.

yeah - as Stephen said upthread I think that would be a very useful
feature...

> 
> 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.

I think b1 would be doable with your current approach and some careful
management but b2 seems outright out for generating on-the-fly in the
webserver, som maybe we need to look into a way of building them either
using a script that runs from cron or during the data-import into the
archives.


Stefan