On Wed, May 16, 2018 at 5:11 PM, Clayton Coleman <ccole...@redhat.com>

> 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 <comnea.d...@gmail.com>
> 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
>> dev@lists.openshift.redhat.com
>> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
dev mailing list

Reply via email to