On 12/13/05, David Ferlier <[EMAIL PROTECTED]> wrote: > > > For libraries that we have modified, there are several ways to take them > > > out of the tree : > > > - generate a patch that makes a vanilla libs into a customized one, and > > > apply this patch to a given release of the lib when we build the software. > > > - submit the patch upstream to request its inclusion in the lib. > > > > > > The best solution, IMHO, is the second one, but it won't always be > > > possible. The first one requires that we track each lib's so that we can > > > generate a patch that applies blissfully to any new release. > > > > i think too that the second way is the better, > > I personally highly prefer the first solution. If you knew what > modifications we make to the third-party libraries we integrate, you > wouldn't even ask ;)
As I already said, if you are _that_ far from the pristine sources, you are actually working on a fork. This is your choice, which has some implications I am sure you evaluated before going down this path; I am really not in a position to judge whether merging back to upstream is feasible or desiderable. > > All our modifications wouldn't interest the authors of the project > because they are sometimes hacks, sometimes diffs to work around the > project limitations (for example with curl, we added just one function > to be able to use curl with an already opened socket). Upstream developers could not be interested but, sticking to the curl example, did you actually try to write a mail to the curl-library mailing list? If using curl with an already opened socket is not supported it could be for a reason; for example, possible reasons include: 1. no one ever asked for the specific feature 2. someone asked, but no developer was interested in coding it (or had enough time) 3. it is, for some reason I do not know, a bad thing to do Whatever is true, they are in the best position to state why this feature is not there. May be reasons 1 or 2, I think they would be more than happy to at least evaluate a patch. May be the third (or somethig else), it would not be a waste of time because you will know more about why the limitation is there, hence in a better position to decide how to proceed thereon. Please note, I am not here to tell you how to manage your project. I am only trying to help identify issues that would prevent the inclusion of this program in distros (and you have already a direct interest from 2 of the major ones...) Gianluca _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
