commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [ALL] Too much traffic on the "dev" ML
Date Sat, 17 Jan 2015 22:18:28 GMT
On 1/17/15 3:11 PM, sebb wrote:
> On 17 January 2015 at 16:29, Mark Fortner <> wrote:
>> Bulk JIRA changes prior to a release tend to swamp the list. Perhaps it
>> would be better to close the issue as the work is done.
> The convention is to resolve the issue when the work is done and close
> the issues after the release.
> When bulk closing lots of issues, it's easy enough to suppress the email.

How, exactly?  I used to be able to do this, but I don't seem to
have the karma now or maybe I just forgot how.
Sorry for the hijack; but I agree this is noise that would be nice
to suppress.

The website commits are another morass.  I find that when I do it
"manually" - command line checkin as opposed to counting on the
maven site thingy - there is often much less noise.  Is there a way
to do that "silently" as well?

>> Mark
>> On Jan 17, 2015 8:11 AM, "Gilles" <> wrote:
>>> On Sat, 17 Jan 2015 16:36:55 +0100, Gilles wrote:
>>>> On Sat, 17 Jan 2015 15:00:34 +0000, sebb wrote:
>>>>> On 17 January 2015 at 14:23, Gilles <>
>>>>> wrote:
>>>>>> On Fri, 16 Jan 2015 16:00:45 -0600, Ole Ersoy wrote:
>>>>>>> I agree - we're hung up on a clown from the 90s.  It's so much
>>>>>>> simpler click watch on github and get notifications.  Also
>>>>>>> stackoverflow has a much broader Java community and having traffic
>>>>>>> through it could benefit this community.
>>>>>> I'm afraid that the main problem is not the tool.
>>>>>> Step 1: an issue is felt as a problem by some people (from the
>>>>>>         community or might-be contributors)
>>>>>> Step 2: people (from the community) who don't feel the problem
>>>>>>         try to demonstrate that there isn't a problem, thus
>>>>>>         dismissing the (argumented) feeling of others
>>>>>> This can destroy a community, or at least prevent its expansion.
>>>>>> [And the "Commons" project's (with the word "project" as in "an
>>>>>> Apache project") community certainly does not benefit from a
>>>>>> pool of contributors commensurate with its purported goal and
>>>>>> user base.]
>>>>>> On the practical side, I'm not (yet) against having a single "dev"
>>>>>> list: discussions about design are usually interesting even if
>>>>>> applied to another project's codebase (with the the word "project"
>>>>>> as in "programming project").
>>>>>> But lately, the flood of automatic notifications (commits and CI)
>>>>>> has drowned the useful discussions.
>>>>> commits are already sent to a separate list.
>>>> The more stringent problem is getting _all_ the projects' commits!
>>>>  I have just recently changed Continuum and the Jenkins Math job to use
>>>>> commits as well.
>>>>> What other automatic notifications are still affecting the dev list?
>>>>> Maybe they can be redirected elsewhere.
>>>>>  For people who do not contribute to a project (i.e. neither
>>>>>> providing code nor checking it), a commit diff is just noise
>>>>>> because they lack context (not being aquainted with the codebase).
>>>>> Indeed, which is why it is good that they are sent to a different
>>>>> mailing list.
>>>> Good, yes. Enough, no.
>>>>>  The Commons community's implied answer to the stated fact is
>>>>>> that people who feel that way should change their perception of
>>>>>> reality, or go away.
>>>>>> The respectful answer would be to solve the problem with the
>>>>>> readily available technology of the 1990s: separate MLs for
>>>>>> each project's _notifications_ (with the word "project" as in
>>>>>> "programming project").
>>>>> As already previously noted, the PMC are responsible for oversight and
>>>>> so must see all the commits.
>>>> No, they _must_ not. Because you cannot enforce the "must". [As noted
>>>> by several people, they use filters...]
>>>> People do what they want, and what they can.
>>> In addition to segregated commit MLs, I think that one _digest_ message
>>> every day, summarizing all the commits (of all projects) of the day might
>>> help a lot: policy would be safe.
>>> Gilles
>>>  The number of people voting for any one release of a given
>>>> (programming) project is proof enough that not everybody checks
>>>> everything.
>>>> Even those who vote "should" review, but not necessarily do so
>>>> extensively (if, for example, what is more important for them is
>>>> that the release happens).
>>>> [To avoid instant flaming, I immediately stress that it is _not_
>>>> to say that Apache should publish unreviewed code...]
>>>>  Would it really make enough of a difference to non-PMC members to be
>>>>> worth the additional work (ours and Infra) of setting up individual
>>>>> commit lists?
>>>> The result would be worth it; oh, yes!
>>>> Unfortunately, I cannot imagine how much work this is going to be,
>>>> as I never delved into commit trigger scripts.
>>>> Gilles
>>>>>> Regards,
>>>>>> Gilles
>>>>>>  Ole
>>>>>>> On 01/16/2015 10:21 AM, Ben McCann wrote:
>>>>>>>> I find the whole I idea of a mailing list very 1990s. I'd
much prefer
>>>>>>>> something like Google Groups where I can set my notification
>>>>>>>> preferences
>>>>>>>> easily to send me updates only on certain threads such as
threads I've
>>>>>>>> started, which has a nice easily browsable and searchable
>>>>>>>> interface,
>>>>>>>> and where I do not have to go through a signup process for
each new
>>>>>>>> group/list I want to post to. I feel many of the problems
folks are
>>>>>>>> talking
>>>>>>>> about here are caused by using a frustrating technology.
E.g. it was
>>>>>>>> mentioned that if we split mailing lists that joining every
>>>>>>>> would be
>>>>>>>> very painful. Perhaps that's because the process of joining
just a
>>>>>>>> single
>>>>>>>> list is too difficult. Having to setup filters is also not
>>>>>>>> user-friendly. How do I make a filter that says only put
threads on
>>>>>>>> which
>>>>>>>> I've participated in my inbox? There's probably a way, but
it's not as
>>>>>>>> obvious as clicking a single button. And even with filters
I still
>>>>>>>> don't
>>>>>>>> want most of this garbage coming to my mail account anyway
because it
>>>>>>>> pollutes my search results when I'm looking for something
I do care
>>>>>>>> about.
>>>>>>>> I signed up for the dev list just so that I could ask that
>>>>>>>> reviews
>>>>>>>> and commits my patch <>
>>>>>>>> (which
>>>>>>>> I still need help with), but I really have no interest in
getting any
>>>>>>>> commons mail beyond that. I've never participated in any
of these
>>>>>>>> other
>>>>>>>> projects and flooding my inbox is just frustrating and isn't
going to
>>>>>>>> cause
>>>>>>>> me to start. The web interface for mailing list archives
is truly
>>>>>>>> horrendous.
>>>>>>>> On Fri, Jan 16, 2015 at 8:16 AM, Gilles <
>>>>>>>> wrote:
>>>>>>>>  On Fri, 16 Jan 2015 16:52:36 +0100, Torsten Curdt wrote:
>>>>>>>>>  Was it mentioned that anybody would be forbidden to
subscribe to any
>>>>>>>>>>> ML they see fit?
>>>>>>>>>>>  You missed my point - but never mind.
>>>>>>>>>>  What was it?
>>>>>>>>> Judging from your comments below, you completely missed
>>>>>>>>>    That comparison is pretty flawed as those projects
are not tiny
>>>>>>>>>>>> components.
>>>>>>>>>>> I'm not talking about the size of components,
but the size of the
>>>>>>>>>>> ML traffic.
>>>>>>>>>>>  So just because a component/project has a lot
of ML traffic you
>>>>>>>>>> want
>>>>>>>>>> to make it TLP?
>>>>>>>>>>  I never said that.
>>>>>>>>> I'm only complaining about ML traffic.
>>>>>>>>>   Usually it should be about having enough active committers
>>>>>>>>> users.
>>>>>>>>>> While this might contribute to ML traffic, it doesn't
>>>>>>>>>> mean the same.
>>>>>>>>>>   I've never a great fan of umbrellas but the components
are so
>>>>>>>>>> small -
>>>>>>>>>>>> I don't see another option. The thought of
components to go TLP
>>>>>>>>>>>> feels
>>>>>>>>>>>> just plain silly to me. Hence it would be
great to work together
>>>>>>>>>>>> as a
>>>>>>>>>>>> community that takes care of those components.
>>>>>>>>>>> The idea of "Commons Math" being a component
is silly, but we can
>>>>>>>>>>> accept
>>>>>>>>>>> silly things that result from history (and consider
the practical
>>>>>>>>>>> advantages, as I noted elsewhere).
>>>>>>>>>>>  Well, by the current definition it's not an
Apache project. Call
>>>>>>>>>> it
>>>>>>>>>> sub-project if you like - I don't care.
>>>>>>>>>>  What I'm calling "project" is a _programming_ project;
that's the
>>>>>>>>> word
>>>>>>>>> I'm used to; do you have another one?
>>>>>>>>> Every component is a separate programming project, it's
a simple
>>>>>>>>> fact.
>>>>>>>>>   At some stage we decided to call it component. After
all I see it
>>>>>>>>> as
>>>>>>>>>> a library.
>>>>>>>>>> Do you think it's more and needs to be raised to
the level to full
>>>>>>>>>> blown project like hadoop or httpd?
>>>>>>>>>> Not sure it Math holds that comparison but you are
welcome to
>>>>>>>>>> convince
>>>>>>>>>> us.
>>>>>>>>>>  I think that this has nothing to do with this thread.
>>>>>>>>>    If it depends on the name of the list, I guess that
the "sense of
>>>>>>>>>>> community" is not very developed...
>>>>>>>>>>>  And that's what I call an oversimplification.
>>>>>>>>>>  You brought that up (one community == one list).
Or another missed
>>>>>>>>> point?
>>>>>>>>> Gilles
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message