[ironic] [release] [kolla] RFC: stop doing Extended Maintenance for Bifrost
Hi all, Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality. Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance. Opinions? Dmitry P.S. Adding kolla because of a potential impact. -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On Wed, Feb 10, 2021 at 6:22 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi all,
Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality.
Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance.
Opinions?
If it's not an overkill burden, I would suggest following Kolla's policy where we in fact keep one last EM branch alive in practice (older ones rot much too quickly). That would mean still caring about Stein until Train goes EM too. -yoctozepto
On Wed, Feb 10, 2021 at 6:43 PM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:
On Wed, Feb 10, 2021 at 6:22 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi all,
Since Bifrost is an installation project that supports several
distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality.
Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves
the regular maintenance.
Opinions?
If it's not an overkill burden, I would suggest following Kolla's policy where we in fact keep one last EM branch alive in practice (older ones rot much too quickly). That would mean still caring about Stein until Train goes EM too.
I'm afraid it is an overkill burden. Please see above, we're struggling even with normally supported branches. Dmitry
-yoctozepto
-- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
On Wed, Feb 10, 2021 at 7:44 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
On Wed, Feb 10, 2021 at 6:43 PM Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, Feb 10, 2021 at 6:22 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi all,
Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality.
Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance.
Opinions?
If it's not an overkill burden, I would suggest following Kolla's policy where we in fact keep one last EM branch alive in practice (older ones rot much too quickly). That would mean still caring about Stein until Train goes EM too.
I'm afraid it is an overkill burden. Please see above, we're struggling even with normally supported branches.
Well, you mentioned EMs down to Ocata so I had to try my luck. :-) -yoctozepto
On Wed, 10 Feb 2021 at 17:44, Radosław Piliszek <radoslaw.piliszek@gmail.com> wrote:
On Wed, Feb 10, 2021 at 6:22 PM Dmitry Tantsur <dtantsur@redhat.com> wrote:
Hi all,
Since Bifrost is an installation project that supports several distributions, maintaining its stable branches is a never ending nightmare. We have *nearly* fixed Ussuri (thank you Riccardo!) and just started looking into Train (thank you Iury and Mark), I'm sure we cannot keep EM branches in a decent shape. Personally I feel that Bifrost is more geared towards consumers staying close to master, but my gut feeling may not necessarily match the reality.
I would hope not the actual master branch, given that it pulls in master branches of all dependencies.
Based on the above, I'm proposing: 1) EOL all old branches from Ocata to Stein on Bifrost. 2) No longer create EM branches, EOL immediately after a branch leaves the regular maintenance.
Opinions?
If it's not an overkill burden, I would suggest following Kolla's policy where we in fact keep one last EM branch alive in practice (older ones rot much too quickly). That would mean still caring about Stein until Train goes EM too.
In theory, there's no burden. There's no obligation to keep EM branches working. In Kolla we generally have a policy where EM branches lie dormant, and are not actively maintained by the core team. They are however open for patches, with the understanding that the submitter will probably need to fix CI before they can land a patch. With my StackHPC hat on, this works well for us because in general our clients' systems are no older than the latest EM (currently Stein). We do rely on Bifrost (via Kayobe), and it could make things a little difficult for us if we could not rely on Bifrost's older stable branches. While I may not be the most active ironic core, I have spent a fair amount of time patching up Bifrost, and will continue to do so when necessary. I suppose the tl;dr is, if you don't want to maintain Bifrost EM that's fine, but please keep it open for someone else to try. Mark
-yoctozepto
participants (3)
-
Dmitry Tantsur
-
Mark Goddard
-
Radosław Piliszek