On Wed, 2 Dec 2015 18:36:30 -0500 Christopher Michael <cpmich...@osg.samsung.com> wrote:
> 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 I'm in agreement here with Mike, Cedric, Raster, and DH. Leave things as they are, if you have a problem, build better filters in your email client, or switch to using phab instead of the mailing list. Some of us like the firehose just like it is. B-) > >> 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 -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ 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
