On 17 January 2015 at 22:18, Phil Steitz <phil.ste...@gmail.com> wrote: > 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.
Select the issues that you want to change There should be a Tools menu item top right which includes Bulk change. > 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? Dunno. Adjusting the way that Maven does anything is not generally very easy as it is often buried in multiple layers of plugins. It may be that svnmucc could be used; that tends to be a lot quieter than svn commit. We do now have a notifications list which is intended for build-bot commits. It would make sense for commits to the live site to go there as well. Those commits did not exist before svnpubsub, and they are not critical. I assume that is something Infra can do quite easily. The main commits list would then remain for code commits and source document updates. > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
