Suggestion to Stop Cross Posting Discussions

Dear All,

Within the past few months, there have been several discussions that relate to LLVM and its sub-projects (such as the discussions on moving to Git and the Code of Conduct). To ensure that these discussions reach all community members, people have been cross-posting these messages to llvmdev, cfe-dev, and every other -dev you can think of.

This is becoming a headache for me (and possibly other mailing list admins) because replies are often sent to every list, but not all users are subscribed to every list. As a result, we're moderating messages for people because they're subscribed to llvm-dev but not openmp-dev, or they are on cfe-dev but not llvm-dev, etc.

Can we keep these policy discussions on llvm-dev and just expect people to subscribe to llvm-dev if they want to particpate? Alternatively, could we create a new mailing list for these discussions?

I'd rather spend time moderating first-poster posts and discarding SPAM than ensuring that all of you can post to all the lists.

Regards,

John Criswell

From: "John Criswell via llvm-dev" <llvm-dev@lists.llvm.org>
To: llvm-dev@lists.llvm.org
Sent: Tuesday, July 5, 2016 1:51:27 PM
Subject: [llvm-dev] Suggestion to Stop Cross Posting Discussions

Dear All,

Within the past few months, there have been several discussions that
relate to LLVM and its sub-projects (such as the discussions on
moving
to Git and the Code of Conduct). To ensure that these discussions
reach
all community members, people have been cross-posting these messages
to
llvmdev, cfe-dev, and every other -dev you can think of.

This is becoming a headache for me (and possibly other mailing list
admins) because replies are often sent to every list, but not all
users
are subscribed to every list. As a result, we're moderating messages
for people because they're subscribed to llvm-dev but not openmp-dev,
or
they are on cfe-dev but not llvm-dev, etc.

Can we keep these policy discussions on llvm-dev and just expect
people
to subscribe to llvm-dev if they want to particpate? Alternatively,
could we create a new mailing list for these discussions?

I'd rather spend time moderating first-poster posts and discarding
SPAM
than ensuring that all of you can post to all the lists.

Perhaps this is the easiest solution: Make it so that anyone subscribed to any of the -dev lists can post to all of them.

Alternatively, we could have a "community" list to which anyone subscribed to any of the -dev lists is automatically subscribed.

We have a lot of people who are subscribed, for example, to cfe-dev and not to llvm-dev, and I'm not sure that making them received backend-related messages just to catch community-wide discussions is reasonable.

-Hal

+1 to do something, whether that something is to mail only on llvm-dev, or to move those discussions to a 'community' or 'cross-project' list of some sort.

I -am- subscribed to cfe-def and llvm-dev, and as a result, I get most of these messages twice. I also have mail rules to put cfe-dev email in one folder and llvm-dev email in another folder. When both mailing lists are involved, the discussions end up in my llvm-dev folder, but occasionally, someone will only reply on one of the lists. I then get to follow the discussion across folders, and that's no fun.

Hi John,

Apologies for creating this problem, but as you said, not everyone
subscribes to llvm-dev, but for that kind of discussion, we really
should get *everyone's* input.

Moving to a new list (ex. llvm-foundation, llvm-admin, etc) won't get
everyone's attention by a long shot, and managing multiple lists could
increase potential problems to list admins, so the only way out I can
see is to just "expect people interested in the status of LLVM as a
project to subscribe to llvm-dev".

I'm happy with that solution, but maybe we need to change some
documentation in Clang, LLDB, LLD, libraries etc. to make sure that
this is clear to all their users that wouldn't subscribe to llvm-dev
otherwise.

cheers,
--renato

For ISO C++ we long ago created an 'all' list for topics that were organisational and not technically specific to an aspect of the Standard such as Library, or Core, or Extensions, etc.. For the most part I think that since the early 1990s when these lists started, the 'all' reflector/distribution-list has worked really well. I still get all the ISO C++ mailings, and the signal to noise ratio is pretty good in this regard.

For topics such as GIT versus SVN hosting, or code of conduct, and such like (even social events!); the use of a separate list is well justified and means that we can automatically filter and manage our emails in a more useful way.

Hal's 'community' suggestion is essentially the same thing as the ISO C++ 'all' list, and it has worked really well over the years and I'd definitely favour that approach.

  MartinO

+11111

I'm tired of all the stupid/bikeshed OT non-developer discussions that
happen on what imnsho should be a *development ONLY* list.

I don’t have a good suggestion to avoid the bikeshed discussion, but it is not off topic: git/svn is used by every active llvm developer on a day to day basis!

  • Matthias

Is this reply troll bait? How can a discussion to help clean things up
spawn yet a discussion on what should be cleaned up... ummm.. seriously?

git vs svn - Put all //your//(community) religious feelings aside, it's
more of an infrastructure issue than anything. Any half intelligent
developer will make the migration (some begrudgingly) and after some time
forget whatever was the old way.

Things for a developer list:
Code style - which can spawn lots of bikeshed (llvm seems to have something
that works already)
API design - ...
RFC on refactoring or some bigger change
New developer questions - Hand holding for the first few stupid questions..
it just happens

Why people feel so strongly about blue vs green or 9 vs 10 or whatever
other nit picky little thing is beyond me.

