On 12/02/2015 06:32 PM, Carsten Haitzler wrote: > On Wed, 2 Dec 2015 10:42:43 -0800 Cedric BAIL <cedric.b...@free.fr> said: > >> Hello, >> >> I am just going to say that Mike proposal is the one that make most >> sense and will be the most efficient for everyone without forever >> discussing every little detail. We could even go as far as >> decomissionning our current mailing list. > > or just leave it as-is and unsubscribe if you dont want it, or use filters > locally or... use phab. > > i don't see any value in centrally imposing some policy on everyone where > everyone will end up disagreeing on what they want to watch or not. > Yes. Everyone is going to have their own preference
> use the git-commits firehose that is "everything" > > btw - our git commits mailing lists runs on e.org - not on sf.net infra. so sf > is irrelevant here. > > i don't see the point of decommissioning the list - it's useful and works and > takes effort to decommission. as above. use phab or local filters and filter > as > you like. > +2. I'd have to agree here. Why change something that has worked for years ? I am sure just about every email client has filters by now...set some up ;) dh >> Cedric >> >> On Wed, Dec 2, 2015 at 8:56 AM, Mike Blumenkrantz >> <michael.blumenkra...@gmail.com> wrote: >>> My preference would be to do away with the commit mailing list entirely. >>> It's easy to set a follow rule on phab for projects that you're interested >>> in, and this has the added benefit of reducing our reliance on the >>> failure-prone sourceforge infrastructure. Moreover, it would avoid future >>> arguments over whether a project is important enough to be on the list. >>> >>> As an example of how easy this is: >>> 1) go to https://phab.enlightenment.org/herald/new/ (accessed through the >>> applications link on the left panel -> herald -> create new rule) >>> 2) click commit (top option) >>> 3) click continue >>> 4) click personal (top option) >>> 5) click continue >>> 6) make up a rule name in the top field >>> 7) change condition to "Repository" and "is any of" >>> 8) click magnifying glass on right to add whatever projects you're >>> interested in >>> 9) change action to "send me an email" >>> 10) click save rule >>> >>> You now have a rule which notifies you about your repositories of interest >>> and can be changed at any time. To only receive mails for "master" branch >>> commits, simply add another condition with "branches" "contains" "master". >>> >>> Furthermore, mails from phab will contain links to the commit audit on >>> phab, a useful tool which we do not make enough use of. Not only does it >>> allow inline reviewing of commits along with direct ticket/diff >>> referencing, it also will directly mail the associated author of the >>> audited commit--something which the commit list cannot automatically do. >>> >>> Lastly, using the audit method allows developers to set more herald rules >>> to automatically add themselves to audited commits, meaning that any time a >>> review is started they will receive a mail, similar to the current review >>> workflow. Unlike the current workflow, however, a developer can also create >>> specialized rules to automatically begin an audit session (with >>> notification) when certain criteria are met, eg. specific files which the >>> developer maintains are modified by someone else. >>> To test this, simply follow the above steps but use "add me as an auditor" >>> instead of/in addition to "send me an email". This can be further >>> restricted by adding another condition to the rule which specifies "change >>> conditions", allowing pruning based on commit size, content, and specific >>> files. >>> >>> Sure, this is a little more work than clicking subscribe, then waiting for >>> the confirmation mail, then clicking the confirm link, then clicking the >>> confirm button after maybe thinking of a throwaway password, but I think >>> the benefits are worthwhile enough to make this a project standard. >>> >>> On Wed, Dec 2, 2015 at 9:55 AM Stephen Houston <smhousto...@gmail.com> >>> wrote: >>> >>>> I think leaving it like it is, or number two, would be the right option. >>>> The commit ml is the easiest way for me to quickly get an idea of what is >>>> going on across git, not just the core projects. "Oh look, edi added >>>> faster syntax highlighting... Sweet!". >>>> >>>> On Wed, Dec 2, 2015 at 8:39 AM, Tom Hacohen <t...@osg.samsung.com> wrote: >>>> >>>>> Hey, >>>>> >>>>> I'm sending this email to raise an issue that has been annoying me for >>>>> the last few months, but especially in the last couple of weeks. >>>>> >>>>> As it stands the Git ML is cluttered and it's very annoying for me to >>>>> review commits that are of relevance to me. The problem, is that in the >>>>> Git ML we send emails for all of the commits in all of the repos in >>>>> git.e.org. This includes some more niche projects. This means I get >>>>> hundreds of commits a week that I don't care about, and this number will >>>>> only grow once more projects are added. To make matters even worse, >>>>> those projects don't follow the EFL commit guidelines and have authors >>>>> like "Gerrit <xxxx>" or just merge commits. >>>>> >>>>> I could solve it locally, by filtering out the main offenders according >>>>> to the repository name (we pass it in the header), though I suspect I'm >>>>> one of many to be annoyed by it (I already know I'm not the only one). >>>>> >>>>> I think it's time to tackle that. I came out with two alternatives: >>>>> 1. Only send commit emails for "core" efl projects. >>>>> 2. Split the git ML to two MLs, "core" and "extra". >>>>> >>>>> By core projects I mean: e, efl (+ loaders), elm and terminology. Maybe >>>>> also any other project that is developed by more than a few efl >>>>> developers and follows our guidelines. >>>>> >>>>> In addition, I recommend all the projects to follow the E commit >>>>> guidelines to make the commit history more manageable. This will both >>>>> lessen this annoyance and improve the commit history of the relevant >>>>> projects. >>>>> >>>>> Please let me know what you think. >>>>> >>>>> -- >>>>> Tom. >>>>> >>>>> ------------------------------------------------------------------------------ Go from Idea to Many App Stores Faster with Intel(R) XDK Give your users amazing mobile app experiences with Intel(R) XDK. Use one codebase in this all-in-one HTML5 development environment. Design, debug & build mobile apps & 2D/3D high-impact games for multiple OSs. http://pubads.g.doubleclick.net/gampad/clk?id=254741911&iu=/4140 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
