Re: [Flightgear-devel] Next, for development (and not much else)

[Gaétan A. <gae...@be...>]

Hi All,

I agree wit Scott, 'next' should be able to compile, pass the
non-regression tests and run/be usable with the standard options (not
with new functionalities under heavy development). Works can be
incomplete on 'next' but should not break the rest of the simulator. By
experience, a broken system during a few days/weeks is bad because some
complex bugs may have been introduced unnoticed during this period.
Bugs should be spotted and fix as quick as possible even on 'next' (I
don't have a lot a fun with git bisect)

When we start to develop for a new major release (LTS), we should
reconsider the version of each distro that we want to support. For
example, be compatible for the 'next' release with Ubuntu 16.04 is
useless because Ubuntu 16.04 will be out of support when the release
will be created (2022 in this case).

- Ubuntu 20.04: C++17, OSG 3.6
- Ubuntu 18.04: C++17, OSG 3.4 (not sure about this distro because end
  of support 2023)
- Debian 10: C++17, OSG 3.4
- CentOS 8: C++17, OSG not provided
- Linux Mint 20: C++17, OSG 3.6
- Linux Mint 19.3: C++17, OSG 3.4 (not sure about this distro because
  end of support 2023)

I have 1 concern about C++17. OpenRTI (HLA support) is full of auto_ptr
that has been removed in C++17. Do we still want to support HLA?
OpenRTI can not be changed because it has to stick with the HLA
standard (still on C++98).

Should not be the beginning of a release a good time to do some major
housekeeping? Examples:
- remove compiler warnings,
- replace virtual methods with override methods,
- code indentation (tabs removal). It is really difficult to read some
  part of our code if you don't have the expected editor with the
  correct settings,
- remove C-style casting,
- remove static cast where possible using templates
  (for example simgear::canvas::Group::createChild,
  SGSubsystemGroup::get_subsystem),
- remove unused or duplicated #include,
- replace old C++ code with newer C++ code (for example
  replace std::enable_if with std::enable_if_t, replace typedef with
  using, #define with const, boost:: with std::).

I'm still working on the replacement of the 2D panel by canvas.

Cheers,

On Sat, 20 Jun 2020 10:08:44 -0500
Scott <sc...@gm...> wrote:

> My rules:
> 
> - Next must always compile.  If it does not, then development shuts
> down.
> 
> - The sim must remain usable.  If I introduce a change that prevents 
> making it beyond the splash screen, then that shuts down
> development.  I don't check it into Next until I've resolved that
> issue.  Use a feature branch if things may be broken for several
> days.  Merge that into Next once it is usable again.  Don't forget to
> delete the feature branch once it becomes obsolete.
> 
> - If I introduce a shader change that makes runways blue - no big
> deal to make this change directly to Next.  It's a work in progress,
> but still usable.
> 
> - Follow James lead by communicating your intent for big changes.
> Keeps everyone informed.
> 
> Scott
> 
> 
> On 6/20/20 9:43 AM, Dany wrote:
> >
> >
> > On 20/06/2020 at 12:58, James Turner wrote :  
> >>  
> >>> On 20 Jun 2020, at 11:51, Erik Hofman <er...@eh... 
> >>> <mailto:er...@eh...>> wrote:
> >>>
> >>> I know but the difference is between telling a dozen developers
> >>> to switch to branch X or asking a few thousand users to leave
> >>> branch next alone.  
> >>
> >>
> >> Hmm, I had not considered the idea that it’s thousands, do you
> >> really think it is so large?
> >>  
> >
> > Many people use 'next' because under Linux they have no good
> > solution other than compiling. The FG version by the distros are
> > often old and sometimes buggy. Like are many pre-compiled versions
> > built on another system. The local compilation is generally the
> > best way.
> >
> > They are naturally oriented to download_and compile. Which results
> > in non-developers using 'next', the version given by default when
> > running d&c. Although the stable version can easily be obtained by
> > d&c, but it is a bit old.
> >
> > Also, intermediate people (aircraft developers, not knowing C++)
> > often need a recent FG version (would it be only for compatibility
> > with collaborators).
> >
> > If I read well what you are writing, you'd prefer if d&c would give 
> > the last 'release' version (for those who would like something more 
> > recent than the stable version).
> >
> > Kind regards,
> >
> > Dany
> >
> >
> >
> >
> > _______________________________________________
> > Flightgear-devel mailing list
> > Fli...@li...
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel  



-- 
          \||/ There are only 10 kinds of people:
         /~ ~\ -Those who understand binary
         |@ @| -Those who don't
|-oooO----(_)---Oooo---------------------------------------|
 Gaétan Allaert

Key server : https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event
Key ID : 55472127