Open Stack

Hello

Le lun. 18 janv. 2021 à 10:22, Marios Andreou <marios at redhat.com> a écrit :

>
>
> On Fri, Jan 15, 2021 at 7:01 PM Herve Beraud <hberaud at redhat.com> wrote:
>
>> Hello,
>>
>> Sorry for my late reply, and thanks for the heads up.
>>
>> Can't we move directly to EOL [1]?
>> I don't see reason to keep an unmaintained repo open, and if the repos
>> remain open and patches merged then it's not really unmaintained repos.
>>
>> The goal of the extended maintenance was to offer more chances to
>> downstream maintainers to get/share patches and fixes, if you decide to not
>> maintain them anymore then I would suggest you to move to "EOL" directly,
>> it would be less misleading.
>>
>> Notice that if you move rocky to eol all the corresponding branches will
>> be dropped in your repos.
>>
>> Also notice that last week we proposed a new kind of tag (<series>-last)
>> [2][3] for Tempest's needs, but because tempest is branchless...
>>
>> Maybe we could extend this notion (-last) to allow the project to reflect
>> the last step...
>> It could reflect that it will be your last release, and that the project
>> is near from the end.
>>
>> But if you don't plan to merge patches, or if you don't have patches to
>> merge anymore, then I would really suggest to you to move directly to EOL,
>> else it means that you're not really "unmaintained".
>>
>
> OK thanks very much Herve as always for your time and thoughts here. I am
> not against the EOL I just thought it was more of a requirement to declare
> it 'unmaintained' first. The advantage is it is a softer path to completely
> closing it off for any future submissions. Possibly the '-last' tag fits
> this need but if I have understood correctly it might need some adjustment
> to the definition of that tag ('we could extend this notion') and honestly
> I don't know if it is necessary. More likely straight to EOL is what we
> want here.
>

You're welcome, Do not hesitate to ping us.
Concerning the "-last", I said that we surely need to extend this kind of
tag because it is referenced for tempest's usages.
I think EOL fits our needs and is the shortest path.


> I will bring this up again in tomorrow's tripleo irc meeting
> http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019859.html
> and point to this thread. Let's see what other opinions there are around
> EOL vs -last for stable/rocky
>

Same thing on my side, I added this topic to our next relmgt irc meeting
(thursday) to see opinions of the team.


> thank you, marios
>

Thank you

>
>
>
>>
>> Hopefully it will help you to find the solution that fits your needs.
>>
>> Let me know if you have more questions.
>>
>> [1]
>> https://governance.openstack.org/tc/resolutions/20180301-stable-branch-eol.html#end-of-life
>> [2] https://review.opendev.org/c/openstack/releases/+/770265
>> [3] https://review.opendev.org/c/openstack/project-team-guide/+/769821
>>
>> Le ven. 15 janv. 2021 à 16:52, Marios Andreou <marios at redhat.com> a
>> écrit :
>>
>>>
>>> On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou <marios at redhat.com>
>>> wrote:
>>>
>>>> Hello TripleO
>>>>
>>>> I would like to propose that we move all tripleo stable/rocky repos [1]
>>>> to "unmaintained", with a view to tagging as end-of-life in due course.
>>>>
>>>> This will allow us to focus our efforts on keeping the check and gate
>>>> queues green and continue to deliver weekly promotions for the more recent
>>>> and active stable/* branches train ussuri victoria and master.
>>>>
>>>> The stable/rocky repos have not had much action in the last few months
>>>> - I collected some info at [2] about the most recent stable/rocky commits
>>>> for each of the tripleo repos. For many of those there are no commits in
>>>> the last 6 months and for some even longer.
>>>>
>>>> The tripleo stable/rocky repos were tagged as "extended maintenance"
>>>> (rocky-em) [2] in April 2020 with [3].
>>>>
>>>> We have already reduced our CI commitment for rocky - these [4] are the
>>>> current check/gate jobs and these [5] are the jobs that run for promotion
>>>> to current-tripleo. However maintaining this doesn’t make sense if we are
>>>> not even using it e.g. merging things into tripleo-* stable/rocky.
>>>>
>>>> Please raise your objections or any other comments or thoughts about
>>>> this. Unless there are any blockers raised here, the plan is to put this
>>>> into motion early in January.
>>>>
>>>> One still unanswered question I have is that since there is no
>>>> ‘unmaintained’ tag, in the same way as we have the <release>-em or
>>>> <release-eol> for extended maintenance and end-of-life, do we simply
>>>> _declare_ that the repos are unmaintained? Then after a period of “0 to 6
>>>> months” per [6] we can tag the tripleo repos with rocky-eol. If any one
>>>> reading this knows please tell us!
>>>>
>>>>
>>> o/ hello !
>>>
>>> replying to bump the thread - this was sent ~1 month ago now and there
>>> hasn't been any comment thus far.
>>>
>>> ping @Herve please do you know the answer to that question in the last
>>> paragraph above about 'declaring unmaintained' ? please thank you ;)
>>>
>>> As discussed at the last tripleo bi-weekly we can consider moving
>>> forward with this so I think it's prudent to give folks more chance to
>>> comment if they object for _reason_
>>>
>>> thanks, marios
>>>
>>>
>>>
>>>
>>>
>>>
>>>> Thanks for reading!
>>>>
>>>> regards, marios
>>>>
>>>>
>>>> [1] https://releases.openstack.org/teams/tripleo.html#rocky
>>>>
>>>> [2] http://paste.openstack.org/raw/800464/
>>>>
>>>> [3] https://review.opendev.org/c/openstack/releases/+/709912
>>>>
>>>> [4]
>>>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&var-influxdb_filter=branch%7C%3D%7Cstable%2Frocky
>>>>
>>>> [5]
>>>> http://dashboard-ci.tripleo.org/d/3-DYSmOGk/jobs-exploration?orgId=1&fullscreen&panelId=9&var-influxdb_filter=type%7C%3D%7Crdo&var-influxdb_filter=job_name%7C%3D~%7C%2Fperiodic.*-rocky%2F
>>>>
>>>> [6]
>>>> https://docs.openstack.org/project-team-guide/stable-branches.html#maintenance-phases
>>>>
>>>
>>
>> --
>> Hervé Beraud
>> Senior Software Engineer at Red Hat
>> irc: hberaud
>> https://github.com/4383/
>> https://twitter.com/4383hberaud
>> -----BEGIN PGP SIGNATURE-----
>>
>> wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
>> Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
>> RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
>> F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
>> 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
>> glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
>> m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
>> hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
>> qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
>> F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
>> B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
>> v6rDpkeNksZ9fFSyoY2o
>> =ECSj
>> -----END PGP SIGNATURE-----
>>
>>

-- 
Hervé Beraud
Senior Software Engineer at Red Hat
irc: hberaud
https://github.com/4383/
https://twitter.com/4383hberaud
-----BEGIN PGP SIGNATURE-----

wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+
Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+
RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP
F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G
5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g
glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw
m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ
hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0
qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y
F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3
B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O
v6rDpkeNksZ9fFSyoY2o
=ECSj
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210118/ebfa121c/attachment-0001.html>