Versions Compared

Old Version 3

changes.mady.by.user Florian Gleixner

Saved on

compared with

New Version Current

changes.mady.by.user Florian Gleixner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes
1 minScribeAll

 Florian Gleixner does the scribe, Taras Spashchenko is next,

 Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

*Officially Supported Technologies - UpkeepAll

  • See 2023-06-21 Meeting notes for the most recent discussion notes on this the upkeep process.

  • Options:

    1. Capture/document the ad-hoc process which we've been following in lieu of a having a formally defined process

    2. Go back to the previous meeting notes and try to resurrect the process we started to define (see link to meeting notes above)

    3. Do #1 now (short-term/stop-gap solution) and continue to try to make progress on #2 (longer-term solution)

  • Considerations
    • Relevant release milestones
    • Expectations for the TCR process / Which list should we be looking at?
    • How do we ensure this isn't a moving target for developers (both internal and external to the project) throughout the release cycle
    • Do we need notification mechanisms for announcing changes to the OST list for the release in development?
    • Implications on planning for the next release cycle

Previous Notes:

Expand

Focus on upkeep:

  • How do statuses transition?
  • What is active?
    • Can be up to 4 releases
    • Right now - Poppy, Orchid, Nolana. But Q is also "being developed" Or is it up to GA?
    • Period of time where there is often 2 in dev. We wouldn't want to make Q have to comply with P
    • What milestones should inform statuses? Where in the dev process can we nail things down? Statuses in line with dev processes?
    • Milestones are in the release cycle but toward the end. Don't know until part way through the release cycle what version of RMB, etc
    • Maybe changes need to be valid all the way down to active
    • Changes happen right up to the last moment, and even during support periods
    • Want to be able to make the decisions we can early but that won't be all of them
    • Accepted would be nice but maybe not practical, too linear. Leave for now.
    • Do the kinds of changes matter? Like only for security vs for features
      • Discuss more later
    • If we accept changes all along does the page make sense at all? Can people still use it for planning if it is always a moving target?
      • Maybe for active only take security changes? But basic technologies stay the same
      • Freeze earlier in the cycle? Tell people early on if the version will change, like what Stripes does, RMB process is different? Stripes bumps version number early on then aggregates changes in the cycle to that release.
      • Ahead of cycle determine okapi/stripes/rmb versions?
        • Making decision on stuff we own different from external
        • Have to plan far ahead
    • Lists was Orchid version of stripes but it was going to be in Poppy. If new modules have to have released versions and next version will have a breaking change, they have to refactor
    • So if know going to break stripes do early in the cycle but then can they use snapshot versions?
      • challenge to say they have to use version that doesn't exist yet
      • snapshot versions interferes with reproducible builds
    • Distinguish between internal released tools and external ones?
      • Limit OST to things not internal?
      • Might be easier to talk about external separate from internal?
      • Historical policy around 1st party releases, could be talked about in the future
  • Ended up updating change column to clarify what can/is likely to change in statuses
  • Probably difficult to change release process so this makes sense to distinguish, but doesn't really help TCR problem
    • Might need to relax OST restrictions for 1st party items
  • Do we still need accepted?
    • Might make sense for third party
    • Need to see if actually works practically and then come back to it maybe
  • Upkeep activities
    • Drafting starts at GA for release that is two releases later (R starts at GA of P)
    • Move to accepted before release scope refinement deadline for given release
    • Move to active when development begins on that release, which is around time of feature freeze of the release prior to the given release
    • Archived when it is out of support, tied to GA of future release (2 out?)
    • TC should plan when the release schedule is published

Today's Notes:

  • Rereading the Section "Timing of Upkeep Activities"
    • Maccabee Levine would try to play this through and we should adjust the statuses of the pages.
    • According to the rules we should change Quesnelias side from DRAFT to ACCEPTED, but on the other hand TC should discuss the transition?
      • Some frontend versions have to be re-checked for Quesnelia.
      • Zak Burke checking versions in test environment until next monday is too tight, but bumping versions on the other hand helps planning. Some versions (yarn 1) are outdated anyway.
      • Craig McNally but we should have gonr to ACCEPTED back in october
      • Craig McNally we should walk through the versions and decide on monday
      • Tod Olson we should decide / check postgres upgrade 13 first
      • Craig McNally Postgres upgrade will probably be done directly to 15 for Ramsons, Kitfox team is preparing the Test environments
      • Marc Johnson Decision to upgrade Postgres has not been done. Suggest a goal for monday meeting, upgrade to Postgres 13 for Quesnelia and 15 for Ramsons.
      • Craig McNally versions have to be checked until monday. Some have no version information like Kafka/minio
      • Postgres 16 is out of scope at the moment as it is not yet avalible in the AWS environment
    • Too easy to get mixed up in the rules. Craig McNally adds examples to the rules.
    • Moving from ACCEPTED to ACTIVE would be for Quesnelia within 4 days.
      • Marc Johnson planning deadline should have enough time for having influence. There are no goot milestones to pin the transitions to. release scope refinement deadline is too late for the ACCEPTED state.
      • Craig McNally probably release scope composition deadline? yes.
      • Marc Johnson probably not bind to milestones, but respect them.
    • At monday we should get Quesnelia page to ACTIVE - 4 pages with ACTIVE state
  • Ramsons release milestone schedule will be published when Quesnelia gets GA
  • We can get through the process then
  • Ransoms page can be generated before too
  • Marc Johnson To make changes mor visible, DRAFT pages should contain only changed versions.
  • ACCEPTED pages will be filled with all version
  • This is discussed controversally

Open question:

  • creation of DRAFT page: when and shall it contain only changes?
  • postgres 13 or 15 on Quesnelia?
NAZoom Chat

Will paste from recording soon ...00:03:24        Jenn Colt:      Sorry!
00:25:28        Marc Johnson:   If we’re going to leap, we might as well go to 16
00:26:28        Tod Olson:      Replying to "If we’re going to le..."

The pushback on going to 16 was that it wasn't available in the AWS environment. (I'm not certain if that was Postgresql proper or the AWS flavor.)
00:29:28        Florian Gleixner:       Replying to "If we’re going to le..."

https://www.postgresql.org/support/versioning/
00:41:13        Tod Olson:      I need to step away for a minute.
00:48:26        Tod Olson:      back
00:54:13        Marc Johnson:   We are likely to be in that situation soon.

If we make the PostgreSQL 13 decision on Monday and then the 15 decision the week after, we’ll need the Ransoms page then
01:01:26        Tod Olson:      Thank you, Craig and Zak, for the comments about let's not loose the big picture in our documented process because of all of the details and edge cases.


Action Items