We were having a good discussion about epel8-playground in the Steering Committee meeting this week. Since we ran out of time I'd like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and it's hard to explain to end users what it is for, or when to use it. It was also agreed that we need to decide on a plan of "this is what playground is for" and then work to setup/cleanup/document things.
There seemed to be two main opinions of what to set the plan to.
A) epel8-playground is meant for package development and testing for major changes. We stop doing the "build on both epel8 and epel8-playground", and epel8-playground packages only get built from the epel8-playground dist-git branch.
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
Both of these plans would require epel8-playground cleanup, and re-implementation. Both would require work. But the work would be quite different with the different plans. So until we decide which way to go, we don't know what to do.
Thoughts on which plan to choose? Or if there is something different?
Troy
On Fri, Jul 31, 2020 at 03:13:00PM -0700, Troy Dawson wrote:
We were having a good discussion about epel8-playground in the Steering Committee meeting this week. Since we ran out of time I'd like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and it's hard to explain to end users what it is for, or when to use it. It was also agreed that we need to decide on a plan of "this is what playground is for" and then work to setup/cleanup/document things.
There seemed to be two main opinions of what to set the plan to.
A) epel8-playground is meant for package development and testing for major changes. We stop doing the "build on both epel8 and epel8-playground", and epel8-playground packages only get built from the epel8-playground dist-git branch.
Thats my preferred setup. Note that this will take some releng work to make it inherit right from epel8 and such.
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
I find this less compelling because stream changes are supposed to be minor release changes, so typically not abi/api breaks or big version updates. In general epel8 stable packages should keep working fine when the next minor 8.x release comes out, so I don't know that this would be particualrly valuable.
Both of these plans would require epel8-playground cleanup, and re-implementation. Both would require work. But the work would be quite different with the different plans. So until we decide which way to go, we don't know what to do.
Thoughts on which plan to choose? Or if there is something different?
A for me, not sure when I would have time to work on it, but I think thats best.
kevin
On Sat, 1 Aug 2020, Kevin Fenzi wrote:
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
I find this less compelling because stream changes are supposed to be minor release changes, so typically not abi/api breaks or big version updates. In general epel8 stable packages should keep working fine when the next minor 8.x release comes out, so I don't know that this would be particualrly valuable.
We have had a python update which affected a lot of package, and TUV have added lower versions of packages already in EPEL, so the minor releases are not that trivial for packagers.
On 01. 08. 20 0:13, Troy Dawson wrote:
We were having a good discussion about epel8-playground in the Steering Committee meeting this week. Since we ran out of time I'd like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and it's hard to explain to end users what it is for, or when to use it. It was also agreed that we need to decide on a plan of "this is what playground is for" and then work to setup/cleanup/document things.
There seemed to be two main opinions of what to set the plan to.
A) epel8-playground is meant for package development and testing for major changes. We stop doing the "build on both epel8 and epel8-playground", and epel8-playground packages only get built from the epel8-playground dist-git branch.
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
Both of these plans would require epel8-playground cleanup, and re-implementation. Both would require work. But the work would be quite different with the different plans. So until we decide which way to go, we don't know what to do.
Thoughts on which plan to choose? Or if there is something different?
Whatever you do, please get rid of the package.cfg file. It is very confusing and very annoying.
See for example https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
On Wed, Aug 19, 2020 at 4:52 PM Miro Hrončok mhroncok@redhat.com wrote:
On 01. 08. 20 0:13, Troy Dawson wrote:
We were having a good discussion about epel8-playground in the Steering Committee meeting this week. Since we ran out of time I'd like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and it's hard to explain to end users what it is for, or when to use it. It was also agreed that we need to decide on a plan of "this is what playground is for" and then work to setup/cleanup/document things.
There seemed to be two main opinions of what to set the plan to.
A) epel8-playground is meant for package development and testing for major changes. We stop doing the "build on both epel8 and epel8-playground", and epel8-playground packages only get built from the epel8-playground dist-git branch.
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
Both of these plans would require epel8-playground cleanup, and re-implementation. Both would require work. But the work would be quite different with the different plans. So until we decide which way to go, we don't know what to do.
Thoughts on which plan to choose? Or if there is something different?
Whatever you do, please get rid of the package.cfg file. It is very confusing and very annoying.
See for example https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I'd like to get this decided by the end of August so we can start working on whichever steps we need to take. And, above all, there is one step we didn't say, but it applied to all Step 0 - Document it. Whatever we do, we need to start by documenting it, agreeing on that, and then do the work to make it that way.
Troy
On 21/8/20 19:06, Troy Dawson wrote:
On Wed, Aug 19, 2020 at 4:52 PM Miro Hrončok mhroncok@redhat.com wrote:
On 01. 08. 20 0:13, Troy Dawson wrote:
We were having a good discussion about epel8-playground in the Steering Committee meeting this week. Since we ran out of time I'd like to continue it via email.
Most everyone agreed that playground is currently a bit of a mess and it's hard to explain to end users what it is for, or when to use it. It was also agreed that we need to decide on a plan of "this is what playground is for" and then work to setup/cleanup/document things.
There seemed to be two main opinions of what to set the plan to.
A) epel8-playground is meant for package development and testing for major changes. We stop doing the "build on both epel8 and epel8-playground", and epel8-playground packages only get built from the epel8-playground dist-git branch.
B) epel8-playground is meant for future RHEL/CentOS testing, and thus everything built in epel8-playground get's built off CentOS Stream. We would continue the "build on both epel8 and epel8-playground" and this would make sure packages would be able to build on the newer RHEL.
Both of these plans would require epel8-playground cleanup, and re-implementation. Both would require work. But the work would be quite different with the different plans. So until we decide which way to go, we don't know what to do.
Thoughts on which plan to choose? Or if there is something different?
Whatever you do, please get rid of the package.cfg file. It is very confusing and very annoying.
See for example https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
I'd like to get this decided by the end of August so we can start working on whichever steps we need to take. And, above all, there is one step we didn't say, but it applied to all Step 0 - Document it. Whatever we do, we need to start by documenting it, agreeing on that, and then do the work to make it that way.
Troy
Pablo
On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
On 21/8/20 19:06, Troy Dawson wrote:
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
Do we have any data here?
Are stream changes breaking epel packages so that they need rebuilds often?
It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely?
Do we know that many/any people are consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us?
kevin
On Sat, Aug 22, 2020 at 11:12 AM kevin kevin@scrye.com wrote:
On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
On 21/8/20 19:06, Troy Dawson wrote:
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
Do we have any data here?
Are stream changes breaking epel packages so that they need rebuilds often?
It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely?
Do we know that many/any people are consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us?
Pros for building against stream: - We would have a way to test EPEL packages that matter against the not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream: - I think you've hit on a big thing. For those wanting a major change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream. - HERE IS THE BIGGEST CON AGAINST USING STREAM -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Aug 22, 2020 at 11:12 AM kevin kevin@scrye.com wrote:
On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
On 21/8/20 19:06, Troy Dawson wrote:
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
Do we have any data here?
Are stream changes breaking epel packages so that they need rebuilds often?
It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely?
Do we know that many/any people are consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us?
Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream:
- I think you've hit on a big thing. For those wanting a major
change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above.
A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived.
If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons.
Thoughts? Troy
On Fri, Aug 28, 2020, at 6:11 PM, Troy Dawson wrote:
On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Aug 22, 2020 at 11:12 AM kevin kevin@scrye.com wrote:
On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
On 21/8/20 19:06, Troy Dawson wrote:
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
Do we have any data here?
Are stream changes breaking epel packages so that they need rebuilds often?
It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely?
Do we know that many/any people are consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us?
Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream:
- I think you've hit on a big thing. For those wanting a major
change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above.
A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived.
If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons.
Thoughts?
Sounds like the perfect solution to me!
V/r, James Cassell
Am 29.08.20 um 00:11 schrieb Troy Dawson:
On Thu, Aug 27, 2020 at 2:10 PM Troy Dawson tdawson@redhat.com wrote:
On Sat, Aug 22, 2020 at 11:12 AM kevin kevin@scrye.com wrote:
On Sat, Aug 22, 2020 at 02:50:39PM -0300, Pablo Sebastián Greco wrote:
On 21/8/20 19:06, Troy Dawson wrote:
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
D) 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Use CentOS 8 Stream to build against.
I am leaning towards option D. We've already got all the playground infrastructure setup. I don't want to waste that. So, although I said option C in the meeting, that doesn't mean I want it, I was just stating it was an option.
I like option D too, looks like a more polished version of option B
Do we have any data here?
Are stream changes breaking epel packages so that they need rebuilds often?
It will mean that if someone wants to use playground to test some large change in epel, they will have to find people who also enable stream to test it most likely?
Do we know that many/any people are consuming stream all the time?
We also don't have much way to say 'if you enable epel8-playground you have to enable stream repos also'.
I guess I don't think the yummy to trouble ratio is good enough here to justify the trouble of enabling stream. Can you expand on why this is good/what it gets us?
Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream:
- I think you've hit on a big thing. For those wanting a major
change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above.
A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived.
If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons.
Just a thought - this assumes that when RHEL9 gets out of the door. The above mentioned scenario (possible library changes) will not happen? Implies after May 31, 2024 (EL8 Maintenance Support Phase starts) ...
-- Leon
On Fri, Aug 28, 2020 at 03:11:49PM -0700, Troy Dawson wrote:
Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream:
- I think you've hit on a big thing. For those wanting a major
change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above.
A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived.
If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons.
Thoughts?
Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version?
Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it?
kevin
On Sun, Aug 30, 2020 at 11:44 AM kevin kevin@scrye.com wrote:
On Fri, Aug 28, 2020 at 03:11:49PM -0700, Troy Dawson wrote:
Pros for building against stream:
- We would have a way to test EPEL packages that matter against the
not yet released RHEL version. -- How often would this matter? -- It's hard to say. There might not be a single EPEL package needing this for the entire RHEL 8.3 release. -- I know for the 8.2 release, I would have liked it so I would have had a place to let others test my updated KDE. --- But I found a work around, so I didn't have to have it.
Cons for building against stream:
- I think you've hit on a big thing. For those wanting a major
change, but don't care about stream, then playground becomes useless. -- So this cuts down on the usefulness of playground. Packagers who want a major change in their package, and are working on stream.
- HERE IS THE BIGGEST CON AGAINST USING STREAM
-- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes out. At some point after that, it switches to being based off RHEL9. --- This means that infrastructure is going to have to switch everything back to being built off RHEL. --- We will have to re-document things. --- More confusion if we had go the CentOS Stream route.
Troy
At the EPEL Steering Committee Meeting, this was discussed again. I believe we all agree that having -playground build off Stream isn't a good thing. But we are also concerned about possible library changes in RHEL8 that might affect EPEL8 packages, and having something based off Stream would be good. Here is the proposal. Note: A) was re-written with better wording than above.
A) epel8-playground 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume playground depends on epel8. 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built.
E) epel8-next 1 - Manual builds only. No package.cfg files. No automatic builds. 2 - Assume -next depends on epel. 3 - Built off CentOS Stream. 4 - Has a limited lifetime that corresponds with the CentOS Stream / RHEL lifetime. -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, then epel8-next get's archived.
If people are wondering about the name, it was decided to use -next instead of -stream, due to the overuse of 'stream' among other reasons.
Thoughts?
Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version?
Very good question. Without being a superhero, do you and/or Smooge think we have the resources to do this? It's sounding like the answer is no.
Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it?
Also a very good question / idea. Any ideas on what would be a good way to ask that? Asking on epel-devel would get some. Asking on epel-annouce would get more, but if we did that, we'd have to have the answers not come back to that list. Possibly cross post to fedora-devel and/or centos-devel.
Troy
On Mon, 31 Aug 2020 at 09:43, Troy Dawson tdawson@redhat.com wrote:
On Sun, Aug 30, 2020 at 11:44 AM kevin kevin@scrye.com wrote:
Thoughts?
Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version?
Very good question. Without being a superhero, do you and/or Smooge think we have the resources to do this? It's sounding like the answer is no.
Honestly, I don't see us having the resources to keep the playground around. Kevin's doubts a long time ago about playground stretching resources too far were correct. The build system is highly complex and just doing plain EPEL is a strain on the Fedora volunteers. Adding the playground was an experiment and I would lean towards ending it.
Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it?
Also a very good question / idea. Any ideas on what would be a good way to ask that? Asking on epel-devel would get some. Asking on epel-annouce would get more, but if we did that, we'd have to have the answers not come back to that list. Possibly cross post to fedora-devel and/or centos-devel.
Troy _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject...
On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 31 Aug 2020 at 09:43, Troy Dawson tdawson@redhat.com wrote:
On Sun, Aug 30, 2020 at 11:44 AM kevin kevin@scrye.com wrote:
Thoughts?
Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version?
Very good question. Without being a superhero, do you and/or Smooge think we have the resources to do this? It's sounding like the answer is no.
Honestly, I don't see us having the resources to keep the playground around. Kevin's doubts a long time ago about playground stretching resources too far were correct. The build system is highly complex and just doing plain EPEL is a strain on the Fedora volunteers. Adding the playground was an experiment and I would lean towards ending it.
Sounds like you would like C)
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
You, Kevin, and Mohan have been doing all the work. And anything we decide, you all will end up doing all that work as well. So I think totally fair that you get a huge say in what happens. But if we do decide to drop playground, I don't want it to sound like it's because of you.
The facts are that EPEL has been given very limited resources, barely enough to keep normal EPEL operations running. Adding epel-playground on top, has over-taxed our limited resources. If epel-playground didn't require any extra upkeep, it might be ok. And if we find a solution that doesn't require any extra upkeep, maybe we can keep playground. But adding anything else, like -next, is over the top. At a minimum it will require extra resources every couple years to setup and take down stuff. Those are resources we don't have.
Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it?
Also a very good question / idea. Any ideas on what would be a good way to ask that? Asking on epel-devel would get some. Asking on epel-annouce would get more, but if we did that, we'd have to have the answers not come back to that list. Possibly cross post to fedora-devel and/or centos-devel.
On Mon, Aug 31, 2020 at 08:05:14AM -0700, Troy Dawson wrote:
On Mon, Aug 31, 2020 at 7:08 AM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 31 Aug 2020 at 09:43, Troy Dawson tdawson@redhat.com wrote:
On Sun, Aug 30, 2020 at 11:44 AM kevin kevin@scrye.com wrote:
Thoughts?
Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version?
Very good question. Without being a superhero, do you and/or Smooge think we have the resources to do this? It's sounding like the answer is no.
Honestly, I don't see us having the resources to keep the playground around. Kevin's doubts a long time ago about playground stretching resources too far were correct. The build system is highly complex and just doing plain EPEL is a strain on the Fedora volunteers. Adding the playground was an experiment and I would lean towards ending it.
Sounds like you would like C)
C) Drop playground. Say it was an interesting experiment and we learned stuff, but shut it down. (and clean up the package.cfg files as part of shutting it down)
You, Kevin, and Mohan have been doing all the work. And anything we decide, you all will end up doing all that work as well. So I think totally fair that you get a huge say in what happens. But if we do decide to drop playground, I don't want it to sound like it's because of you.
The facts are that EPEL has been given very limited resources, barely enough to keep normal EPEL operations running. Adding epel-playground on top, has over-taxed our limited resources. If epel-playground didn't require any extra upkeep, it might be ok. And if we find a solution that doesn't require any extra upkeep, maybe we can keep playground. But adding anything else, like -next, is over the top. At a minimum it will require extra resources every couple years to setup and take down stuff. Those are resources we don't have.
I think playground might be fixable/made of use without too much work... * adjust fedpkg to stop requesting playground branches always/only request them on explicit ask * change the inheritence in koji so it inherits from epel8 * untag all the things that are "older" in playground * add more docs about what it is and how it works * perhaps make it send a daily report for each compose
I suppose though that if we get those things in place, adding a epel8-stream shouldn't be much work over that (aside mirroring stream repos and adding them to koji).
I wish we could get some idea of the usage of things to know where best to send our limited efforts. Are people using playground? Would they use it more if it was smaller/just big changes packages? Are there enough stream users to justify a epel repo built against it? Would it be popular if there were?
I'm open on how to answer these questions, or I suppose we just guess as best we can.
We could also decide to do something if we get the resources. ie, don't set a time when something is done, say it depends on free time of interested parties.
I suppose all that didn't help too much did it?
kevin
On Wed, 2020-09-02 at 14:07 -0700, Kevin Fenzi wrote:
I think playground might be fixable/made of use without too much work...
- adjust fedpkg to stop requesting playground branches always/only
request them on explicit ask
- change the inheritence in koji so it inherits from epel8
- untag all the things that are "older" in playground
- add more docs about what it is and how it works
- perhaps make it send a daily report for each compose
Whether we keep playground (but make playground inherit from epel) or drop it entirely -- that means package.cfg is not going to be needed either way, right?
The only one scenario I can think of where package.cfg is useful is if someone wants their package automatically rebuilt for epel-next. But maybe that should be done automatically the same way ELN rebuilds Rawhide without the individual packager having to worry about it.
So... masas-retire package.cfg, perhaps?
On Wed, Sep 2, 2020 at 2:08 PM Kevin Fenzi kevin@scrye.com wrote:
I think playground might be fixable/made of use without too much work...
- adjust fedpkg to stop requesting playground branches always/only
request them on explicit ask
- change the inheritence in koji so it inherits from epel8
- untag all the things that are "older" in playground
- add more docs about what it is and how it works
- perhaps make it send a daily report for each compose
When you start listing the actual steps, I think you are correct. Changing playground to do what we want, is only a little bit more work than it would to drop it.
If you don't mind, I'd like to go through those steps in a little more detail, and in order that they need to be done.
Step 1 - Approve plan via Steering Committee. Step 1a - Documents and communication -- No releng needed. -- Should be done along the whole way Step 2 - Update fedpkg and remove all package.cfg from epel8. -- Can be done by a proven packagers, no releng needed. Step 3 - Change the inheritance in koji so it inherits from epel8 -- releng work --- I don't know how easy / hard this will be for releng Step 4 - Untag all the things that are "older" in playground -- currently that is a releng process. There is no way for a maintainer to retire their package from playground. -- This needs to happen some time (3 months?) after step 2 is finished. A time that we can see that people have manually built their package in playground, versus the automatic builds. So that the "older" packages are obvious. -- If we do this as a huge batch, it should be a fairly simple (though long) step for releng. Step 5 - Send a daily report -- Is this similar to what we send for EPEL6,7,8 ? --- If this is true, I'm in favor of it. If not, then please explain more. -- I have no idea about the work involved for this.
I think Step 5 is a very important step (if I'm understanding it correctly). Because it will give us a good idea about how many people are utilizing playground.
I think Step 3, changing the inheritance is the only change in the work involved for releng. We would be changing the inheritance, instead of deleting it. I don't know how much extra work that will be.
I have specifically avoided the -next / Stream discussion. Not that I don't think it's important, but because of resources. Let's get playground fixed up if possible. We'll take what we learn, look at how much resources it took, look at how much it is used, and then make a decision.
Troy
On Fri, 4 Sep 2020 07:18:31 -0700 Troy Dawson tdawson@redhat.com wrote:
Step 4 - Untag all the things that are "older" in playground -- currently that is a releng process. There is no way for a maintainer to retire their package from playground. -- This needs to happen some time (3 months?) after step 2 is finished. A time that we can see that people have manually built their package in playground, versus the automatic builds. So that the "older" packages are obvious.
Isn't it likely that builds with the same NEVR (apart from the disttag) in playground as in EPEL-8 proper are automatic builds rather than manual ones?
That would certainly reflect my own usage, where almost all of my packages would be the same, but my manual build of proftpd is different.
Paul.
On Fri, Sep 4, 2020 at 11:18 AM Paul Howarth paul@city-fan.org wrote:
On Fri, 4 Sep 2020 07:18:31 -0700 Troy Dawson tdawson@redhat.com wrote:
Step 4 - Untag all the things that are "older" in playground -- currently that is a releng process. There is no way for a maintainer to retire their package from playground. -- This needs to happen some time (3 months?) after step 2 is finished. A time that we can see that people have manually built their package in playground, versus the automatic builds. So that the "older" packages are obvious.
Isn't it likely that builds with the same NEVR (apart from the disttag) in playground as in EPEL-8 proper are automatic builds rather than manual ones?
That would certainly reflect my own usage, where almost all of my packages would be the same, but my manual build of proftpd is different.
Good point. Check and see if they have the same NVR, except el8 is epel8.playground. I like that better.
On Fri, Sep 4, 2020 at 7:18 AM Troy Dawson tdawson@redhat.com wrote:
Step 1 - Approve plan via Steering Committee. Step 1a - Documents and communication -- No releng needed. -- Should be done along the whole way Step 2 - Update fedpkg and remove all package.cfg from epel8. -- Can be done by a proven packagers, no releng needed. Step 3 - Change the inheritance in koji so it inherits from epel8 -- releng work --- I don't know how easy / hard this will be for releng Step 4 - Untag all the things that are "older" in playground -- currently that is a releng process. There is no way for a maintainer to retire their package from playground. -- This needs to happen some time (3 months?) after step 2 is finished. A time that we can see that people have manually built their package in playground, versus the automatic builds. So that the "older" packages are obvious. -- If we do this as a huge batch, it should be a fairly simple (though long) step for releng. Step 5 - Send a daily report -- Is this similar to what we send for EPEL6,7,8 ? --- If this is true, I'm in favor of it. If not, then please explain more. -- I have no idea about the work involved for this.
This plan has been approved by the Fedora Steering Committee. Thus Step 1 has been accomplished. Ya!!! We will start steps 1a and 2 next week. Step 4 - We will determine what "older" means, but right now I think Paul has the right idea that anything with the same NVR is both epel8 and epel8-playground is considered "older", or non-automated.
Troy
On Fri, Sep 04, 2020 at 07:18:31AM -0700, Troy Dawson wrote: ...snipp....
Step 5 - Send a daily report -- Is this similar to what we send for EPEL6,7,8 ? --- If this is true, I'm in favor of it. If not, then please explain more. -- I have no idea about the work involved for this.
I was thinking like the report that rawhide/branched composes send to the devel/test lists. So, basically that the compose happened and showing what updated, etc.
I think that shouldn't be much work, but... we may need to do some work to make it not send if nothing has changed (which we should/could also reuse for branched).
I think Step 5 is a very important step (if I'm understanding it correctly). Because it will give us a good idea about how many people are utilizing playground.
well, no, it will just make it more visible when packages in playground change.
For usage, thats another thing... we should look at the new dnf counting that fedora is doing and see if we can use that with at least epel8... but thats another seperate project I guess.
I think Step 3, changing the inheritance is the only change in the work involved for releng. We would be changing the inheritance, instead of deleting it. I don't know how much extra work that will be.
Should just be a few commands.
kevin
On Sun, Sep 6, 2020 at 2:01 PM Kevin Fenzi kevin@scrye.com wrote:
On Fri, Sep 04, 2020 at 07:18:31AM -0700, Troy Dawson wrote: ...snipp....
I think Step 5 is a very important step (if I'm understanding it correctly). Because it will give us a good idea about how many people are utilizing playground.
well, no, it will just make it more visible when packages in playground change.
For usage, thats another thing... we should look at the new dnf counting that fedora is doing and see if we can use that with at least epel8... but thats another seperate project I guess.
Sorry, I wasn't clear. By "utilizing playground" I meant developers / maintainers. If we see that no, or very few packages are built in playground after we go manual, then, maybe it isn't worth the effort for epel9. If we see that a decent amount of packages are manually built in playground, then we will know it's worth the effort for epel9. I realize that package changes will probably come in waves. So I don't expect the steady stream we have in regular epel8. But we should have enough time to gauge how well the maintainers are using it.
As for end users, ya. As much as I wish we could find out ... I like that we care enough about privacy that we can't find out. Troy
epel-devel@lists.fedoraproject.org
-
Andrew C Aitchison -
James Cassell -
kevin -
Kevin Fenzi
-
Leon Fauster -
Michel Alexandre Salim -
Miro Hrončok -
Pablo Sebastián Greco -
Paul Howarth -
Stephen John Smoogen -
Troy Dawson