<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Without arguing specific packages, my actual observation is that
      there are certain types of software that are resistant to the
      concept of a "release". And when you have beautifully curated
      releases -- like Debian does occasionally, and Ubuntu does on
      schedule -- and a written policy like the SRU policy cited below,
      it makes a lot of sense to exclude such software from your
      released repos. The number of exceptions within the SRU document
      points to a systemic issue that would be best not to address
      haphazardly, IMHO.</p>
    <p>That said, there are a number of enterprise goals which result in
      this sort of software being included with every version of Debian
      or Ubuntu. People want a browser. People want malware scanners and
      security auditors. People want drivers. People want to use current
      standards, codecs, cyphers.....and these are developed on a
      schedule outside the control of Debian or Ubuntu. How can Ubuntu
      be held to LTS this sort of package? Do the good people at Debian
      or Ubuntu want to be left "holding the bag" when an item in their
      repo ceases to function during the support period?</p>
    <p>There is a certain element of culture that comes into play as
      well. How many times have you sought customer service for a
      consumer product and been asked, "do you have the current model?"
      What happens with a larger software package or suite when they ask
      that question and you reply, "but I used the version in the LTS
      repo!" Whether it's appliances, automobiles, software, or
      mass-media, nobody wants to take responsibility for the
      past......and they'll barely take care of the now. LTS releases
      are welcome islands in a sea of flux.<br>
    </p>
    I realize that some of these observations and questions dovetail
    into discussions regarding snap or Docker images. As an alternative,
    each distro might have an extra repository that doesn't do releases
    -- "Ubuntu UnReleased" or something -- where you do limited
    procedures for compatibility (e.g. recompile with Ubuntu-preferred
    compiler flags), but specifically disclaim that it will be
    maintained by anyone but the developers (Essentially separating each
    "release" into a curated section and a rolling current section.).
    Again, I look to the method that Ubuntu Studio is using. <br>
    <p>I do want to thank Gunnar for his initial reply and kind
      suggestions -- one of which I will likely implement shortly. But I
      wanted to return a kindness for a kindness, and I could see a
      grave systemic issue being dealt with as individual problems.....I
      believe that you will soon be forced into creating a systemic
      solution, because the issue isn't going away -- and, in fact, the
      problems are getting worse as the flow of problems accelerates.
      Accordingly, the earlier you address the issue, get it understood,
      and undertake systemic reforms to have it addressed, the better
      everyone's lives will be.</p>
    <p>c</p>
    <p>P.S. -- one of the many joys of Linux is that one can accumulate
      tools for specific use-cases, rather than trying to pretend
      everything is a nail for one's hammer. Brave is not my
      "daily-driver" as a browser -- which is a thoroughly up-armored
      Firefox that breaks about 30% of the sites I visit. But there are
      times when I find Brave useful to have around. It's currently
      implemented via a ppa (the mechanism of which is, BTW, another
      data-point for my thesis). I think it would be great to have
      minimally-screened versions of all major browsers available in a
      single, secure repo.<br>
    </p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 3/7/21 8:45 PM, Zack Coffey wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAA8KC9+Ce317qKgVKtUr2dWBB+nfJzwgnfVEBcByUVBb+033Rg@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">If I get a vote, it would be a solid NO for Brave. 
        <div><br>
        </div>
        <div>The idea that a browser is using cryptocurrency to bait
          users, behaviour tracking, serving ads while saying it's
          blocking ads, changing referrer URLs to their own, and
          encourages users to nag website owners to sign up for Braves
          BAT system and have agreements with them... does not suit
          Ubuntu. </div>
        <div><br>
        </div>
        <div>Honestly Brave is pretty much the opposite of what they say
          they are. They are a company, taking open source Chromium and
          making money off users. I do not support that and no distro
          should.</div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Sun, Mar 7, 2021 at 5:42 PM
          Franklin Hunter <<a href="mailto:tiedyedbun@gmail.com"
            moz-do-not-send="true">tiedyedbun@gmail.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">The
          missing cc:<br>
          <br>
          On 3/7/21 5:55 AM, Gunnar Hjalmarsson wrote:<br>
          > Hi again, Franklin.<br>
          ><br>
          > I haven't read your whole answer yet. I certainly will.<br>
          ><br>
          > But I noticed that you replied to me only. Can you please
          send your <br>
          > reply to the mailing list too, so others can participate
          if they want.<br>
          ><br>
          > / Gunnar<br>
          ><br>
          ><br>
          > On 2021-03-07 11:20, Franklin Hunter wrote:<br>
          >> Hello, Gunnar.<br>
          >><br>
          >> For such a short reply, there was a lot for me to
          think about....in <br>
          >> both what you said, and what you cited.<br>
          >><br>
          >> My original email had also included:<br>
          >><br>
          >>     Is there an online form for this? I was reading
          info from "dpkg -s"<br>
          >>     and "apt-cache showpkg" , so I can't easily see
          if Debian has or<br>
          >>     hasn't rolled theirs. I'm thinking of something
          with visibility of<br>
          >>     whether Ubuntu is getting it from developers or
          Debian, and how much<br>
          >>     mucking is required to make it appropriate for
          Ubuntu.<br>
          >><br>
          >>     This is Linux, and we can always do a ppa or
          compile our own, but<br>
          >>     Ubuntu's package curation in its distros is
          highly valued and<br>
          >>     appreciated. It'd be nice if we could see where
          more or less of that<br>
          >>     curation might be necessary.<br>
          >><br>
          >> I understood that there must be some policy for
          stable release <br>
          >> updates, because the Ubuntu project is known for its
          quality -- and <br>
          >> such a policy is necessary for consistent quality.
          After having read <br>
          >> the policy, however, I can see where some disconnects
          between the <br>
          >> policy and user expectations may be inevitable.<br>
          >><br>
          >> Let's start out with the easy stuff.....<br>
          >><br>
          >> You say:<br>
          >><br>
          >>     At the same time I know that youtube-dl upstream
          is updated<br>
          >>     frequently, and that it's a pain to try use
          anything but the latest<br>
          >>     upstream. IMO there are reasons to question why
          it's present in the<br>
          >>     Debian/Ubuntu archives at all.<br>
          >><br>
          >> Now that I've read the policy, I fully agree. The
          package youtube-dl <br>
          >> should not be in a repository under the current SRU
          policy. The <br>
          >> policy also notes various environmental exceptions in
          section 2.1, <br>
          >> particularly the fourth bullet point. Environmental
          circumstances are <br>
          >> also listed in sections 9.11, 9.23, 10.1 and, to a
          certain extent, <br>
          >> section 12. [Very likely, more sections of 9 would
          apply, but I'm not <br>
          >> sufficiently familiar with them.] Lynis should also
          not be in a <br>
          >> repository under current SRU policy.<br>
          >><br>
          >> Now might be a good time to reflect on what a policy
          is supposed to <br>
          >> be.... A policy should be a _framework of action_ to
          further <br>
          >> _enterprise goals_. The SRU policy is to further the
          enterprise goal <br>
          >> to provide releases (particularly LTS releases) that
          are rock-solid, <br>
          >> of the highest quality, and maintain functionality
          for the entire <br>
          >> support period. Packages are chosen to support this
          goal, and <br>
          >> supported (within SRU) towards this end.<br>
          >><br>
          >> Packages such as youtube-dl, all browsers, time zone
          data, and clamav <br>
          >> definitions (and lynis) _cannot_ fit within this
          definition. Rather <br>
          >> than individually carve them out, it should be
          recognized that a <br>
          >> different class of package is out there -- one that
          neither Ubuntu <br>
          >> nor Debian really control. They may be involved in an
          armaments race <br>
          >> (as various malware v. malware detectors and
          preventions) or in a <br>
          >> standards race, or in a race to keep up with
          political malfeasance <br>
          >> (tzdata). Why not recognize them as a class and deal
          with them <br>
          >> efficiently?<br>
          >><br>
          >> So, what are other enterprise goals? The impulse to
          include lynis, <br>
          >> youtube-dl, browsers, and other packages within a
          distro is driven by <br>
          >> a desire to be "complete" and "competitive" and be
          useful "as <br>
          >> installed". Those are entirely valid goals for the
          enterprise. <br>
          >> Furthermore, a distro may want to be "cool" and
          "popular" in order to <br>
          >> increase market share and/or support. It may also be
          that user's <br>
          >> expectations are that Ubuntu (or Debian) provide a
          "complete Linux <br>
          >> environment" that can be compared to other current
          Linux distros, and <br>
          >> provide immediate bragging rights over those who
          cling to Microserfdom.<br>
          >><br>
          >> These are all worthy goals for an enterprise that
          wants to survive -- <br>
          >> though some purists may consider them crass. But
          where is the policy <br>
          >> for these goals? It struck me, while reading through
          the SRU policy, <br>
          >> that it was unclear where functionality suggestions
          might <br>
          >> originate.....but it didn't look like there was any
          room for user input.<br>
          >><br>
          >> In light of current realities, I would suggest that
          there be a <br>
          >> further division of Ubuntu repositories for packages
          that users might <br>
          >> otherwise ppa, reviewed at a lesser level than would
          be appropriate <br>
          >> for other repositories, to achieve the enterprise
          goal of "complete <br>
          >> Linux environment" and useful "as installed". I
          should note that <br>
          >> something similar is done with Ubuntu Studio. All
          browsers probably <br>
          >> belong in this repo, as well as youtube-dl and
          security packages. <br>
          >> These packages stand or fall on their own, and (to
          protect the core) <br>
          >> they have been tested to not crash core
          functionality. This would, <br>
          >> BTW, make you one of the first distros to officially
          include Brave <br>
          >> and clarify your relationship with Tor.<br>
          >><br>
          >> Incidentally, if you adopt any of this, please credit
          to "cthulhu" so <br>
          >> I can include on my resume. "Franklin Hunter" is
          synthetic.<br>
          >><br>
          >> Second, you should have an online form for requested
          updates, and a <br>
          >> public-facing database for tracking them. Note that I
          am not <br>
          >> suggesting what you do with them......because that
          should evolve as <br>
          >> data accumulates.<br>
          >><br>
          >> Third, you should monitor tools such as <a
            href="https://repology.org/" rel="noreferrer"
            target="_blank" moz-do-not-send="true">https://repology.org/</a>
          to see <br>
          >> how the freshness of your packages compare to other
          distros.<br>
          >><br>
          >> Fourth, the SRU policy is currently written for
          maintainers, but <br>
          >> fails to reference either enterprise goals or user
          expectations. It <br>
          >> might correctly function in that manner, but it
          cannot be optimized <br>
          >> as long as the goals and expectations are not
          explicitly linked [In <br>
          >> real life, I'm a CPA with extensive experience with
          internal audit.]. <br>
          >> Each section should start with the corporate goal and
          end with the <br>
          >> benefit to the consumer. Maintainers will also get
          less grief and <br>
          >> more joy if they can say, "I'm doing 3.25 to further
          corporate goal X <br>
          >> and consumer benefit Y" instead of "I'm doing 3.25
          because it's the <br>
          >> rule."<br>
          >><br>
          >> Thank you, again, Gunnar Hjalmarsson, for a peek
          inside a structure <br>
          >> that I appreciate and applaud. I hope that it only
          gets better from <br>
          >> here.<br>
          >><br>
          >> Cooth<br>
          >><br>
          >> On 3/6/21 4:19 PM, Gunnar Hjalmarsson wrote:<br>
          >>> Hi Franklin,<br>
          >>><br>
          >>> On 2021-03-05 07:45, Franklin Hunter wrote:<br>
          >>>> The version in focal is 2020.03.24-1 .<br>
          >>>><br>
          >>>> The developer is at 2021.03.03.<br>
          >>>><br>
          >>>> Can it get freshened?<br>
          >>><br>
          >>> It can't be updated easily given Ubuntu's policy
          for stable release <br>
          >>> updates.<br>
          >>><br>
          >>> <a
            href="https://wiki.ubuntu.com/StableReleaseUpdates"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://wiki.ubuntu.com/StableReleaseUpdates</a><br>
          >>><br>
          >>> At the same time I know that youtube-dl upstream
          is updated <br>
          >>> frequently, and that it's a pain to try use
          anything but the latest <br>
          >>> upstream. IMO there are reasons to question why
          it's present in the <br>
          >>> Debian/Ubuntu archives at all.<br>
          >>><br>
          >>> There are two much better options:<br>
          >>><br>
          >>> 1. Install it as a snap (the latest/edge
          channel).<br>
          >>><br>
          >>> 2. Install it from upstream:<br>
          >>><br>
          >>> <a
            href="https://github.com/ytdl-org/youtube-dl#installation"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/ytdl-org/youtube-dl#installation</a><br>
          >>><br>
          ><br>
          ><br>
          <br>
          -- <br>
          Ubuntu-devel-discuss mailing list<br>
          <a href="mailto:Ubuntu-devel-discuss@lists.ubuntu.com"
            target="_blank" moz-do-not-send="true">Ubuntu-devel-discuss@lists.ubuntu.com</a><br>
          Modify settings or unsubscribe at: <a
            href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss"
            rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>