[stable][kolla] EOL kolla ocata branch
Hi stable team, Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL: - openstack/kolla - openstack/kolla-ansible Let me know if need anything else. Regards
I've missed the extended maintenance, sorry about that. I don't fully understand what's the process for extended maintenance mode, who is responsible of the management and to take care of it. Is the core group responsible at all of the branch? Change any policy regarding what can be merged, backport, etc? Ocata branch has been unmaintained for a few months until a couple of patches fixes before putting into EOL. If someone wants to maintain ocata, I guess we should tag as EM. Should the core group vote this decision or is something decided based of people whiling to maintaining the branch? Regards n Fri, Dec 21, 2018, 10:21 AM Eduardo Gonzalez <dabarren@gmail.com> wrote:
Hi stable team,
Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL:
- openstack/kolla - openstack/kolla-ansible
Let me know if need anything else. Regards
Please stable team, don't EOL kolla ocata yet, until we clarify if want EM or EOL the branch. Regards On Fri, Dec 21, 2018, 2:58 PM Eduardo Gonzalez <dabarren@gmail.com> wrote:
I've missed the extended maintenance, sorry about that.
I don't fully understand what's the process for extended maintenance mode, who is responsible of the management and to take care of it. Is the core group responsible at all of the branch? Change any policy regarding what can be merged, backport, etc?
Ocata branch has been unmaintained for a few months until a couple of patches fixes before putting into EOL. If someone wants to maintain ocata, I guess we should tag as EM.
Should the core group vote this decision or is something decided based of people whiling to maintaining the branch?
Regards
n Fri, Dec 21, 2018, 10:21 AM Eduardo Gonzalez <dabarren@gmail.com> wrote:
Hi stable team,
Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL:
- openstack/kolla - openstack/kolla-ansible
Let me know if need anything else. Regards
On 12/21/2018 7:58 AM, Eduardo Gonzalez wrote:
I don't fully understand what's the process for extended maintenance mode, who is responsible of the management and to take care of it. Is the core group responsible at all of the branch? Change any policy regarding what can be merged, backport, etc?
Details are in [1][2]. The same project stable core team is responsible for the branch, it doesn't transfer to some new stable EM core team. The appropriate fix model is essentially the same - only backport fixes, not features, no new dependencies, etc. Gauge risk vs reward as normal.
Ocata branch has been unmaintained for a few months until a couple of patches fixes before putting into EOL. If someone wants to maintain ocata, I guess we should tag as EM.
Generally if CI is still working for the branch and people are using it, and it's not a burden, it's fine to leave it open. If it starts failing CI and no one is caring for it (fixing CI issues etc) then it's acceptable to move to EOL after 6 months (see the "Unmaintained" section in [2]).
Should the core group vote this decision or is something decided based of people whiling to maintaining the branch?
It's really up to the core group. If there are people willing to maintain the branch outside of the core group, they should work with the core group, essentially like a liaison. [1] https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.h... [2] https://docs.openstack.org/project-team-guide/stable-branches.html -- Thanks, Matt
On Fri, 21 Dec 2018 at 14:53, Matt Riedemann <mriedemos@gmail.com> wrote:
On 12/21/2018 7:58 AM, Eduardo Gonzalez wrote:
I don't fully understand what's the process for extended maintenance mode, who is responsible of the management and to take care of it. Is the core group responsible at all of the branch? Change any policy regarding what can be merged, backport, etc?
Details are in [1][2].
The same project stable core team is responsible for the branch, it doesn't transfer to some new stable EM core team.
The appropriate fix model is essentially the same - only backport fixes, not features, no new dependencies, etc. Gauge risk vs reward as normal.
Ocata branch has been unmaintained for a few months until a couple of patches fixes before putting into EOL. If someone wants to maintain ocata, I guess we should tag as EM.
Generally if CI is still working for the branch and people are using it, and it's not a burden, it's fine to leave it open. If it starts failing CI and no one is caring for it (fixing CI issues etc) then it's acceptable to move to EOL after 6 months (see the "Unmaintained" section in [2]).
Just pointing out that the last successful run of at least one of the periodic kolla image publish job was at 2019-01-07T06:06:47. If anyone is using Ocata and wants to maintain this, please get in touch. Otherwise I guess we'll mark is as unmaintained on 2019-07-07. It does seem a bit wasteful of CI resources to have 6 months of failing periodic jobs. Should we disable them on the ocata branch until a volunteer steps forward?
Should the core group vote this decision or is something decided based of people whiling to maintaining the branch?
It's really up to the core group. If there are people willing to maintain the branch outside of the core group, they should work with the core group, essentially like a liaison.
[1]
https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.h... [2] https://docs.openstack.org/project-team-guide/stable-branches.html
--
Thanks,
Matt
Hello Mark.
On 2. Apr 2019, at 17:33, Mark Goddard <mark@stackhpc.com> wrote:
It does seem a bit wasteful of CI resources to have 6 months of failing periodic jobs. Should we disable them on the ocata branch until a volunteer steps forward?
I’d be in favour of that. If someone is still actively building Ocata and needs the CI, the errors would have to be corrected first anyway. Christian. -- Christian Berendt Chief Executive Officer (CEO) Mail: berendt@betacloud-solutions.de Web: https://www.betacloud-solutions.de Betacloud Solutions GmbH Teckstrasse 62 / 70190 Stuttgart / Deutschland Geschäftsführer: Christian Berendt Unternehmenssitz: Stuttgart Amtsgericht: Stuttgart, HRB 756139
participants (4)
-
Christian Berendt
-
Eduardo Gonzalez
-
Mark Goddard
-
Matt Riedemann