[TripleO] moving stable/rocky for tripleo repos to unmaintained (+ then EOL) OK?

Előd Illés elod.illes at est.tech
Tue Jan 19 16:20:47 UTC 2021


Hi,

just to add some clarification:

- 'Unmaintained' is rather a state, where a stable/branch is not 
maintained (meaning, no one pushes CI fixes, bugfix backports), you 
don't need to transition to 'unmaintained'
- a team can decide whether they want to wait for the 6 months to move 
the branch to EOL, or (if no one steps up as maintainer) start the EOL 
process [1] after the warning is sent to the mailing list
- the '-last' tag is really created to support tempest's special case, 
so in TripleO's case EOL is the right choice

I hope this helps. And sorry for the late response.

Thanks,

Előd

[1] 
https://docs.openstack.org/project-team-guide/stable-branches.html#end-of-life



On 2021. 01. 18. 11:44, Herve Beraud wrote:
> Hello
>
> Le lun. 18 janv. 2021 à 10:22, Marios Andreou <marios at redhat.com 
> <mailto:marios at redhat.com>> a écrit :
>
>
>
>     On Fri, Jan 15, 2021 at 7:01 PM Herve Beraud <hberaud at redhat.com
>     <mailto: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 <mailto:marios at redhat.com>> a écrit :
>
>
>             On Thu, Dec 10, 2020 at 7:01 PM Marios Andreou
>             <marios at redhat.com <mailto: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/20210119/49894d44/attachment-0001.html>


More information about the openstack-discuss mailing list