From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dario Faggioli Subject: Re: [PATCH v2 3/3] xl: new "loglvl" command Date: Tue, 8 Mar 2016 19:05:06 +0100 Message-ID: <1457460306.3102.277.camel@citrix.com> References: <56D9C80702000078000D9910@prv-mh.provo.novell.com> <56D9CA6002000078000D9935@prv-mh.provo.novell.com> <1457117113.2959.594.camel@citrix.com> <56DD783602000078000D9EE0@prv-mh.provo.novell.com> <1457374039.3102.82.camel@citrix.com> <56DE96A502000078000DA3E9@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1877116771694396672==" Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.84) (envelope-from ) id 1adM0o-0004r8-0x for xen-devel@lists.xenproject.org; Tue, 08 Mar 2016 18:05:38 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: George Dunlap , Jan Beulich Cc: Wei Liu , Stefano Stabellini , Ian Jackson , xen-devel List-Id: xen-devel@lists.xenproject.org --===============1877116771694396672== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-7102wVyoNTiqzEVPcz/c" --=-7102wVyoNTiqzEVPcz/c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2016-03-08 at 14:05 +0000, George Dunlap wrote: > On Tue, Mar 8, 2016 at 8:08 AM, Jan Beulich > wrote: > >=C2=A0 > > Right, and asking people myself to not follow bad examples when > > adding new code, I did take all of your input to adjust the patch. > > Just that in this case the set of bad examples is so large that in > > a > > similar case in the hypervisor I probably wouldn't have dared to > > ask for a style correction. > Well the approach of the libxl maintainers seems to have be, "Just > make sure the new code adheres to the new style, and eventyally > everything will be up-to-date". > Funnily enough, basing on my experience, libxl does not look that bad to me, and every time I've been bitten by something like this, it was in Xen rather than in libxl. :-D Of course, although I've been active in both, I don't claim that my experience is statistically significant... I guess it depends on what specific areas of code one gets to work on. Anyway, I personally don't think this affect in any way the point that new code should comply as much as possible with coding style, existing best practises, etc., and that is true for this patch, as well as for all the times everyone of us may have been asked to do the same, either in xen, tools, or anywhere... In fact, especially if we decide to do this (which I'd be in favour of, and up for helping): > Given that the "new" style has been around for a while now, it > probably would be good to set aside some time at the beginning of the > next development cycle to fix things up > being strict about new code actually helps this, as it makes sure there is less --rather than more-- code to fix during such a huge fixup challenge! :-) > -- it is incredibly > frustrating to carefully try to copy the surrounding style, only to > be > told to revise it. >=20 Yep, I fully agree. Regards, Dario --=20 <> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) --=-7102wVyoNTiqzEVPcz/c Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEABECAAYFAlbfFFIACgkQk4XaBE3IOsRbDQCfRxwVgq/acmmfZwbzSFm10HTr hRgAn2ZxzEhOihLgdggzu++xE2NV90tx =uGlg -----END PGP SIGNATURE----- --=-7102wVyoNTiqzEVPcz/c-- --===============1877116771694396672== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============1877116771694396672==--