Hi, list, While running some routine checks (the likes that motivated my patches), I found libfm's source includes a few files coming from exo, nicely dated to ease comparison to upstream. However, they are also /dated/ (2009-08-30), and it's likely some of the bugs detected by the tools are already fixed upstream, and also many more the tools didn't catch.
I thought of three possibilities going forward: 1_ We keep working as if exo's code was our own, fixing the bugs independently of them being fixed or not upstream. 2_ We sync periodically, bringing the fixes made to the respective version of the file. In that case, tagging the files with the hash of the correspondent commit would be a good idea. 3_ We remove the copy-pasted code and just depend on exo as a third-party library. As I see it, 1 is the easiest path in the short term: it doesn't require us to update calls to deprecated functions, issues due to mixed dependencies with GTK2 and GTK3, and that sort of breakage. However, it is the least robuts. We are unlikely to catch as many bugs as upstream, for several reasons, including, but not limited to, the number of users, the man-power, and pure randomness. Number 2 has the partial advantage of a reduced amount of breakage due to library update on the target system, as we are still shipping our own files with the interfaces WE need. However, in the immediate term this comes with breakage because we lagged behind too much. It has the advantage of getting upstream's fixes, but lagging behind a bit. It also requires periodically checking, which I'm not sure we can guarantee right now. Number 3 also comes with a lot of breakage, and not only means aiming at a moving target, but it can cause harm to distributions, as they may need to update the library and we may not fully support it for a variety of reasons, one being we don't have yet complete support for GTK3. I think the most reasonable route would be to fix the immediate bugs (as in option 1), then migrate to near-upstream and later move to use it as a library. Of course, I'm thinking of a span of at least several months. I may or may not be able/willing to do that job. I'm not sure it's desired, really, since the move to Qt may render this obsolete, AFAIK. Opinions welcomed. Mario. _______________________________________________ Lxde-list mailing list Lxde-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxde-list
