Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Il 11/11/20 16:56, Kevin Fenzi ha scritto:
Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Hi kevin,
I've tried to summarize some of the aspects of the (updated) policy in an image [1], is that right? I don't fully understand the difference between the Beta during final freeze and Pre release...
As a side note, it would be nice to have a link in docs.fedoraproject.org main page to the fesco section, I currently can't found and didn't know he existence of it before you posted the link ;-)
Mattia
On Wed, Nov 11, 2020 at 06:36:54PM +0000, Mattia Verga via devel wrote:
Il 11/11/20 16:56, Kevin Fenzi ha scritto:
Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Hi kevin,
I've tried to summarize some of the aspects of the (updated) policy in an image [1], is that right? I don't fully understand the difference between the Beta during final freeze and Pre release...
I think you are splitting one "phase" into two: "beta" and "pre-release". That should be just one phase called "pre-release". The "final freeze" block is part of that one phase, similarly to how "beta freeze" block is part of "pre-beta".
I read the PR again, and it seems to me that the text matches my description above, i.e. it only has one phase.
As a side note, it would be nice to have a link in docs.fedoraproject.org main page to the fesco section, I currently can't found and didn't know he existence of it before you posted the link ;-)
+1
That picture is great. It would be nice include it in the docs, except that we'd need the "source" version (svg?).
Zbyszek
Il 12/11/20 09:54, Zbigniew Jędrzejewski-Szmek ha scritto:
On Wed, Nov 11, 2020 at 06:36:54PM +0000, Mattia Verga via devel wrote:
Il 11/11/20 16:56, Kevin Fenzi ha scritto:
Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Hi kevin,
I've tried to summarize some of the aspects of the (updated) policy in an image [1], is that right? I don't fully understand the difference between the Beta during final freeze and Pre release...
I think you are splitting one "phase" into two: "beta" and "pre-release". That should be just one phase called "pre-release". The "final freeze" block is part of that one phase, similarly to how "beta freeze" block is part of "pre-beta".
I read the PR again, and it seems to me that the text matches my description above, i.e. it only has one phase.
Maybe it's because my limited English comprehension, but that doesn't seem much clear to me.
In the PR I read: "
Beta to Pre Release This is the time between the Beta release and the Final freeze.
[...]
Pre release This is the time after the Final freeze.
"
I have uploaded the .svg to https://mattia.fedorapeople.org/updates_policy.svg feel free to correct it!
Mattia
On Thu, Nov 12, 2020 at 05:40:08PM +0000, Mattia Verga via devel wrote:
Il 12/11/20 09:54, Zbigniew Jędrzejewski-Szmek ha scritto:
On Wed, Nov 11, 2020 at 06:36:54PM +0000, Mattia Verga via devel wrote:
Il 11/11/20 16:56, Kevin Fenzi ha scritto:
Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Hi kevin,
I've tried to summarize some of the aspects of the (updated) policy in an image [1], is that right? I don't fully understand the difference between the Beta during final freeze and Pre release...
I think you are splitting one "phase" into two: "beta" and "pre-release". That should be just one phase called "pre-release". The "final freeze" block is part of that one phase, similarly to how "beta freeze" block is part of "pre-beta".
I read the PR again, and it seems to me that the text matches my description above, i.e. it only has one phase.
Maybe it's because my limited English comprehension, but that doesn't seem much clear to me.
In the PR I read: "
Beta to Pre Release This is the time between the Beta release and the Final freeze.
[...]
Pre release This is the time after the Final freeze.
"
I have uploaded the .svg to https://mattia.fedorapeople.org/updates_policy.svg feel free to correct it!
Yeah, it's kind of complex there.
"Pre release" is after 'go' at a 'go/no-go meeting'. At that point updates _are_ pushed to stable, but they populate the updates repo, they no longer are part of the base release packages.
The document doesn't make that part very clear tho... it folds in the above with the time before go... perhaps it could be clarified.
I can try...
kevin
Il 12/11/20 23:48, Kevin Fenzi ha scritto:
On Thu, Nov 12, 2020 at 05:40:08PM +0000, Mattia Verga via devel wrote:
Il 12/11/20 09:54, Zbigniew Jędrzejewski-Szmek ha scritto:
On Wed, Nov 11, 2020 at 06:36:54PM +0000, Mattia Verga via devel wrote:
Il 11/11/20 16:56, Kevin Fenzi ha scritto:
Greetings.
FESCo is looking to update the updates policy document that is here:
https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/
For the most part the updates are not changing any policy, but simply removing old/no longer accurate information (taskotron no longer exists, bodhi is always enabled, etc) and trying to clarify things.
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
You can see the PR with the changes:
https://pagure.io/fesco/fesco-docs/pull-request/40
and if you want to view the changed document:
https://pagure.io/fork/kevin/fesco/fesco-docs/raw/updates-update/f/fesco/mod... (you may want to install a adoc viewing extension in your browser to view it)
Feedback welcome here or in the PR.
FESCo is likely to look at this next week for approval.
Thanks!
kevin
Hi kevin,
I've tried to summarize some of the aspects of the (updated) policy in an image [1], is that right? I don't fully understand the difference between the Beta during final freeze and Pre release...
I think you are splitting one "phase" into two: "beta" and "pre-release". That should be just one phase called "pre-release". The "final freeze" block is part of that one phase, similarly to how "beta freeze" block is part of "pre-beta".
I read the PR again, and it seems to me that the text matches my description above, i.e. it only has one phase.
Maybe it's because my limited English comprehension, but that doesn't seem much clear to me.
In the PR I read: "
Beta to Pre Release This is the time between the Beta release and the Final freeze.
[...]
Pre release This is the time after the Final freeze.
"
I have uploaded the .svg to https://mattia.fedorapeople.org/updates_policy.svg feel free to correct it!
Yeah, it's kind of complex there.
"Pre release" is after 'go' at a 'go/no-go meeting'. At that point updates _are_ pushed to stable, but they populate the updates repo, they no longer are part of the base release packages.
The document doesn't make that part very clear tho... it folds in the above with the time before go... perhaps it could be clarified.
I can try...
kevin
Now I see... I have updated the graph, see if it fits:
https://mattia.fedorapeople.org/updates_policy_v2.svg https://mattia.fedorapeople.org/updates_policy_v2.png
Another couple of things which are not entirely clear to me:
- the "pre-beta-freeze" is said to be going "after the branch event happens but before the beta freeze". The usage of "pre-beta-freeze" suggests that there's an ongoing freeze, which isn't true... I would suggest you to name this section "pre-bodhi-change-point". - the following section is named "beta-freeze and bodhi-change-point", but I think it should be named only "bodhi-change-point" since "beta-freeze" sits at the end of Pre Beta.
Mattia
On Fri, Nov 13, 2020 at 02:12:44PM +0000, Mattia Verga via devel wrote:
... and third version:
https://mattia.fedorapeople.org/updates_policy_v3.svg https://mattia.fedorapeople.org/updates_policy_v3.png
Thanks for working on this. ;)
I still don't like 'bodhi activation point'. Can you change that to 'bodhi updates-testing activation point' ?
Also, I wonder if there couldn't be some way to show the various branches? ie, that rawhide is always rawhide at the top, then branched is made off it, goes thru the process and becomes stable release Fn?
Perhaps thats too complex, but it would show streams of releases coming off rawhide...
kevin
Il 14/11/20 20:57, Kevin Fenzi ha scritto:
On Fri, Nov 13, 2020 at 02:12:44PM +0000, Mattia Verga via devel wrote:
... and third version:
https://mattia.fedorapeople.org/updates_policy_v3.svg https://mattia.fedorapeople.org/updates_policy_v3.png
Thanks for working on this. ;)
I still don't like 'bodhi activation point'. Can you change that to 'bodhi updates-testing activation point' ?
Also, I wonder if there couldn't be some way to show the various branches? ie, that rawhide is always rawhide at the top, then branched is made off it, goes thru the process and becomes stable release Fn?
Perhaps thats too complex, but it would show streams of releases coming off rawhide...
kevin
https://mattia.fedorapeople.org/updates_policy_v4.svg https://mattia.fedorapeople.org/updates_policy_v4.png
Done. But I think "Bodhi compose enablement point" would be more appropriate.
Mattia
Kevin Fenzi wrote:
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
Worded like in the above quote: Finally!
But when I see the actual wording in the proposed changes, I see that we go from an undocumented policy to never untag packages in Rawhide (at least, not documented anywhere in the current Update Policy – I think it was decided in some FESCo meeting and never actually codified in the documentation) to a documented policy to almost never untag packages in Rawhide ("it will normally not be untagged"), only "in exceptional cases", which is very open to interpretation.
Hence, I disagree with the wording in the new policy and still ask for the "Rawhide must never go backwards in EVR" policy to be completely overturned, not just softened with exceptions. There is simply no rationale for it, with distro-sync being a thing, and considering that updates-testing, which is supposed to be *more* stable than Rawhide, *can* actually go backwards in EVR (and that's a good thing).
Kevin Kofler
On Fri, Nov 13, 2020 at 12:23:05AM +0100, Kevin Kofler via devel wrote:
Kevin Fenzi wrote:
The one actual proposed change is to allow releng to untag builds that have already gone out in rawhide composes. This was forbidden by the existing policy.
Worded like in the above quote: Finally!
But when I see the actual wording in the proposed changes, I see that we go from an undocumented policy to never untag packages in Rawhide (at least, not documented anywhere in the current Update Policy – I think it was decided in some FESCo meeting and never actually codified in the documentation) to a documented policy to almost never untag packages in Rawhide ("it will normally not be untagged"), only "in exceptional cases", which is very open to interpretation.
Yep. IMHO it should still be a very rare thing. Perhaps we should come up with a list of the cases under which it would happen, but I figured leaving it to releng would be ok.
Hence, I disagree with the wording in the new policy and still ask for the "Rawhide must never go backwards in EVR" policy to be completely overturned, not just softened with exceptions. There is simply no rationale for it, with distro-sync being a thing, and considering that updates-testing, which is supposed to be *more* stable than Rawhide, *can* actually go backwards in EVR (and that's a good thing).
We have been over this. If anyone could untag anything they felt like it would make it much more difficult for everyone to integrate their changes with the rest of the collection.
kevin
Kevin Fenzi wrote:
We have been over this. If anyone could untag anything they felt like it would make it much more difficult for everyone to integrate their changes with the rest of the collection.
That issue is simply not something we have observed at any time back when this untagging was still allowed. (And it was even possible as self-service without involving rel-eng at all, because the Rawhide tag used to be open before gating was introduced.) In the worst case, if some build(s) depends on the untagged build(s), the dependent build(s) can simply be untagged as well.
It is definitely possible to revert to a consistent state, because one such consistent state trivially exists: the one where *all* builds built after the untagged build get untagged as well. But the minimal set of builds to untag is typically much smaller, if it is even larger than a singleton (a set consisting only of the one build you want to untag to begin with). If the untagged package is a leaf package, the set is even guaranteed to be a singleton (but that is not even a necessary condition, only a sufficient condition).
Kevin Kofler
On Fri, Nov 13, 2020 at 01:05:49AM +0100, Kevin Kofler via devel wrote:
Kevin Fenzi wrote:
We have been over this. If anyone could untag anything they felt like it would make it much more difficult for everyone to integrate their changes with the rest of the collection.
That issue is simply not something we have observed at any time back when this untagging was still allowed. (And it was even possible as self-service without involving rel-eng at all, because the Rawhide tag used to be open
Actually it was... perhaps you just weren't affected?
before gating was introduced.) In the worst case, if some build(s) depends on the untagged build(s), the dependent build(s) can simply be untagged as well.
Sure, but that wastes other peoples work, demotivates them from working on things and in general makes things unhappy.
It is definitely possible to revert to a consistent state, because one such consistent state trivially exists: the one where *all* builds built after the untagged build get untagged as well. But the minimal set of builds to untag is typically much smaller, if it is even larger than a singleton (a set consisting only of the one build you want to untag to begin with). If the untagged package is a leaf package, the set is even guaranteed to be a singleton (but that is not even a necessary condition, only a sufficient condition).
Sure, you can revert, but the longer you wait the more work has been done by others on top of what you are reverting. I agree there are some rare times when it's ok to do this, but just letting anyone do this anytime they like could make things worse for everyone IMHO.
Anyhow, I guess lets agree to disagree...
kevin