Si Chen wrote: > Adam, > > If there were some older patches that got missed two years ago, maybe > it's good to submit them again. We do have more committers back then.
My general feeling from a bit ago, was that patches tended to languish, and not get applied. Once instance, I filed a bug during the 2005 users conference, that fixed an off-by-one bug in the ofbiz-home resolver. An obvious one-line fix, that sat around for ages. When simple things tend to get ignored, it makes one less likely to try and push more complex changes. I have noticed a change in that recently, however. > As to the general question of why patches don't get applied "by those in > charge," obviously we could all work harder for the good of the > project. However, please don't underestimate the amount of time that it > takes committers to review patches and test them. If you or anybody > feels that your patches are ignored, please try to make it more clear > (a) what your patch does--send in screenshots, describe how it works, > etc. and (b) above all, write good, clean code that can just go in right > away. There are patches in jira which are themselves buggy, difficult > to understand, formatted incorrectly, or just don't even patch. Also, > it helps if you contribute on a somewhat regular basis so that your > patches are coming from a "trusted" source. What kind of automated testing is there? What are the procedures that committers do? It'd be nice to get this documented, so that those willing to help can try to do more of the work themselves. Pushing things out to the leaves can reduce strain on those in the center. Of course, writing this documentation itself takes time. Unfortunately, this often turns into a catch-22. Those at the upper levels are so busy doing work, that they have no time to write documentation or train others so that more can be delegated. It happens all the time in debian, and can be very frustrating for all involved. > Last of all, it's not a matter of one person having to do all the work > at fixing something. The fact is, we're all working here all the time > to help make it better. However, it's not a good practice to put > half-finished things in the project, or break one feature to make > another work. That just creates more problems for everybody. One of > the stated policies for us the committers, in fact, is not to commit > things until they're reasonably complete and functional--and we could > all do better at it. As for the one person, it seems those in this thread are feeling like I was attacking, or singling people out. That was not my intention. If people read it that way, then it was my fault for allowing such an interpretation to occur. I will admit that I only did a compile test, and a search/replace on the package names(for this particular bug(401)). That was plain oversite on my part. Internally, we don't use jpublish, nor the screen widget, for our own applications, so this generally isn't a problem for us. I will be revisiting this bsf issue, and getting jpublish to work, as I really think this patch needs to be in rather soon. > > On Nov 1, 2006, at 2:00 PM, Adam Heath wrote: > >> Si Chen wrote: >>> I don't know about the particulars of the commons-fileupload library, >>> but the problem with the bsf is that it interfered with the currently >>> used jpublish. If you can supply an upgrade combination of bsf and >>> jpublish that still works, I think that should work for me (and >>> hopefully the other committers as well.) Otherwise, given how little >>> the bsf library is actually used in the core ofbiz applications and >>> framework, it made little sense to break existing functionality just to >>> get a newer version of it. >> >> Yes, well, there is a patch from someone else from 2004(see the bug) >> that fixes that. And that patch was never applied. >> >> It's all well and good to provide patches, but if they never get applied >> by those in charge, it makes those that provide said patches reluctant >> to provide more in the future. >> >>> In general the goal of updating the libraries is a good one, but in my >>> opinion it has to be well-tested so that the functionality of the core >>> project is not compromised. >> >> So, instead of going forward, fixing jpublish, you'd rather stay back? >> Why does one person have to do all the work at fixing something? > > Best Regards, > > Si > [EMAIL PROTECTED] > > > >
