commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
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 <phidias51@gmail.com> 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?

Phil
>
>> Mark
>> On Jan 17, 2015 8:11 AM, "Gilles" <gilles@harfang.homelinux.org> 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 <gilles@harfang.homelinux.org>
>>>>> 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
go
>>>>>>> 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
web
>>>>>>>> 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
list
>>>>>>>> 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
very
>>>>>>>> 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
someone
>>>>>>>> reviews
>>>>>>>> and commits my patch <https://issues.apache.org/jira/browse/BCEL-186>
>>>>>>>> (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 <gilles@harfang.homelinux.org
>>>>>>>> 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
mine.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    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
and
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>>> While this might contribute to ML traffic, it doesn't
necessarily
>>>>>>>>>> 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: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message