Re: OFBiz UI work

[David E. Jones]

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

entry

of each set, and

see if the 2nd entry is
highlighted similarly. Meaning, if it is

highlighted similarly,

the set of changes is bogus
(formatting only).

In general, we should submit patches that are
intentional, ie just the intended changes

only.

We should not

submit patches that contain unintended
changes that have extra unintended footprints.

Jonathon

David E. Jones wrote:

Moving this back to the mailing list...


On Jan 15, 2007, at 5:34 PM, Adrian Crum

wrote:

David E. Jones wrote:

When reviewing a patch lines with

formatting

changes only are

EXTREMELY time consuming, and the patch

attached that issue is a

good example of a painful one. For each of

those line you have to

stare at it looking at every character

trying

to figure out what the

point of the bloody change was, or to make

sure

that the change is

"invisible"...

That really puzzles me. You keep mentioning

formatting changes when I

don't see any. I didn't make any formatting

changes when modifying the

=== message truncated ===

smime.p7s
Description: S/MIME cryptographic signature