On 1/17/15 3:11 PM, sebb wrote: > On 17 January 2015 at 16:29, Mark Fortner <phidia...@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" <gil...@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 <gil...@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 <gil...@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-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
