Open Stack

On Thu, 2023-02-09 at 08:39 -0500, James Slagle wrote:
> On Thu, Feb 9, 2023 at 8:25 AM Sean Mooney <smooney at redhat.com> wrote:
> 
> > If its not clear by my tone below i am very much speaking in my personal
> > capsity
> > not in a redhat one just to be explict about that up front.
> > On Thu, 2023-02-09 at 13:50 +0100, Dmitriy Rabotyagov wrote:
> > > Sorry, let me not agree with this approach. TripleO is a project under
> > > OpenStack governance. Any project under the governance *must* follow 4
> > > opens [1]. At the same time, if the project happens to be maintained
> > > by a single vendor, it doesn't make it any special from any other
> > > project that has healthy contribution diversity. So community
> > > consensus can't be neglected in my opinion.
> > while i hesitate to disagree with my colleague i strongly agree with this
> > statement. regardless of the makeup of the contibutor base
> > by being listed under the grovernace of the openstack foundation and being
> > recognised as a offical openatck porject Tripleo is not a "RedHat Project"
> > or thrid party project and is subject to same rules and procedures as
> > any other offical openstack project.
> > > 
> > > While I fully understand that the main contributor of the project is
> > > quitting it and resuming to maintain only some stable branches that
> > > are currently in an Extended Maintenance, until they will be EOLed, I
> > > personally don't think that dropping content/removing later branches
> > > or releases does follow 4 opens. Even though we might not be aware of
> > > contributors willing to step in in further maintenance of the project,
> > > it doesn't mean they won't show up in some time when the word will be
> > > spread.
> > i tend to agree i think the stable/zed branch since it has been release
> > should not be retired
> > it should be left open so that anyone who deployed it can fix bug and
> > maintaien it.
> > this might require addiing new memeber to the core team or other changes
> > but
> > if there are people willing to put in the work we shoudl afford them the
> > opertunity.
> > its been a very long time since there was any kind fo diversity in the
> > triplo comunity but
> > there have been limisted contibutions form other like 99cloud although
> > after train that sharpely
> > decreased.
> > https://www.stackalytics.io/?module=tripleo-group&release=train
> > there really has not been any significant multi vendor contibution since
> > HP stopped workign on
> > tripleo in kilo but that does not mean there are not comunity users of
> > this may want
> > to maintain it instead of move there production cloud to a diffent
> > technology.
> > or perhaps maintain it so that they can plan to move to a diffent
> > deployment approch in a timely manner.
> > 
> 
> Yes, leaving the branches around also seems reasonable. In whatever way
> that needs to be represented in terms of who, how, or if, they are
> maintained, I can help represent that either through docs or governance
> patches, whichever is deemed appropriate.
i would personally update the readme wiht a statemnt that is deprecated and that limited
supprot is aviable or something like that to let people know they shoudl not plan or perform new
deployment on those later versions. that part of the deprecation process anyway.
advertising the support status to the possible users.
it might make sense to transition stable/zed to EM too if there is no intention to do addtional releases.
if  maintainers appear that could be reverted by them. if not its reflective of reality.
> 
>