kicad-developers team mailing list archive

[Mark Roszko <mark.roszko@xxxxxxxxx>]

>  I was not aware that this attitude has changed.

Well it's just the way I see it, heck I may be wrong but it isn't really an
attitude as much as upstreams wanting to continuously deliver the latest
versions without distro repo politics. In some cases, there are both distro
and official upstream releases.

On Wed, Oct 23, 2019 at 12:43 PM Wayne Stambaugh <stambaughw@xxxxxxxxx>
wrote:

> On 10/23/2019 10:52 AM, Mark Roszko wrote:
> > Can there ever be a statement written somewhere that says "KiCad strives
> > to support Ubuntu LTS Latest and Previous, Debian Latest, etc"?
> > Basically defining what is considered "older Linux distros" vs
> "supported".
>
> This is always going to be an issue but I think we can do a better job
> of defining which distros we support.  AFAIK, the stable version
> currently builds on all of the Linux distros listed.  We just need to be
> clear that this only applies to the current stable release and that
> development branch may not build.
>
> >
> > KiCad is unique in not building linux packages directly compared to most
> > other major pieces of software so that line has never been defined
> clearly.
>
> I thought most Linux distros packaged software in accordance with the
> preferred packaging requirements for each distro.  It used to be the
> case that distros frowned upon externally build packages because there
> was always the distinct possibly that they would break something in ways
> that were difficult to resolve.  I was not aware that this attitude has
> changed.  Too be honest, I would rather the distros build KiCad
> according to their requirements.  I would think the manpower for us to
> provide packages for every linux distro would be overwhelming.
>
> >
> > On Wed, Oct 23, 2019 at 9:28 AM Wayne Stambaugh <stambaughw@xxxxxxxxx
> > <mailto:stambaughw@xxxxxxxxx>> wrote:
> >
> >     One thing we don't specify on the system requirements page on the
> KiCad
> >     website is whether or not this applies to the current stable release
> or
> >     the nightly builds.  Since we don't specify this, I can see how users
> >     would assume that it's all versions of KiCad.  Perhaps we should note
> >     that this is only applicable to the current stable version and that
> >     nightly builds may not support older Linux distributions due to the
> >     availability of dependency library versions.  I don't think it's
> >     reasonable to expect the latest development version of KiCad to
> continue
> >     to support legacy Linux distros.  The current LTS release of Ubuntu
> is
> >     18.04 which supports boost version 1.65.  I think attempting to
> support
> >     nightly builds on Ubuntu 16.04 is going to continue cause headaches
> as
> >     time goes on.  If no one objects, I will update the system
> requirements
> >     page accordingly.
> >
> >     Cheers,
> >
> >     Wayne
> >
> >     On 10/23/2019 1:39 AM, Eeli Kaikkonen wrote:
> >     > It should also be noted that 20.04 will be the next LTS release of
> >     > Ubuntu. This means that there will be two post-16.04 LTS releases
> out
> >     > there before KiCad 6 will be released (I'm not *that* optimistic
> :) ).
> >     > Is it really worth it to actively support 3 different LTS
> releases? It
> >     > doesn't sound very realistic. How many users would actually be
> >     affected
> >     > if KiCad 6 wouldn't be available for 16.04? 1000s? 100s? 10? And
> >     if they
> >     > continue with 16.04 until 2021, why would they need to switch to
> >     KiCad 6
> >     > before that?
> >     >
> >     > Eeli Kaikkonen
> >     >
> >     > ke 23. lokak. 2019 klo 3.05 Seth Hillbrand (seth@xxxxxxxxxxxxx
> >     <mailto:seth@xxxxxxxxxxxxx>
> >     > <mailto:seth@xxxxxxxxxxxxx <mailto:seth@xxxxxxxxxxxxx>>)
> kirjoitti:
> >     >
> >     >     On 2019-10-22 16:06, Ian McInerney wrote:
> >     >
> >     >>     I dug into the website history and apparently the original
> intent
> >     >>     should have been to support 16.04 LTS until its standard
> support
> >     >>     ends in 2021
> >     >>
> >      (
> https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782
> ).
> >     >>     Since we haven't actually used any code from the newer Boost
> >     >>     version (that we weren't already using), we should probably
> back
> >     >>     out the change and also update the website with the correct
> >     Ubuntu
> >     >>     LTS support date. It looks like that will make it so we can't
> >     >>     update to 1.59 until 2021 then.
> >     >>
> >     >
> >     >     Hi Ian-
> >     >
> >     >     I did write that.  In retrospect, I'm not sure that the
> >     sentiment is
> >     >     correct.  One of the things we are attempting to do is focus
> our
> >     >     primary efforts where they will have the largest impact for our
> >     >     users.  Toward that end, we were attempting (in the post KiCon
> >     >     meeting) to define where that cut off should be.  We kind of
> >     >     arbitrary picked "vendor supported" as it seemed reasonable.
> >     >
> >     >     I now think we should tighten that a bit more for the Linux
> >     >     distributions.  Under MSW/Mac, we compile or have rolling
> updates
> >     >     for most of our own dependencies.  This allows us to ensure
> system
> >     >     compatibility but not worry about library compatibility.  The
> >     Linux
> >     >     library system is different and holds back updates.
> >     >
> >     >     So, why would we want to update the boost libraries and what
> >     does it
> >     >     gain us?  The original bump was to allow unit tests.  During
> v6, I
> >     >     would also like to utilize the UUID library from 1.60 as many
> >     of the
> >     >     feature we plan will require GUID at least.
> >     >
> >     >     This doesn't preclude using KiCad on 16.04.  It just requires
> >     >     someone to package a boost ppa.  There are a few out there that
> >     >     could be used as baselines for this.
> >     >
> >     >     -Seth
> >     >
> >     >
> >     >     KiCad Services Corporation KiCad Services Corporation Logo
> >     >     Seth Hillbrand
> >     >     *Lead Developer*
> >     >     +1-530-302-5483‬ <tel:+12126039372>
> >     >     Davis, CA
> >     >     www.kipro-pcb.com <http://www.kipro-pcb.com>
> >     <http://www.kipro-pcb.com/>    info@xxxxxxxxxxxxx
> >     <mailto:info@xxxxxxxxxxxxx>
> >     >     <mailto:info@xxxxxxxxxxxxx <mailto:info@xxxxxxxxxxxxx>>
> >     >     https://twitter.com/KiProEDA <https://twitter.com/KiProEDA>
> >     >     https://www.linkedin.com/company/kicad
> >     >     <https://www.linkedin.com/company/kicad>
> >     >
> >     >     _______________________________________________
> >     >     Mailing list: https://launchpad.net/~kicad-developers
> >     >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>>
> >     >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     >     More help   : https://help.launchpad.net/ListHelp
> >     >
> >     >
> >     > _______________________________________________
> >     > Mailing list: https://launchpad.net/~kicad-developers
> >     > Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     > Unsubscribe : https://launchpad.net/~kicad-developers
> >     > More help   : https://help.launchpad.net/ListHelp
> >     >
> >
> >     _______________________________________________
> >     Mailing list: https://launchpad.net/~kicad-developers
> >     Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> >     <mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~kicad-developers
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
> >
> > --
> > Mark
>


-- 
Mark