<div dir="ltr"><div>Not all projects get back-ported bug fixes.  Right now the copy of syslog-ng in epel gets back-ported bug fixes, I don't know very much about who maintains that though.<br></div><div><br></div><div>I think a good example of what you have in mind is what Oracle just did with the Java JDK - a new LTS release (currently JDK 11) will become available every three years but is supported for eight(ish?) years.  A new feature release will become available every six months, I don't believe fixes are back-ported.<br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 11:13 AM Evan Rempel <<a href="mailto:erempel@uvic.ca">erempel@uvic.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF">
    <div class="gmail-m_7093337168929300605moz-cite-prefix">I don't have a versioning issue with
      versioned repos. After all, that is what all of the</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">OS repos are: Redhat 6, Sientific Linux
      7, Centos 8, Debian 9, Ubunto 16 etc.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">The issue I have with syslog-ng in
      specific is that once a new version comes out,</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">the previous version is abandoned. No
      bug fixes. No security fixes etc.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">This is NOT the same as the OS versions
      repos where bug fixes and security fixes</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">are continued within the repo.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">What is being suggested in this thread
      is for major version repo to be created and</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">maintained in the long term support
      (LTS) role. Given the history of version numbers for</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">syslog-ng there is no clear major
      version transition. Syslog-ng3 (3.0 thorught 3.19)</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">has been changing, breaking and adding
      new features for nearly 6 years. That's</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">about 3 releases per year. Without some
      automated update process this is impossible to</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">keep up with for anything more that a
      handful of systems.<br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">Some thought as to designing a policy
      around when a new major version should be created</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">and supported the long term support and
      then automatic updates (not upgrades) would be possible</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">within that major version and its
      associated repo. A balance needs to be found between frequency</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">of releases and how many versions need
      to be supported. I would recommend only 1 release per</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">year that is supported. That would
      limit the number of supported versions to no more than 5.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">Possibly include an unsupported head
      for folks that absolutely need a latest feature before the</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">year it is released. That group can
      transition to the released version once it is released as a</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">supported version.</div>
    <br>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">With regards to the duration of the
      long term support, I think that 3 years is a little short.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">With a 3 year LTS cycle organizations
      that use syslog-ng would have to start the planning, testing</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">and approval process perhaps as
      frequently as every 2 years. Redhat basic support is 5 years</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">with extended support pushiing that out
      to 7 years. That cycle might be a little long and costly for the</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">vendor/community to support that long.</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">I would propose nothing shorter than 4
      years, so that customers can do the planning, testing, approval</div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">and upgrade process every 3 years at a
      minimum.<br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix"><br>
    </div>
    <div class="gmail-m_7093337168929300605moz-cite-prefix">On 3/29/19 6:23 AM, Nik Ambrosch wrote:<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">
        <div>Having a syslog-ng-latest repo to compliment the existing
          syslog-ng-317 versioned repos might be a good idea for people
          who use these builds for desktops and non-mission-critical
          applications.<br>
        </div>
        <div><br>
        </div>
        <div>I don't like surprises so I use the versioned repos and
          only change when there's a *need* to upgrade (new feature/fix
          listed in the changelog).</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 4:24
          AM Czanik, Péter <<a href="mailto:peter.czanik@balabit.com" target="_blank">peter.czanik@balabit.com</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
          <br>
          Here I offer my personal opinion about rolling releases, which
          differs<br>
          from the official Balabit opinion...<br>
          <br>
          When I first started my unofficial syslog-ng rpm packages a
          long time<br>
          ago in the galaxy, I had a single repository. When a new
          release came<br>
          out I packaged it into this repo. The feedback I received --
          and I<br>
          fully agreed as a practicing sysadmin -- that "don't do
          automagic<br>
          version updates for us, as it might break things". That's how<br>
          versioned repositories started. From the admin point of view
          an<br>
          automatic update is a risk, as even with thousands of
          automatic tests,<br>
          configurations can break. I recall quite a few breaking
          changes, some<br>
          intentional, some accidental. From this point of view things
          got just<br>
          worse when from yearly releases we changed to two months.
          Quite a few<br>
          places test new releases for more than two months before
          adding to<br>
          production...<br>
          <br>
          Here I fully agree with Evan, and this was also a feedback I
          often<br>
          received in private (unfortunately not on a public mailing
          list, blog<br>
          post or whatever), that continuous rolling is a major pain. To
          best<br>
          accommodate such users, there could be an LTS releases next to
          the<br>
          rolling, which receives fixes for critical problems. To avoid
          having<br>
          many parallel supported versions, we could align this with a
          major<br>
          release of Redhat, and keep that version supported for ~3
          years.<br>
          <br>
          In this case there could be a versioned repo for LTS releases:<br>
          syslog-ng4<br>
          syslog-ng5<br>
          etc.<br>
          And for those needing the latest features:<br>
          syslog-ng-rolling<br>
          Where people receive new feature releases automatically as
          they appear.<br>
          <br>
          Bye,<br>
          <br>
          Peter Czanik (CzP) <<a href="mailto:peter.czanik@balabit.com" target="_blank">peter.czanik@balabit.com</a>><br>
          Balabit (a OneIdentity company) / syslog-ng upstream<br>
          <a href="https://syslog-ng.com/community/" rel="noreferrer" target="_blank">https://syslog-ng.com/community/</a><br>
          <a href="https://twitter.com/PCzanik" rel="noreferrer" target="_blank">https://twitter.com/PCzanik</a><br>
          <br>
          On Thu, Mar 28, 2019 at 3:57 PM Evan Rempel <<a href="mailto:erempel@uvic.ca" target="_blank">erempel@uvic.ca</a>> wrote:<br>
          ><br>
          > The syslog-ng package maintainers and those deciding on
          version numbering need to decide on when backwards
          compatibility breaking occurs. IMO there is no reason to not
          upgrade to newer versions automatically (whatever schedule the
          client performs yum updates), with the one exception being
          updates that no longer work with a configuration file. Having
          an exact version number in the configuration file (@version
          3.17) is not useful if the configuration works with multiple
          releases. I would think<br>
          > that having a configuration version that remains the same
          for the same configuration syntax and semantcs would be more
          meaningful. Just thinking in public/out loud, perhaps all
          syslog-ng version 3.x use the same configuration syntax, then
          the @version would be 3, and when the config syntax is no
          longer backwards compatible, a new package name and @version
          is produced. This means that package NAMES would need to
          contain the major version number "syslog-ng-3" so that you do
          NOT get automatic<br>
          > updates to "syslog-ng-4".<br>
          ><br>
          > The down side for this is that syslog-ng-3 would need to
          be security fixed along side the syslog-ng-4 package for some
          support period and then finally deprecated in favour of the
          newer syslog-ng-4 package.<br>
          ><br>
          > I find that the postgresql community has done this very
          well. They make a major version release once per year which is
          how they introduce new features. They provide security fixes
          (and most bug fixes) for a period of 5 years. That means that
          at any given time they are supporting 5 major releases.
          Because this is a published schedule, installations are
          guaranteed to be supported/patched for 5 years, which falls
          into line with vendor OS support models quite well and
          provides the postgresql<br>
          > community the ability to make backwards breaking changes
          every year.<br>
          ><br>
          > For enterprise environments similar to what Mark
          describes below, it is critical that installed packages don't
          become abandoned with regards to patches. New features are not
          required to be added automatically, but security and bug fixes
          are. Some way to get security and bug fixes automatically
          without breaking compatibility over a long time preriod (3-5
          years) is what is needed to ensure stability, security and
          maintainability in an enterprise environment.<br>
          ><br>
          > Our company suffers from these requirements which are
          made that much more difficult by packaging decisions like what
          syslog-ng has decided on. Don't think  I am picking on
          syslog-ng. elasticsearch and oracle java suffer from this too.
          I am just trying to make the syslog-ng package as awesome as
          the syslong-ng program!<br>
          ><br>
          > I am free for further discussing if the package
          maintainers want to reach out.<br>
          ><br>
          > Evan Rempel<br>
          ><br>
          > On 3/28/19 6:43 AM, Faine, Mark R. (MSFC-IS40)[NICS]
          wrote:<br>
          > > You can easily version lock a package in Redhat
          (don’t know about SUSE, but I’d imagine so)  There is no need
          for a separate repository.  It makes more sense for the
          default to be the latest release and for locking to a specific
          release to be the exception.  It would probably even be easier
          for him to manage.<br>
          > ><br>
          > > The Redhat version is very old (3.2.5), so I’d
          rather not use it but not having a repo that tracks with the
          latest release breaks my installation process and means that I
          need a few separate tasks just for syslog-ng.<br>
          > ><br>
          > > If there is an update, I’ll have to remove the repo,
          add the new repo, then upgrade.  Instead of just doing a yum
          update.  I usually patch secondary servers first and then a
          few weeks later the primary or production servers, I think
          that would be enough warning if there were any breaking
          changes.<br>
          > ><br>
          > > Hopefully, if he is going to choose not to provide a
          repo with the latest release, I hope he is at least
          standardizing the naming convention and URLs so that I can
          automate the process, even so my problem is that it would
          still be a manual process, at least partially, since I’ll have
          to keep track of when a new version is released and update my
          configuration accordingly.  Manual processes such as this
          increase the potential for oversight which could allow a
          security vulnerability to slip through.<br>
          > ><br>
          > > I don’t know how many security vulnerabilities
          typically occur with syslog-ng but I know that it’s a big deal
          here and we are constantly pushed to keep systems up-to-date. 
          If there is some random high profile security vulnerability
          found on my system, I don’t want to be called out for having
          out-of-date software from a third-party repo.  I know it’s not
          fair but that’s the way they’ll frame it.<br>
          > ><br>
          > > In the end, I might be forced to use the Redhat
          version in the optional rpms repo, though since I’ve been
          working with 3.18, it’s possible that there may be things in
          my configuration that aren’t even compatible with that
          version. The thing is, they’d rather I use the old version
          that is, at least allegedly, supported by Redhat, than a
          newer, arguably more secure, and more performant version.
          Their reasoning breaks down to nothing more than CYA.<br>
          > ><br>
          > > I guess my point is that I’d hoped to argue for
          getting to use the czanik packages for the reasons I’ve
          mentioned and knowing already it would be an uphill battle but
          if they get a whiff of how the repos are structured it will
          make it even harder to justify, perhaps impossible.<br>
          > ><br>
          > > Thanks,<br>
          > > -Mark<br>
          > ><br>
          > > From: syslog-ng <<a href="mailto:syslog-ng-bounces@lists.balabit.hu" target="_blank">syslog-ng-bounces@lists.balabit.hu</a>>
          On Behalf Of Péter, Kókai<br>
          > > Sent: Thursday, March 28, 2019 4:16 AM<br>
          > > To: Syslog-ng users' and developers' mailing list
          <<a href="mailto:syslog-ng@lists.balabit.hu" target="_blank">syslog-ng@lists.balabit.hu</a>><br>
          > > Subject: Re: [syslog-ng] Redhat repo<br>
          > ><br>
          > > Hello,<br>
          > ><br>
          > > I've just spoke with Czanik Peter - the maintainer
          of those repositories.<br>
          > ><br>
          > > He said that initially there was one repo having the
          latest released, but majority of the user want to control when
          to upgrade to a newer version from both RHEL and SUSE side.<br>
          > > (I guess it is an *easy* way to prevent accidental
          updates.)<br>
          > > Also he said that there was not much demand for such
          structured repository since the shift (only 1-2 person).<br>
          > ><br>
          > ><br>
          > ><br>
          > > --<br>
          > > Kokan<br>
          > ><br>
          > > On Wed, Mar 27, 2019 at 3:40 PM Faine, Mark R.
          (MSFC-IS40)[NICS] <mailto:<a href="mailto:mark.faine@nasa.gov" target="_blank">mark.faine@nasa.gov</a>> wrote:<br>
          > > I have a question about the Redhat repo for the
          unofficial OSE builds.  It seems as though they are tied to a
          specific version.  For example, I'm currently using
          czanik-syslog-ng318epel6, however, I see that 3.19 has a
          different repo specifically for that version.  This seems to
          be counter to the point of yum repositories and it imposes an
          additional maintenance burden.  Am I maybe not properly
          understanding how it works, and if not, is there a repo that
          tracks with the latest stable version?<br>
          > ><br>
          > > -Mark<br>
          > ></blockquote>
      </div>
    </blockquote>
    <br>
  </div>

______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" rel="noreferrer" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" rel="noreferrer" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.balabit.com/wiki/syslog-ng-faq" rel="noreferrer" target="_blank">http://www.balabit.com/wiki/syslog-ng-faq</a><br>
<br>
</blockquote></div>