I am thankful for all the moderation work on the mailing lists and I think we all agreed that cross posting was a bad idea in this instance.

In each case getting a consistent coding style accepted, designing good APIs and using the best version control tool available all affect me as a developer so it is worth discussing. I can deal with style inconsistencies, or bad APIs it’s often just am annoyance but not a deal breaker. It just slightly affects my productivity. The same is true for version control strategies. There is no reason to dismiss it as “just infrastructure”. I hope we can at least agree to disagree on what is relevant for llvm-dev to keep this thread in control.

  • Matthias

+1 for an “llvm-project” list that everyone involved in any llvm subproject is encouraged to sign up for.

-Chris

Another +1 from me. The llvm-dev and cfe-dev lists are both firehoses and a lot of people on the periphery of the community don’t subscribe to them for this reason (which is not a negative, it’s a sign of a healthy and active project). A lower-traffic list for everyone in the community would be very useful.

David

In Free Pascal Compiler mailing lists ,

http://www.freepascal.org/maillist.var

there is a mailing list for all OFF TOPIC subjects :

http://lists.freepascal.org/mailman/listinfo/fpc-other/

When a subscriber is sent a message to "fpc-other" , there is no fear that
it will be considered "off topic" , because its existence is for "off
topic" messages .

In other lists , when a thread is converted to an "off topic" conversation
, a list administrator is kindly requesting that "please move this
discussion to fpc-other list" .

So much easy .

Mehmet Erol Sanliturk

I'm not against the idea, never have been, but I'd like to know what's
the expected scope and topics of such a list.

In the past, I have proposed to have a separate list to discuss
non-dev topics, pertinent to the whole community (like infrastructure,
tools, etc), and have only met discouragement. That's why I'm
surprised everyone is now in agreement... :slight_smile:

If we do have such a list, would any decision/consensus taken in it
(say, move to GitHub) be taken as final?

For example, say we discuss and agree on that list that we'll move to
GitHub, we'd probably have to announce to all lists, so we're sure
everyone is aware. That announcement can spark discussions like "I
wasn't aware, how can you guys take decisions without asking first",
which will be met with responses like "it was done on this and that
list, you should be there if you care". That can be avoided if we are
clear on what kinds of topics and what kind of decision power each
list has. Cross-posting to each list to let people know *beforehand*
defies the purpose of having such a list in the first place.

Another example is the llvm-commits list. It's generally accepted that
we discuss patches, but not design decisions on it, which should be
done in llvm-dev.

I'm more than happy to see all the non-dev discussions moving
elsewhere, but it has to be *clear* to everyone that decisions as
important as which VCS they'll use next month will be decided there.

cheers,
--renato

+1. I have a similar setup but I only seem to end up with one copy for some reason. It's very confusing to read the end of the conversation on llvm-dev, the beginning on cfe-dev, and finally the middle on lldb-dev.

From: llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] On Behalf Of
Daniel Sanders via llvm-dev
Sent: Wednesday, July 06, 2016 2:11 AM
To: Craig, Ben; llvm-dev@lists.llvm.org
Subject: Re: [llvm-dev] Suggestion to Stop Cross Posting Discussions

+1. I have a similar setup but I only seem to end up with one copy for
some reason. It's very confusing to read the end of the conversation on
llvm-dev, the beginning on cfe-dev, and finally the middle on lldb-dev.

I move *-dev to a single folder just to avoid this.
The sum of all *-dev traffic is not that much.
--paulr

I do that, too. And all *-commit to their own folders, and mark most
of them read by default.

cheers,
--renato

+1 for an “llvm-project” list that everyone involved in any llvm subproject is encouraged to sign up for.

Another +1 from me. The llvm-dev and cfe-dev lists are both firehoses and a lot of people on the periphery of the community don’t subscribe to them for this reason (which is not a negative, it’s a sign of a healthy and active project). A lower-traffic list for everyone in the community would be very useful.

I'm not against the idea, never have been, but I'd like to know what's
the expected scope and topics of such a list.

It seems that the clear scope for the list is topics that apply to all subprojects, including developer meeting, infrastructure issues, policy changes/issues, etc.

If we do have such a list, would any decision/consensus taken in it
(say, move to GitHub) be taken as final?

Yep, that affects everyone.

-Chris

Sorry, I meant to say that issues like “move to github” would be on topic for the list. The addition of a new mailing list certainly doesn’t affect how key decisions in the project are made.

-Chris

Perfect! I'm glad everyone is in agreement. I think it makes sense to
move those things out of the dev list and to make it clear that, if
you care about the project/s, you should be on that list. :slight_smile:

cheers,
--renato

FWIW, I’m not in agreement.

I think having yet another mailing list is a dramatically worse solution than simply fixing our mailing list system to allow subscribers to any of the lists post to all of the lists.

I’ve used a wide variety of email clients over the years and they’ve all been capable of ensuring I only get one copy of emails sent to multiple mailing lists.

That said, if everyone is both adamant that we cannot simply solve the technological problem here and we must do something, then I’ll tolerate yet another mailing list.

I suspect it will mostly result in an increase in the amount of email we all receive because of the number of “heads up” and “go look at this other list” emails that become required due to people not realizing they need to subscribe to this extra list. =[

-Chandler