Re: Stellarium 0.12.4 legacy
On 11/08/14 12:48, Sergio Gelato wrote:
> * Tomasz Buchert [2014-08-11 11:24:28 +0200]:
> > On 11/08/14 10:58, Оlе Ѕtrеісhеr wrote:
> > > Tomasz Buchert <tomasz.buchert@inria.fr> writes:
> > > > one of the stellarium developers asked me if we could create
> > > > a legacy version of stellarium 0.12.4 (the current version
> > > > that is likely to be in jessie is 0.13.0 [1]).
Hi Sergio,
>
> Why (only) 0.12.4? In perusing the archive of the stellarium-pubdevel
> mailing list I came upon a comment by Alexander on 2014-07-20 mentioning
> 0.11.4 as the last version that was expected to work on a certain piece
> of legacy hardware (Radeon IGP 320M, OpenGL 1.3 only). It seems that this
> dropping support for older hardware is a recurrent event in Stellarium
> development. Where does one draw the line of what should be in Debian
> (as opposed to externally maintained packages)?
I guess this is what we are trying to find out.
Maybe there should be a global Debian policy about supporting particular
OpenGL versions? There is such policy about kernel versions.
>
> > > What is the status of the 0.12.4 development? Will they fix bugs in this
> > > release or just ask to update to the 0.13 line? Since it was an upstream
> > > developer who came out of this idea, he can probably do some statement
> > > how they handle the 0.12 line themself.
> >
> > 0.12.4 is End-Of-Line, but I've just asked them if they are going to support
> > 0.12.4 in the future. Note that stellarium has low number of bugs and it
> > shouldn't be a big problem.
>
> Security holes are the only ones I'd really worry about. Does Stellarium
> have a lot of interactions with the network? (Lookups in online catalogs,
> etc.) Is that part of the code stable enough for trivial cherry-picking?
I only know two elements that interact with the network:
satellites plugin and downloading of additional star packs.
As always, the developers should know better.
>
> > > > The reasons he mentions:
> > > > * 0.13.0 requires OpenGL 2.1+ and shaders - this maybe
> > > > problematic for machines older than 5-6 years or some Intel GPUs;
> > >
> > > I am not really familiar with opengl; can you make an example what is
> > > not supported (under Debian Linux)?
> >
> > As far as I understand, it's about hardware support. Older GPUs are unable to run
> > stellarium 0.13.0, because they don't implement necessary features.
>
> Wouldn't it be more accurate to say that Stellarium can run, but only very
> slowly because hardware acceleration of OpenGL API calls cannot be used?
Well, strictly speaking you are right. But "very slow" maybe "too slow" to
be of any use (funnily, running stellarium with LIBGL_ALWAYS_SOFTWARE=1 gives
me a fairly good experience, even if my CPU fans go crazy :) ).
>
> > > > this version runs on Qt5 as well
> > > > * on the other side, 0.12.4 requires only OpenGL 1.4 without shaders;
> > > > this version runs on Qt4
> > >
> > > Why is qt5 vs. qt4 an issue?
> >
> > Qt is not an issue as far as I can tell (and probably it shouldn't be mentioned :) ).
>
> A comment by Georg Zotti (ibidem, 2014-07-19) says that "it was a terrible
> struggle to get over the QT5 barrier, and the struggle is not over IMHO".
> So maybe there are enough rough edges in 0.13.0 to make people want to
> stick with 0.12.4 until 0.13.1 is out? (Is the jessie freeze date poorly
> aligned with Stellarium's release schedule?)
I don't think there is anything wrong with 0.13.0 from the user pov.
>
> > It seems that Qt5 requires only OpenGL 1.3
> > (http://qt-project.org/wiki/Qt-5-on-Windows-ANGLE-and-OpenGL), but if Alexander could
> > confirm this for me...
>
> That's not my reading of that page. The Qt OpenGL module requires OpenGL 1.3
> but is now deprecated in favor of the Qt GUI module (see the warning in
> http://qt-project.org/doc/qt-5/qtopengl-index.html) which has stricter
> requirements. The question is whether Stellarium has started that transition.
I think that the transition is done (judged by use of QOpenGLFunctions, QOpenGLContext,
QOpenGLShaderProgram, etc., which are available since Qt5.0). However I don't see
why requirements are "stricter" in any way. I don't think that our problem
has to do with Qt version actually.
>
> > > > I'm looking for a healthy discussion if we want such a package in jessie,
>
> See my points above. Maybe in jessie but no further?
I think that the only reasonable policy is to put a limit on supported
OpenGL implementations and keep with it.
>
> > > If even upstream sees the need to support older opengl versions: maybe
> > > they could do so in their current development? Maybe as a configuration
> > > option? Then, there would be only one code base, and the -legacy package
> > > would not be decoupled from the main development branch.
> >
> > Alexander should comment on this, but I'll put forward my point of view.
> > As mentioned, 0.12.4 is EOL, they are not going to develop it anymore.
> > s-legacy would be there only to provide stellarium for older machines
> > that will be unable to run newer versions. It would never ever advance
> > its version.
> > It would be great if 0.13.0 could support older hardware and we would
> > have one stellarium package in the archive. I have no idea what development
> > effort it would require, but since stellarium-legacy was proposed, I guess
> > it may be unfeasible.
>
> In the long run they may have no choice but to migrate away from deprecated
> Qt features. The only question would be one of timing.
Again, I don't think this is Qt issue.
>
> > There is another solution, which I don't quite like, but must mention:
> > we could ship 0.12.4 instead of 0.13.0 with jessie for the purpose of
> > keeping support for older machines.
>
> Does 0.13.0 have RC bugs? If not, it seems silly to deprive those users
> who *can* run it of the option to do so and enjoy the new features.
By the same reasoning there is no reason to not update stable packages
with bug-free packages from testing, yet we don't do it.
But I agree, my understanding is that stable should be a snapshot of
the newest software at the moment of the freeze.
Also we should probably estimate the volume of possible users that would
be harmed by having 0.13.x in stable. Alex, can you do any kind of estimation
based on bugs, development process, etc.? If there are no people who would
suffer from it, why even bother, right?
Cheers,
Tomasz
Reply to: