Re: OFBiz UI work

[David E. Jones]

-David


On Jan 15, 2007, at 10:44 PM, Chris Howe 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..."

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 ===

smime.p7s
Description: S/MIME cryptographic signature