On Sun, Oct 19, 2014 at 6:53 PM, Sawyer X <xsaw...@gmail.com> wrote:
> Agreed. However, your sentence seems to me as if it's implying Perl> maintenance is one layer of centralized work where you either have all of> it or none. However, as far as I understand, it's as decentralized as any> other project, where some people know some areas more than others.>>> This means some people care about breakage in their subsystems, others in> other subsystems. Some people might have an overall view in which they want> to know of all subsystems breakage.>> This is where a split view is ideal. Unless every single person on the> list needs to know about every single subsystem that breaks, having a list> with everything is simply unnecessary.>
Problem is, everyone is interested in a different subset, and I don't
believe it can generally be split cleanly in a way that a computer can
preselect it easily.
> But does everyone need to view every single ticket discussion? This is> counter to how these systems are designed.>> A ticket system dictates that you view the conversation if:> * You opened the ticket.> * You were assigned the ticket.> * You were added as a watcher.> * You registered yourself to get updated.>> Then updates go to you personally.>> Anyone can take an update that came from an email, forward it to the list,> and discuss it there to get everyone's comment on it. Question is, does> every single ticket require the attention of everyone?>> Instead of providing an avenue for people to decidedly be part of a> discussion, everyone is automatically added to it and then have to filter> it out.>
It doesn't. This is entirely optional, it just happens to be that the
default is on, and that's a sensible default IMHO: If it was off, hardly
anyone would see them.
> This wasn't about "this specific thing is a burden" but "the overall> approach of sending *every single thing* to p5p is creating a very large> stream that makes it harder to discern emails you want to read than ones> you don't". I am doubtful that everyone on the list reads every mail.>
I'm doubtful that *anyone* on the list reads every email.
As Kent noted, it's easier to put it together than pull it apart.
>
Which is exactly why it's a single list, there is no easy way to pull it
apart in a *useful* way.
> I think it's actually easier to define it as:> * Committers get broken build emails.> * Person who wrote the patch which broke the build get the emails.> * Anyone who wants to view broken builds registers freely.>> A broken build email can be forwarded to the list to create a discussion.> Alternatively, a ticket can be opened from it which will hold its> discussion there. Anyone can join as "watchers" there to receive updates on> the entire discussion even if they are not part of it.>
I suspect we can use mail-threading more sensibly here. That could decrease
the perception of number of emails involved.
> That makes sense.>> Discussions can still happen using bugs, patches, smoke reports, or any> other email as a catalyst. They just need to be forwarded and a thread> ensues. Is every ticket or email starting its own thread? No. Only some.> Those can be done independently.>> It doesn't make sense that every single summary, bug, patch, smoke report,> and more, will be sent to the entire list because *some* might be used to> start a discussion thread. Not withstanding, the queue system has an entire> mechanism to hold the discussion there. You can independently update it via> email instead of the ticket system, if you prefer, and you can register for> the feed to it to get updates.>
And who would I be to decide to whom something would be interesting?
What I suggested (note "suggested", since it's clear it isn't desired) does
> not suppress openness and transparency. More than anything, the idea was to> make it easier for new contributors to join the list and follow it without> being overwhelmed with traffic.>> I reckon the reason this is separated in so many other mailing lists is> because it makes it *easier* to maintain. I see this isn't the case here.>
I think you're arguing for splitting on source, while trying to achieve
splitting on target audience. This will not work.
Leon