commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Qingtian Wang" <qingtian.w...@gmail.com>
Subject Re: codec - thread safe
Date Sun, 07 Oct 2007 20:23:51 GMT
Ok, I got the point.

So let's say I wanted to work on this. What's the most effective way to do it?

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
on. I think that'd be much more effective. Any established channel
where that can happen?

Thanks,
-Q



On 10/7/07, Torsten Curdt <tcurdt@apache.org> 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: user-unsubscribe@commons.apache.org
> For additional commands, e-mail: user-help@commons.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@commons.apache.org
For additional commands, e-mail: user-help@commons.apache.org


Mime
View raw message