Hello, I will try to rephrase this in different angle as well.
During the time you made a review and found no issues, I took the time for reviewing my own code and further test, and I found issues to be fixed, sent the patches to me back to review. Just think of it as another developer would have found issue which caused patch resubmit. The fact that I did find issues while nobody else found means that I am doing good job in reviewing as well :) You should take the branch as-is, unless you have explicit comments for the quality of the code and/or solution. Alon. On Thu, Mar 22, 2012 at 5:37 PM, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > No. > Please don't take the patches from the mailing list. > As I explicitly requested in the past *SEVERAL* times. > > I've done minor fixups in my repository. > As you see my work is in good quality and without comments, issues I > fixed needs to be fixed in tree as well. > > As I requested this approach several times and got no rejection I > assumed this is acceptable. > > This is a *COMPLETE* show stopper. > > If you insist in doing that this way I will resend the patch series to the > list. > > Alon. > > > On Thu, Mar 22, 2012 at 3:57 PM, David Sommerseth > <openvpn.l...@topphemmelig.net> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 22/03/12 12:47, Alon Bar-Lev wrote: >>> On Thu, Mar 22, 2012 at 1:45 PM, David Sommerseth >>> <openvpn.l...@topphemmelig.net> wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>> >>>> On 19/03/12 16:16, Alon Bar-Lev wrote: >>>>> The only component that is in question is lzo. I still think this >>>>> is packager responsibility, not sure why this is an exception. But >>>>> if it will make people happy, I will enable lzo by default. All >>>>> the other components are optional by they nature, and again it is >>>>> up to packager to decide what good for his configuration. >>>> >>>> Hi Alon, >>>> >>>> Okay, based on the discussion on this thread, it makes sense to then >>>> flip LZO to be enabled by default. >>>> >>>> No need to hurry with any patches, as I can add such a patch on top >>>> of everything when the merging is completed. The patch will be >>>> submitted to the mailing list when it's ready to be implemented. >>>> >>> >>> OK, great. I will modify the branch with this (rebase) so it won't >>> create additional noise. So you be able to do a clean pull with >>> complete feature set. >> >> No, I will take this change as an additional patch - as I stated in my >> previous response. I don't want to base such changes on patches which >> are already reviewed and ACKed. That invalidates the work queue I'm on >> already. I'm taking patches from the mailing list, that works very well >> in my workflow - and it gives a good chance of providing the Acked-by >> statements in the git log. >> >> >> kind regards, >> >> David Sommerseth >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAk9rL74ACgkQDC186MBRfroCqwCgqIzkHlcJ7m3qRLMVFapIcVdj >> OZgAnAzlHiBtFBanDaO/KBO1MQo8zooU >> =+ET7 >> -----END PGP SIGNATURE-----
