This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: Teaching emacs about GCC coding conventions (was Re: [PATCH] tree_code_name wrapper)
- From: "Paulo Matos" <pmatos at broadcom dot com>
- To: "Mike Stump" <mikestump at comcast dot net>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 17 Oct 2013 08:46:15 +0000
- Subject: RE: Teaching emacs about GCC coding conventions (was Re: [PATCH] tree_code_name wrapper)
- Authentication-results: sourceware.org; auth=none
- References: <19EB96622A777C4AB91610E763265F462DC5C7 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <525C1786 dot 5030404 at oracle dot com> <CAFiYyc0b7fU=L28_rkfo4x0zQ-wkf=tr+APMuXd3DVNw5FGAHQ at mail dot gmail dot com> <19EB96622A777C4AB91610E763265F462DC8D3 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <20131015095055 dot GM30970 at tucnak dot zalov dot cz> <19EB96622A777C4AB91610E763265F462DDBA3 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <1381937561 dot 25101 dot 9 dot camel at surprise> <19EB96622A777C4AB91610E763265F462DEFD4 at SJEXCHMB14 dot corp dot ad dot broadcom dot com> <mvmsiw19pnq dot fsf at hawking dot suse dot de> <87li1tw5b6 dot fsf at fleche dot redhat dot com> <3B7B9255-28FE-4501-BE95-A3AC73711BE5 at comcast dot net> <l3mu8a$32f$1 at ger dot gmane dot org> <3402850E-8748-4A03-B639-CB0A8487150D at comcast dot net>
> -----Original Message-----
> From: gcc-patches-owner@gcc.gnu.org [mailto:gcc-patches-owner@gcc.gnu.org] On
> Behalf Of Mike Stump
> Sent: 16 October 2013 23:06
> To: Paulo J.Matos
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Teaching emacs about GCC coding conventions (was Re: [PATCH]
> tree_code_name wrapper)
>
> First, we like to wait and let patches bake on mainline before considering back
> porting, this has no bake time yet in our tree. Second, only patches that impact
> quality enough should be back ported. I tend to think that this one does not
> impact quality enough to worry about. Also, you should develop on trunk, not
> 4_8. Arguably, I would say no. Now, a release manager can always review approve
> it; it should be very, very low risk.
>
Makes sense. Thanks for the clarification.
--
Paulo Matos