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

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

Amir,

* Amir Rohan (amir.rohan@mail.com) wrote:
> 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.

I don't think anyone's really against that idea, except perhaps that we
need to try and avoid letting it be abused.

Of course, someone needs to implement it.

Thanks!

Stephen

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

Amir Rohan wrote:

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

I'm not sure about b3 myself.  It seems too easy to have malicious
patches getting in the hands of unsuspecting testers.  I prefer the more
complicated, safe route that people hand-pick the patches they want to
test.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Stephen Frost <sfrost@snowman.net> wrote:
> Amir Rohan (amir.rohan@mail.com) wrote:

>> 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.
>
> I don't think anyone's really against that idea, except perhaps
> that we need to try and avoid letting it be abused.
>
> Of course, someone needs to implement it.

I apologize if someone already pointed this out and I missed it in
skimming this thread, but Majordomo lets you log in (using the
password it sent you when you subscribed to the list) and (re-)send
an email to your own email address.

(1) Click the link at the bottom of most any email; e.g.:
 To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

(2) Sign in.

(3) Click on "Mailing Lists"

(4) Click the right list.

(5) Click on "Summary" to the right of "Message Archives".

(6) Drill down (through whichever search path you find most
convenient) to the right email, and click the link to it.

(7) Click the "Mail this message" link at the bottom.

Now, perhaps this could be made more convenient, but it's not as
bad as the process described earlier in the thread.  I've done it a
few times, and (having found how to do it) it just takes me a
minute to log in to Majordomo and another minute per email I want
to receive.

That's not to say that new mbox options would be a bad thing.

--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company