*PSB* On Wed, May 16, 2018 at 5:11 PM, Clayton Coleman <[email protected]> wrote:
> Currently the process is: > > 1. critical security vulnerabilities are back ported > 2. anyone is free to backport a change that is justifiable if you can get > review and meet the bar for review > 3. anyone who helps backport a change is expected to help keep CI jobs > working if you see something is broken - right now only a small pool of > people are doing that so I've been asking folks to chip in and keep the > jobs up to date if you're going to submit PRs > 4. all changes should be in master first (we won't backport an issue that > hasn't merged to upstream kube or to origin master) > *[DC]: Can you please be more specific around "merged to upstream kube" ? Reason i'm asking is because K8 is always ahead by 1 cycle with Origin and as such are you saying that upstream kube branch should match with what origin master code base cycle is - i.e. say currently origin master is being worked on 1.10 K8 code base and as such upstream kube to "watch" is 1.10 branch ? * > > I cut releases on critical issues and otherwise the tag is just rolling > (if you merge to release-3.7 the change will show up). > > > On Wed, May 16, 2018 at 11:07 AM, Daniel Comnea <[email protected]> > wrote: > >> Hi, >> >> I'm sending out this email to understand what is the Origin EOL policy >> and also understand / start a conversation around what is considered >> critical bug which does trigger a new Origin minor release. >> >> >> The rational started from [1] where after i migrated all my internal prod >> environments from 1.5.1 to 3.7.0 but due to bug [2] was fixed in [3] i had >> to move to 3.7.2 (picked latest minor due to CVEs too). >> >> Now after going to all that long/ painful (due to extensive maintenance >> window and few disruptions at apps level) upgrade process, i then got hit >> by [1] and as it stands today don't have many options on the table except >> forking and trying to back port the patch myself. >> >> >> It will be naive to think that Origin will get all/ majority of the OCP >> bug fixes however i do expect to have a gate or a transparent/known >> (public) process which defines what critical bug is (same in how you might >> have for OCP) such that a new Origin can be triggered. >> >> >> Cheers, >> Dani >> >> [1] https://github.com/openshift/origin/issues/19138 >> [2] https://github.com/openshift/origin/pull/17620 >> [3] https://github.com/openshift/origin/releases/tag/v3.7.1 >> >> >> _______________________________________________ >> dev mailing list >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
