Re: State of Salomé

[Denis Barbier]

On 2011/1/11 Alain Leufroy wrote:
>> 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)

Thanks Alain for your feedback.
Adam, what is your opinion?

Denis