Wow. This subject sure took off from my original dilemma.
Actually, there's an element of truth to what Chris said. At first glance the
policy seems mean-spirited. But as was mentioned in another reply, it's a good
way to train the submitters.
Personally, I have a pretty thick skin, so what David proposed doesn't offend me
or discourage me. Instead, it motivates me to take a closer look at what my IDE
and SVN client are doing to cause these unintentional formatting changes.
I truly appreciate the time David took to address my problem. Without his
detailed description of the problems with my patches, I wouldn't know what was
wrong with them.
David E. Jones wrote:
I'm not sure what to say, perhaps what I originally said would be helpful:
"People tend to slip things into patches accidentally all the time. I'm
tempted to begun the voting process for a new policy that says that if
there is anything in the patch file not described in the summary of the
patch, then it will be rejected..."
-David
On Jan 15, 2007, at 10:44 PM, Chris Howe wrote:
Sorry, I don't know why that quote didn't hit me right
the first time. My apologies to W.C. Fields. “Go
away, kid, you bother me”. I really butchered it. I
mean _really :-)
So, if that's not the policy and procedure you're
looking to adopt, please elaborate on what you're
tempted to propose.
--- "David E. Jones" <[EMAIL PROTECTED]> wrote:
You have quite an imagination.
-David
On Jan 15, 2007, at 10:01 PM, Chris Howe wrote:
Being tempted to ask for a vote, insinuates that
you
want to condone a practice whereby if you go to
review
a patch like in Adrian's case and it has
superflous
formatting changes, that you would delete it from
JIRA
in a "sorry kid, you're wasting my time" dismissal
(email impressions added for levity). Anything
less
is what is currently going on and wouldn't need a
vote. People aren't tempted to vote on the status
quo.
--- "David E. Jones" <[EMAIL PROTECTED]>
wrote:
Ummm... what do you think when you think of a
rejection policy? We
already have patch rejection policies when
problems
are found...
-David
On Jan 15, 2007, at 9:44 PM, Chris Howe wrote:
I agree. I think it's better that we strongly
encourage certain practices (as we are doing
now)
and
bring people to notice when those practices
could
be
improved, but rejection policies put your _means
perspective ahead of your _ends. Contributions
may be
easier to review, but I can gaurantee you with
rejection policies, you will then have less of
it
to
review and thereby less solutions making it back
into
the project.
--- "David E. Jones" <[EMAIL PROTECTED]>
wrote:
Yes, we want more people, but I don't think
anyone
wants
indiscriminate changes going into SVN! I hate
surprises when I check
out as much as the next guy, probably more than
the
next guy in many
cases.
Thinking about the next guy is the real key
here.
You may want to get
your patches in ASAP, but if your patch breaks
existing code (for
example), then that needs to be fixed before
the
commit is done
(either by the committer, the contributor, or
an
interested third
party).
So, yeah, that slows things down and is
inconvenient, but keep in
mind that a large portion of patches that come
into
OFBiz break
existing functionality. This seems to happen
around
once a week or
so, at least.
It's great that people want to contribute, but
in
or
to contribute to
something as large and complex as OFBiz a large
amount of effort is
necessary, and anyone that wants to help out
will
err on the side of
extra effort, caution and review, and
consideration
of more general
requirements and designs rather just one's own
requirements.
-David
On Jan 15, 2007, at 7:42 PM, Jonathon --
Improov
wrote:
Heh. True. I definitely want MORE people
involved
in OFBiz.
But since I'm not a committer, I'd rather make
things easier for
the committers. I have no control over how
easy
or
difficult it is
to handle patches with "extra unintended
footprints".
If I were a committer, I would try to
automatically filter out
formatting changes in my audit, and then
INCLUDE
the formatting
changes. After all, there's no harm removing
some
extra spaces at
the end of lines, part of clean up.
We often try to make things easier for the
person
who is doing a
task that we have no control over. Eg, I'd
keep
my
mouth really
wide open for my dentist just so his vision is
20/20, no arguments
from me; I could afford to be slack about this
"mouth wide-open
policy" if I were able to do the dentistry
myself.
But you're certainly right that it'll exclude
some
people,
especially folks who use editors that do not
give
very much control
to users.
Jonathon
Chris Howe wrote:
I don't know that rejection policies are very
community friendly. Treating SVN code
changes
like
the keeper of the Bridge of Death (Monty
Python
Reference, smile) may find less people
willing
to
do
in this do-ocracy. Many of us rather like
what's
left
of our anarco-sydicalist commune (oh look,
there's
another :-) ).
--- Jonathon -- Improov <[EMAIL PROTECTED]>
wrote:
David,
I agree with the rejection policy.
One suggestion on procedure to take when
self-reviewing a patch before submitting it.
Look at
the diff to see if there are changes we
cannot
account
for. Using KDiff also makes things easier,
even
when dealing with
formatting changes.
In Emacs, it's also easy to go through every
set
of
changes, do an interactive-search for 1st
=== message truncated ===
