On 05/16/2012 05:28 PM, Matt Wagner wrote:
On Wed, May 16, 2012 at 10:03:17AM -0400, Jason Guiditta wrote:
> Hey, list, had a thought on pushing patches. I have noticed some
> people (inconsistently) pushing patches others send after they review
> them, and adding a 'signed-off by' to the patch. I kind of like this,
> as it adds a simple way to see who reviewed a patch.
This is easily accomplished with adding "-s" to your git-am run.
In deltacloud it's already in this way. Very easy to see who did what.
Instead of playing every time with git -s you can also add in your fantastic
.gitconfig or in the project .git file this lines:
8<------
[format]
signoff = true
------>8
OT:
Honestly, I like both parts (writing, reviewing) because:
- reading others code is sometimes inspiring
- you can look at a review as a challenge if you are able to break the
code (find weaknesses)
- it's easiest place where you can effect quality of code
Completely agree with
you Jan. You're able to learn more reviewing code than just
sit and write your own.
Though it's quite difficult/annoying to keep both in balance
because:
- it's quite difficult to keep overview if some patch needs a review or
not, there are many hands on this project and big traffic on the list
(where are those times when it was possible to read through all patches
on the list)
Exactly.
- most patches land on the list few days before sprint ends, and doing
only reviews couple of days is not very attractive
In this way we shoot on the foot of the project itself because come all the rush
on reviewing patches before the sprint finish.
even more OT:
What is really demotivating for me is if I send a patch which then waits
week(s) on the list and I have to beg for reviewing it, I hope this gets
better when we start using a review tool.
I deeply agree here and it's really a bad behavior. I mean, we're doing a big
thing
with those clouds and rather we can get screwed on what we're building just for lack
of attention in review process or doing, something really evil, that can be the auto
review. The code should be audited by your colleagues not by yourself.
You will always agree with what you wrote. If it's a typo what the hell, is not
important
to follow the whole review part but just for typos.
I mean, we are an open source company, with our code and our brain power, the company get
the money to go forth. I am wondering which of you feel really proud of the amount of
code,
sometimes messy that it's in Aeolus. I bet there're obscure parts of the project
that we
neither talk about because it's too dangerous to put our hands on. That's not the
way to
act. No at all. WE (I am the first) should do better not just for the company itself but
for
the project, we need to feel proud of what we are creating/advertising. Otherwise the
best thing is to get something we believe/like. Even partecipate to Masterchef with Chef
Ramsey!
I want to see facts. Not bullshit code that stay there for ages and we put into a TODO
list
one day I will send a patch for that. Instead do it now. And remember, every single line
of code that
we're writing, is like giving a part of ourself to the community, so you should give
your best
part, not your worse one.
Jan
Thanks Jan for this email that pushed me to put in words my
thoughts.
Cheers,
Francesco