Difference: CoreSoftwareMeetingMinutes20110914 (4 vs. 5)

Revision 52011-09-16 - MarcoClemencic

Line: 1 to 1
 
META TOPICPARENT name="CoreSoftwareMeetingMinutes"

LHCb Core Software Meeting

Line: 34 to 34
 
Added:
>
>
 

Discussion about Windows support

A long discussion followed the comment about dropping Windows, which I try to summarize here (including some more information than the one exchanged during the meeting).
Line: 50 to 51
  The last point is still valid. There is a good value in keeping our software portable and we must do it even if dropping Windows. The main problem is that if we do not force the developers to write code that works on Windows, it will be much more difficult (almost impossible) to keep our code portable.
Changed:
<
<
Despite the fact that portable code is better and our code is portable, the adoption of a new platform is heavily limited by the way we build and configure it (we need LCGCMT binaries and configuration). Moreover, some developers do not see the need of the portability to Windows, or they simply do not care.
>
>
Despite the fact that portable code is better and our code is portable, the adoption of a new platform is heavily limited by the way we build and configure it (we need LCGCMT binaries and configuration). Moreover, some developers do not see the need of the portability to Windows, or they simply do not care. We may also decide that the portability to POSIX platforms is enough.
 
Changed:
<
<
We should also take into account the cost (in terms of men power) of the support for Windows.
>
>
We should also take into account the cost (in terms of man power) of the support for Windows.
  Building the full LHCb stack on Windows is not a problem (the release is usually smooth, except for few cases).

What really costs is the maintenance of the infrastructure, mainly of the nightly builds, which are the basic tool to test the portability of new code. Most of the problems in the Windows nightly builds are due to limitations of the system and not to the code itself.

Changed:
<
<
Another big cost is the maintenance of the Windows builds of the LCG externals (the AA projects are not really a problem). SFT groups is kindly keeping the Windows builds in sync, wherever possible, with the Linux ones, but it's men-power spent only for LHCb, so it's difficult to justify it for a group that is supposed to work on tasks meant to support more than one experiment.
>
>
Another big cost is the maintenance of the Windows builds of the LCG externals (the AA projects are not really a problem). SFT groups is kindly keeping the Windows builds in sync, wherever possible, with the Linux ones, but it's man-power spent only for LHCb, so it's difficult to justify it for a group that is supposed to work on tasks meant to support more than one experiment.
 
Changed:
<
<
Note: Gaudi is not considered in this discussion, because it will support Windows (e. g. for other customers than LHCb). The point of the discussion is if LHCb should still ask SFT/AA to build everything on Windows for us.
>
>
Note: Gaudi is not considered in this discussion, because it will still support Windows (e. g. for other customers than LHCb). The point of the discussion is if LHCb should still ask SFT/AA to build everything on Windows for us.
 

Comments

Please, add here comments and contributions to the discussion.
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback