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