[QGIS-Developer] Trying to upstream fixes for libdxfrw

[Vittorio Carlo Alfieri]

On Wed, May 23, 2018 at 4:28 PM, Jürgen E. Fischer <jef at norbit.de> wrote:

> Hi Vittorio,
>
> On Wed, 23. May 2018 at 15:31:44 +0200, Vittorio Carlo Alfieri wrote:
> > While these changes are good, unfortunately, (for me at least), all these
> > I humbly request, if available and not available online somewhere, a copy
> > of the git repository used to develop libdxfrw up to the point where it
> was
> > introduced in Qgis in 2016 so that I may continue to bisect the code and
> > find the fix for the DWG that I can't open outside of Qgis.
>
> You're looking for https://github.com/jef-n/QGIS/commits/dwg-import ?
>

Wow, yes! Exactly this. I can now continue digging around for the fix.
Thanks!


>
>
> > P.S. If the original git repository is still available it would be great
> if
> > placed on Github and possibly even used as a submodule within qgis itself
> > so as to have the same git tree as upstream for libdxfrw. This would
> > greatly increase harmonization of source code between the various forks
> of
> > libdxfrw and de-duplicate much effort for all parties! I would be willing
> > to help implement this for you guys if so desired.
>
> Isn't libdxfrw dead?
>
> https://sourceforge.net/p/libdxfrw/code/ci/65177975f7999fc37
> 5813bb50b463554f7395d08/
>
> is what I started from and it's still the latest commit...
>

Yeah, I also noticed this. While the Sourceforge repo appears dead, there
has been recent
development for libdxfrw at the following git source trees (amongst others):
https://github.com/rvt/libdxfrw/commits/master
https://github.com/LibreCAD/LibreCAD/commits/master/libraries/libdxfrw/src

Please note: I am not a member of the LibreCAD team, I am just trying to
fix a bug upstream that is affecting me, and noticed that you had fixed it!
Congratulations on your hard work.

Personally, I would choose https://github.com/rvt/libdxfrw as the
"upstream" for this library,
for the following reasons:
1. It contains the entire git source tree, including initial development
from Rallaz, the original
creator of libdxfrw and one of the lead developers of LibreCAD 2.
2. It is already used as a submodule in the upcoming LibreCAD 3.
3. Without too much work from the LibreCAD team it can also be used as a
submodule in LibreCAD 2.
4. It is on Github instead of Sourceforge.
5. It seems to be condoned by Rallaz himself, because the developer, RVT,
is also an administrator
of the SourceForge repo and a member of the LibreCAD team on Github.

In the end it doesn't really matter which git upstream is chosen for the
library, as long as the object ID
of the first commit is the same as the original Sourceforge version. This
tells git that we are talking
about the same source tree. This is not the case in the current Qgis source
tree since libdxfrw
was "forked" from the Qgis source tree.

In my mind, ideally the Qgis project would clone/fork this library, rebase
the Qgis specific modifications
onto the latest upstream version and perform pull-requests for non
qgis-specific fixes.

After this fork is successfully created, it could then be integrated by the
Qgis team as a git submodule
in order to permit merging and re-basing between the various forks of the
libdxfrw project
independently from the Qgis development.

If this is interesting to you, before performing any changes, I would
consult LibreCAD team to make sure
I'm not way off-base and wrong.

I would be willing to help, if so desired, with any of the following:
1. Contacting the LibreCAD team to see if rvt/libdxfrw is going to be their
upstream going forward.
2. Rebase your modifications of libdxfrw onto rvt/libdxfrw source tree and
create the qgis/libdxfrw fork.
3. Try to upstream whatever commit fixes the bug that is affecting me.

Regardless, thank you for the prompt and helpful response,
Vittorio Alfieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180523/a599f5dd/attachment.html>