** Description changed:

  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic
  
  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security
  
  Last relevant related stable updates: 9.5.16, 10.7
  
  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz
  
  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665
  
  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.
  
  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. But this time there are changes worth to
    mention for the SRU team.
-   - change [1] is in all branches Xenil/Bionic/Cosmic and after 
-     coordinating with Debian and Upstream and some members of the SRU Team 
-     (Malta) and Debian we decided to revert this change in all releases 
-     that get SRUs (So 11.x in Disco is the only who will get it).
-     Users are either:
-     a) not affected at all and therefore are fine as-is (majority)
-     b) not affected by the problem but have tests/scripts/CI/... that
-        rely on the behavior (we don't want to SRU break them)
-     c) have a case that is affected, in that case the "code using 
-        client_min_messages" is the one to be considered broken (in favor 
-        of the majority of users) and that code should be changed in stead 
-        of postgres.
-     Furthermore with that decision we are also in sync with Debian 
-     handling the same
-  - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco), 
-    but not in Bionic/Cosmic as we'd break en external ABI of the past in 
-    an SRU
+   - change [1] is in all branches Xenil/Bionic/Cosmic and after
+     coordinating with Debian and Upstream and some members of the SRU Team
+     (Malta) and Debian we decided to revert this change in all releases
+     that get SRUs (So 11.x in Disco is the only who will get it).
+     If misused not having that fix could cause bad data.
+     But users of Ubuntu are either:
+     a) not affected at all and therefore are fine as-is (majority)
+     b) not affected by the problem but have tests/scripts/CI/... that
+        rely on the behavior (we don't want to SRU break them)
+     c) have a case that is affected, in that case the "code using
+        client_min_messages" is the one to be considered broken (in favor
+        of the majority of users) and that code should be changed instead
+        of PostgreSQL.
+     Furthermore with that decision we are also in sync with Debian
+     handling the same
+  - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
+    but not in Bionic/Cosmic as we'd break en external ABI of the past in
+    an SRU. Please Note that the offending plruby this change was made for 
+    is not even in the Archive.
+  => Especially in regard to "regression potential" that means that we will 
+     NOT apply the two changes that are somewhat discussion-worthy. We 
+     might in later updates reconsider them, but for now when applying the 
+     latest stable release we revert those two primarily for the reason to 
+     have the lowest possible regression potential for the SRU.
  
  Note: opening private as it is not yet announced
  Public announce will on thursday.
  
  [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
  [2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14

** Description changed:

  Current versions in supported releases:
   postgresql-9.3 | 9.3.23-0ubuntu0.14.04 trusty <- no upstream updates anymore
   postgresql-9.5 | 9.5.14-0ubuntu0.16.04 xenial
   postgresql-10 | 10.6-0ubuntu0.18.04.1 bionic
   postgresql-10 | 10.6-0ubuntu0.18.10.1 cosmic
  
  Special cases:
  - Disco will be synced from Debian soon (we are on 11.1-2)
  - This is again a security update, so we prep and security will eval and 
publish through -security
  
  Last relevant related stable updates: 9.5.16, 10.7
  
  So the todo is to pick:
  MRE: Xenial 9.5.14 from 
https://ftp.postgresql.org/pub/source/v9.5.16/postgresql-9.5.16.tar.gz
  MRE: Bionic/Cosmic 10.7   from 
https://ftp.postgresql.org/pub/source/v10.7/postgresql-10.7.tar.gz
  
  Standing MRE - Consider last updates as template:
  - pad.lv/1637236
  - pad.lv/1664478
  - pad.lv/1690730
  - pad.lv/1713979
  - pad.lv/1730661
  - pad.lv/1747676
  - pad.lv/1752271
  - pad.lv/1786938
  New - this bug
  - pad.lv/1815665
  
  As usual we test and prep from the PPA and then push through
  SRU/Security as applicable.
  
  Regression potential:
  - usually this works smoothly except a few test hickups that need to be
    clarified to be sure. But this time there are changes worth to
    mention for the SRU team.
    - change [1] is in all branches Xenil/Bionic/Cosmic and after
      coordinating with Debian and Upstream and some members of the SRU Team
      (Malta) and Debian we decided to revert this change in all releases
      that get SRUs (So 11.x in Disco is the only who will get it).
-     If misused not having that fix could cause bad data.
+     What makes this slightly more important is that: if 
+     client_min_messages is misused, then not having that fix
+     could cause bad data.
      But users of Ubuntu are either:
      a) not affected at all and therefore are fine as-is (majority)
      b) not affected by the problem but have tests/scripts/CI/... that
         rely on the behavior (we don't want to SRU break them)
      c) have a case that is affected, in that case the "code using
         client_min_messages" is the one to be considered broken (in favor
         of the majority of users) and that code should be changed instead
         of PostgreSQL.
      Furthermore with that decision we are also in sync with Debian
      handling the same
   - Change [2] renaming of symbols rb/rbt is fine doing forward (Disco),
     but not in Bionic/Cosmic as we'd break en external ABI of the past in
-    an SRU. Please Note that the offending plruby this change was made for 
-    is not even in the Archive.
-  => Especially in regard to "regression potential" that means that we will 
-     NOT apply the two changes that are somewhat discussion-worthy. We 
-     might in later updates reconsider them, but for now when applying the 
-     latest stable release we revert those two primarily for the reason to 
-     have the lowest possible regression potential for the SRU.
+    an SRU. Please Note that the offending plruby this change was made for
+    is not even in the Archive.
+  => Especially in regard to "regression potential" that means that we will
+     NOT apply the two changes that are somewhat discussion-worthy. We
+     might in later updates reconsider them, but for now when applying the
+     latest stable release we revert those two primarily for the reason to
+     have the lowest possible regression potential for the SRU.
  
  Note: opening private as it is not yet announced
  Public announce will on thursday.
  
  [1]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c09daa910
  [2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=b2e754c14

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1815665

Title:
  New upstream microreleases 9.5.16, 10.7 and 11.2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pg-partman/+bug/1815665/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to