kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

All of your arguments are valid.  For me personally,  I'm fine with
enabling everything that's ready for release since I build from source
and it's not an issue on any of the platforms I use for development.  If
that is the consensus, then I will enable them.  I'm just trying to be
fair to our package devs.

On 12/27/2017 05:42 PM, Nick Østergaard wrote:
> 2017-12-27 23:04 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx
> <mailto:stambaughw@xxxxxxxxx>>:
> 
>     Here are my thoughts on the current options that are disable be default.
>      Nothing is experimental except USE_WX_GRAPHICS_CONTEXT which really
>     shouldn't be used and the WX_OVERLAY which is macos specific.
> 
>     KICAD_SCRIPTING, I'm fine with setting this to ON now that we have a
>     sane solution for Python scripting on windows.  All other platforms
>     should have python 2 support for the foreseeable future.
> 
>     KICAD_SCRIPTING_MODULES, this can be enabled as well sense it goes hand
>     in hand with KICAD_SCRIPTING.
> 
>     KICAD_SCRIPTING_WXPYTHON, this is not as clear cut as it would seem.
>     Sometimes the wxPython build gets out of sync with the wxWidgets builds
>     on certain platforms which is known to cause issues.  Enabling this
>     could cause issues for package devs.
> 
> 
> It will also if they enable it explicitly... On multiple platforms this
> ABI check between wx and wxpython is not marked as fatal and only
> servers as a hint that you should poke the maintainers to rebuild
> wxpython. For some reason they seems to remember to rebuild wx when the
> compiler gets updated but not wxpython. But they should really do it,
> there is no reason no to.
>  
> 
> 
>     KICAD_SCRIPTING_ACTION_MENU AFAIK depends on KICAD_SCRIPTING_WXPYTHON so
>     enabling this will dependent upon enabling KICAD_SCRIPTING_WXPYTHON.
> 
> 
> And then what? The packager can still disable those options if he needs
> to. IMHO it is better that the packager does not need to explicitly
> enable any options to get a kicad build configuration that we advertise
> as working features. All those features do work on all the three major
> platforms. Linux, windows and macos.
>  
> 
> 
>     KICAD_USE_OCE, I'm not so comfortable enabling this by default due to
>     issues between version of OCE.  It might be best if this is left up to
>     the package devs.
> 
> 
> What issues are we talking about here? If we never enable it we will not
> discover the issue as quickly as we could. We are not removing control
> from the packager here. He can still disable the option if it causes him
> any isses.
>  
> 
> 
>     KICAD_USE_SPICE, I'm not comfortable enabling this due to the fact that
>     some linux packages of ngspice do not build with --libngspice enabled
>     which will cause build config issues.  I would to default to the package
>     devs to enable this as necessary.
> 
> 
> This is the issue of the packager on that system. If he is lazy he can
> start by disabling this option untill he gets time to fix his platforms
> ngspice package. It should be good now that a release of ngspice have
> been made that has our required fixes. If the ngspice people did not
> make that release I would be okay with having it off by default.
>  
> 
> 
>     On 12/09/2017 11:46 AM, Kristoffer Ödmark wrote:
>     > I think that this message is important, and I feel a decision on this
>     > matter features has to be done by the project manager, basically
>     give a
>     > pointer to what should be used to as far extent as possible.
>     >
>     > Wayne, this is a package dev that wants to know this and while I
>     do not
>     > know who are package devs, the only package dev has expressed a
>     need for
>     > this decision. Please dont just ignore it.
>     >
>     > And yes, the coming patch submissions is dependent on what
>     features are
>     > deemed "standard"
>     >
>     >  -Kristoffer
>     >
>     > On 12/07/2017 08:58 PM, Simon Richter wrote:
>     >> Hi,
>     >>
>     >> On 07.12.2017 19:08, Wayne Stambaugh wrote:
>     >>
>     >>> Yes, that is exactly what I'm saying.  it is possible kicad
>     could have
>     >>> different feature sets depending on the availability of
>     dependencies on
>     >>> the target platform.  The kicad project has no control over
>     this.  If a
>     >>> platform doesn't have dependency support for spice, they can still
>     >>> provide a kicad package without spice support.  That's better
>     than no
>     >>> kicad.
>     >>
>     >> Right, but we still need to give some guidance on the status of
>     >> features. As it is now, new features are introduced as default-off
>     >> "experimental" stuff that is only to be used by a select few, then at
>     >> some point we enable it for nightlies, mostly driven by
>     availability of
>     >> dependencies and a vague feeling that features should be tested,
>     and at
>     >> some point the feature has become something that should have been
>     >> enabled by default a long time ago (but nobody can tell the exact
>     date
>     >> when).
>     >>
>     >> We need a bit of a process here to promote feature status, e.g.
>     >>
>     >> experimental    new stuff, not for general use
>     >> optional    => add to nightlies
>     >> standard    => enable by default
>     >> required    => remove option
>     >>
>     >> I think all the new features for v5 have reached "optional"
>     status, and
>     >> they have been enabled in nightlies as far as possible. The next
>     >> question is whether they are "standard" and should be part of the
>     stable
>     >> release, including questions by users and a commitment to file
>     >> compatibility. Probably yes, but this is a project management
>     decision
>     >> that will affect requirements for patch submissions in the next
>     release
>     >> cycle, so it needs to be an explicit decision.
>     >>
>     >>     Simon
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     >> Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     >> More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
>     >>
>     >
>     > _______________________________________________
>     > Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     > Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     > More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
> 
>     _______________________________________________
>     Mailing list: https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
>     Unsubscribe : https://launchpad.net/~kicad-developers
>     <https://launchpad.net/~kicad-developers>
>     More help   : https://help.launchpad.net/ListHelp
>     <https://help.launchpad.net/ListHelp>
> 
>