So, then how does the parodied scenario demonstrate an imagination if that's exactly what you're wanting to do?
--- "David E. Jones" <[EMAIL PROTECTED]> 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. > === message truncated ===
