Hi Adam, > > First, apologies for the delay in getting back to you on this. I was > waiting for an opportunity to sink a good amount of time into reviewing > your patches, and it didn't come, until I realized this morning that I > had missed your deadline by a day. :-( No problem, I understand that you are very busy. Thank you very much for the review. > > On Thu, 2010-09-23 at 12:00 +0200, Andre Espaze wrote: > > Hello Adam, > > > > > > Then what would be the relevant place for submitting patches of the > > > > remaining modules? Is it a good idea to send them to the bugtracker > > > > like I did for the kernel? Or could I let them on the Mercurial > > > > repository of http://www.python-science.org/project/salome-packaging? > > > > > > I think the Debian bug tracker is better for me, I find it easier to see > > > them and give feedback this way, and it's more of a standard Debian way > > > of doing things. > > I have enclosed in the 'salome-packaging-0.2.tar.gz' archive the patches > > updated to the 5.1.4 version for the KERNEL, GUI, GEOM, MED, SMESH and > > VISU modules. Once I get your agreement, I plan to send that archive to > > upstream because I am around half way of the porting task, with around > > 50 patches on 100. Moreover most of the essential modules are working. > > My concern is now to know which kind of patches are going to be accepted > > before continuing. > > > > The patches come with a documentation explaining briefly their > > meaning. Then the steps on how to build and run every module on Debian > > sid are described. I did not use the tools in the Debian packaging > > system (debian/rules, fakeroot, git-buildpackage, quilt) in order to > > ease the review process. Instead, I imitate the building process > > by listing commands. By that way, I hope that it will be possible > > to discuss with upstream on a specific point by directly using > > the commands provided by their build system. > > Thank you for taking on this huge task! I can see that you've put an > enormous amount of work into making the patches really helpful for > upstream. > > My only concern about the whole thing is that the -debian-dirs patches > right now are not in good shape for upstream, so I think we should > figure out how to make them more generic using libdir and bindir before > sending them in. This will be very tricky for source code files, like > C++ code. The best way to do this will probably be to use -DBINDIR=... > and -DLIBDIR=... where those are substituted in the Makefile by > configure. Ok, it sounds good. > > I'll see about converting those patches in this way. In the meantime, I > think everything else is ready to go in. Thanks again for a great piece > of work, and apologies again for the delay in getting this feedback to > you. Are you working on those patches or may I try to help you? From now, I understand that I should wait a little more before sending the first release. By the end of the month, I can also send patches that are ready to go in if you would prefer that option.
Best regards, André -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
