Bug#587007: salome: Porting patches to Salome 5.1.4 for upstream inclusion

[Adam C Powell IV]

Hi André,

On Wed, 2010-10-13 at 17:38 +0200, Andre Espaze wrote:
> > 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.

I am not working on these patches (just trying to get this 5.1.3-11
release out the door), so feel free to go ahead.  I think it makes sense
to send in the patches without these, then add them later; but if you
think they will more readily accept them all at once, feel free to do it
that way.

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Engineering consulting with open source tools
http://www.opennovation.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/debian-science-maintainers/attachments/20101013/8c51a44d/attachment.pgp>