On Sat, Aug 31, 2013 at 1:46 AM, Danilo Pianini <danilo.pian...@gmail.com> wrote: > Can you suggest me a way to do it *QUICKLY*? > I really don't see the point in not merging more commits. It's not a beauty > contest, it's development.
You must do things right, or at least try to do them. It's not a matter of beauty, it's a matter of just doing things the way they should be done. > I cannot negate I am getting really tired of the > current development process: having your code reviewed is extremely good, > learning git better is even more good, having to change things to met > reviewer's requirements then revert changes because he changed his mind then > again do it all in a single commit is *EXTREMELY TEDIOUS*. The problem I've seen in your pull requests is basically that you tend not to do what your reviewer is asking you to do, trying to make up something to "workaround" the request. That's not going to work. I hardly think that in this case, it's the reviewer's fault. > And it is NOT > possible that a whole month is needed to get a package bumped. This is the problem people have when they start doing code reviews for the first time on a codebase. If you do all perfectly, your commits will be merged very quickly. If you don't, the time taken is going to be polynomial. Typically, as time goes, you'll learn more and improve your commits from the beginning so that the review phase won't take more than a couple of days. Do you know what is extremely tedious, more than what you're complaining here? Having to fix broken ebuilds. Having to revert bad commits. Trust me, it takes even more time than what you may even take. Creating broken code is a /dev/urandom function, fixing broken code requires a lot of brain power and *time*. > > > > > -- > Ing. Dott. Danilo Pianini > > Site: http://www.danilopianini.org/ > Phone: +39 320 41 36 573 > Skype: dany.sk > > > -- Fabio Erculiani
