On 10/7/07, sebb <[EMAIL PROTECTED]> wrote: > On 07/10/2007, Qingtian Wang <[EMAIL PROTECTED]> wrote: > > Ok, I got the point. > > > > So let's say I wanted to work on this. What's the most effective way to do > > it? > > You could try running some of the code checking utilities on the library. > > For example Findbugs and PMD. > > I've done a quick check with FIndbugs, but that has not found any > synchronisation issues. This is because there are no synchronised > methods, so it cannot find any inconsistencies. > > But it should be possible to configure PMD to find any instance or > static variables that are modified after construction. > > Or indeed you could perhaps try making all such variables final, and > see whether it's possible to fix the compiler errors - but that might > be a lot of work. > > > Search the entire code base line by line trying to ID all the thread > > unsafe points by myself? I guess that's very ineffective compared to > > have an issue open, and have the individual developers who write the > > code to address it - They know what needs to be tweaked without having > > to even spend any time since it's their own code. Or at least, the dev > > team as a whole can come up a list of points that need to be worked > > Not necessarily - the code may have been developed over a long period, > and the original authors may not longer be around. Unless the code has > been worked on recently, it's possible that no-one has much detailed > knowledge of the code.
Wow, if that is really the case with commons codec that no one has detailed knowledge of the code, it would suggest to me that no one should use it as a off the shell usable product since no one really knows what it would do. I mean, it's one thing to say "Here's what our intention what this product behaves. But use it at your own risk since there is no guarantee of any kind.", but it's entirely different thing to say "Here's a bunch of code, but we don't know how it behaves, you're welcome to find out for yourself and play around with it." To me those two things put a product at two rather different level of maturity. If codec falls in the latter, a normal user that needs a codec library for their work might as well look some where else or roll their own stuff to hand their codec needs, since it'd take same or even more time to dig in commons-codec and try to find out what exactly it's trying to do. -Q > > > on. I think that'd be much more effective. Any established channel > > where that can happen? > > If you find some bugs, then report them via JIRA. > It helps if you can provide test cases; obviously patches as well is > even better. > > > Thanks, > > -Q > > > > > > > > On 10/7/07, Torsten Curdt <[EMAIL PROTECTED]> wrote: > > > >>> Can the dev team make that happen? - a humble request from a user. > > > >> > > > >> The think about open source is that there is no distinction between > > > >> developer and user. > > > > > > > > That's interesting. Why then almost all open source projects have > > > > "users doc vs. developer doc", "users mailing list vs. developers > > > > mailing list"....? > > > > > > Point taken. But this is more about the presentation of information. > > > Still the distinction is blurry as many developers and contributors > > > come initially from the user background. They felt the itch to > > > improve the code and ended up providing the fix/feature > > > themselves ...I guess we are trying to get you to do the same :) You > > > should see that more as an invitation to help. > > > > > > >> The developers develop because they want to use the > > > >> code. And when somebody wants to use a feature that doesn't exist, > > > >> then > > > >> they can develop it. > > > >> > > > >> In short, if you want this feature, you can do this yourself and > > > >> post a > > > >> patch to this list so it gets included in the next release. There > > > >> is no > > > >> paid "dev team" for any of the commons code. > > > > > > > > OK i see. My intention was just to bring up an issue/request. There is > > > > no saying the developers are obligated to work on it. And contributing > > > > code is certainly not the only way of involving with an open source > > > > project. > > > > > > That is of course true. But I guess what Simon was wanting to point > > > out is that "requesting a feature" rarely means it gets done unless a > > > developer needs that feature too. The personal TODO lists are usually > > > very long. So usually you are better of contributing a patch > > > yourself ...or pay someone to do it for you. That's how it works. > > > > > > > Nevertheless, if the dev team (unpaid as I understand it) > > > > wants the project to be more popular, it might help listening to what > > > > other users have to say other than themselves; otherwise just forget > > > > about it. > > > > > > Well, sure ...listening is great - but someone gotta do it. > > > There is no us vs you, no dev vs user ....there is just us. > > > > > > Does that make sense? > > > > > > cheers > > > -- > > > Torsten > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
