State of Salomé

[Alain Leufroy]

> On 2010/9/28 Adam C Powell IV wrote:
> > Hello André,
> > 
> > On Tue, 2010-09-28 at 11:04 +0200, Andre Espaze wrote:
> >> Hello Adam,
> >> 
> >> > The Debian Salomé package is good, and keeps improving.  But I don't
> >> > want to upload -11 until there's a fix for at least the RC bug, if not
> >> > two other runtime bugs, and I need some help.
> >> > 
> >> > The RC bug 595281 is FTBFS with three different errors on Alpha, IA64
> >> > and Sparc.  It looks like there may be a problem with IDL compiling of
> >> > GEOM_Gen.idl as all of the errors are in its generated source files.
> >> 
> >> Whitout being developper, is it possible for me to access such platforms
> >> with a normal user account? Or should I try to work with a Debian
> >> developper? Or may you have another advice for trying the compilation
> >> on Aplha, IA64 and Sparc?
> > 
> > As far as I know, the Debian porting machines are restricted to
> > developers.  I will see if I can get some time to log in to one of those
> > machines and try a build.
> > 
> >> > The runtime bugs are 596957/596959 (identical and merged) and 597885,
> >> > one is a GEOM module segfault, the other looks like a CORBA problem
> >> > during Salomé initialization by runSalome.  I don't see either of
> >> > these problems, so I'm tempted to tag them "unreproducible".
> >> > 
> >> > A third relatively minor bug is 597739: salomeloader doesn't work
> >> > because of a simple-looking python issue of some kind, someone who
> >> > knows a little python should be able to fix it in 5 minutes.
> >> > 
> >> > I'm a bit over my head with all of these, and don't know where to
> >> > start. Can someone help at least with 595281, so we can upload and
> >> > have a shot at releasing with squeeze?
> >> 
> >> I will try to investigate the remaining bugs tomorrow.
> > 
> > Thank you!  You may have seen someone else has found the same problem as
> > 596957/596959 (the GEOM module segfault), so I can't tag it as
> > unreproducible.
> > 
> >> > In other news, André has ported nearly all of our patches to the
> >> > latest upstream, and will send them in soon.  If all goes well, 5.1.5
> >> > (or whatever the next upstream release number is) will have many of
> >> > our patches included, and packaging future releases will be *much*
> >> > easier. Thanks André!
> >> 
> >> You are very welcome! I was pleased to bring a minor contribution to
> >> the difficult task of Salome packaging. Thank you very much for leading
> >> such project. By the way, do you think that I can send the report and
> >> patches by the end of the week? Or would you prefer to have more time
> >> for a deeper review? Then from this Thursday, I am going to be
> >> unavailable until the 12th of October.
> > 
> > I should have time to review these patches by the end of the week, maybe
> > even today...
> 
> Hello all,
> 
> I have been inactive for months; there are many reasons, at least:
>   - not enough free time
>   - salomé is such a big beast that it is not possible to dedicate few
> hours from time to time
>   - builds take way too loooooooong
>   - IMO the salomé Debian package still needs a lot of work before it
> can be included in a stable release, I did not want to 'lose' my time
> and chose to work on other projects
> 
> The current packaging makes sense, but I wonder whether splitting the
> current monolithic source package into small components (one source
> package per salomé component) could help us to improve momentum.  IMO
> it will be much easier to deal with bugs/ports, and when the Debian
> packages are of high quality, we could reconsider this decision and
> come back to the current layout.
> What do you think?
> 
> Denis

Hello Denis,

André and I agree with you for splitting the big monolithic source package.

Advantages:

* smaller src sizes
* smaller git repositories (speed up cloning and easier commit management)
* more modular building (less resources intensive)
* smaller building time to get a simple running salome (if you make a mistake   
  in the GUI module, you do not have to re-build the overall salome package)
* clearer and cleaner debian rules
* easier to take into account salome modules evolution ("visu" is going to 
  be replaced by "paraview" in Salome 6)
* specific bug tracking
* easy for new devolppers to join one (or more) project

Disadvantages:

* We have to create and manage several projects and mailing lists and so on.
* We have to create specific debian rules for every project (but we already 
  know everything to do)
* Many packages will show up when running apt-cache search (see texlive)
* We should to create meta package to help users to install a common/full 
  salome


By the way we have send patches to upstream for salome 5.1.4 and they should 
be integrated for the middle of january (and ported to the current salome 
version 5.1.5 or higher)

Alain and André

--
Alain Leufroy
http://www.logilab.fr/
Informatique scientifique & gestion de connaissances