After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
kevin
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
If we do that, then we should rename `epel8-playground` to `epel8-stream`...
I'd like it to work the same way that epel7 worked. And that means no more automatic provisioning epel8-playground for epel8 stuff. And package.cfg should become optional.
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
If we do that, then we should rename `epel8-playground` to `epel8-stream`...
I'd like it to work the same way that epel7 worked. And that means no more automatic provisioning epel8-playground for epel8 stuff. And package.cfg should become optional.
I disagree, mostly because I think we want there to be minimal friction to supporting both branches. If we retain the package.cfg, then what we're getting
On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
If we do that, then we should rename `epel8-playground` to `epel8-stream`...
I'd like it to work the same way that epel7 worked. And that means no more automatic provisioning epel8-playground for epel8 stuff. And package.cfg should become optional.
I disagree, mostly because I think we want there to be minimal friction to supporting both branches. If we retain the package.cfg, then what we're getting
So, it sounds like we (the epel admins and package maintainers) are wanting two different things. 1 - A place that the package maintainers can play around with their packages. (If I update package A to this version, do things still work.) They want the playground to be the same as what's in epel, or you don't know if it breaks because of the version of package A, or if it's the build enviroment.
2 - A place that package maintainers and epel admins, can see if updates to the build system break things. This would be where we have -streams as a build environment, and things like that.
Troy
On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson tdawson@redhat.com wrote:
On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
Thinking about this I just realized "Bad Idea" Why? Because streams is always going to be changing. It will be almost impossible to know what buildroot a -playground package was built with. Also, the playground packages get built, whenever they get built. There is not set schedule. So a stream update could affect package D, but package D doesn't get built for 6 month, so we have no idea whether the stream affects Package D or not.
If we do that, then we should rename `epel8-playground` to `epel8-stream`...
I'd like it to work the same way that epel7 worked. And that means no more automatic provisioning epel8-playground for epel8 stuff. And package.cfg should become optional.
I disagree, mostly because I think we want there to be minimal friction to supporting both branches. If we retain the package.cfg, then what we're getting
So, it sounds like we (the epel admins and package maintainers) are wanting two different things. 1 - A place that the package maintainers can play around with their packages. (If I update package A to this version, do things still work.) They want the playground to be the same as what's in epel, or you don't know if it breaks because of the version of package A, or if it's the build enviroment.
2 - A place that package maintainers and epel admins, can see if updates to the build system break things. This would be where we have -streams as a build environment, and things like that.
Troy
On Wed, Sep 25, 2019 at 11:16:57AM -0700, Troy Dawson wrote:
On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson tdawson@redhat.com wrote:
On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
Thinking about this I just realized "Bad Idea" Why? Because streams is always going to be changing. It will be almost impossible to know what buildroot a -playground package was built with. Also, the playground packages get built, whenever they get built. There is not set schedule. So a stream update could affect package D, but package D doesn't get built for 6 month, so we have no idea whether the stream affects Package D or not.
We have https://koschei.fedoraproject.org/?order_by=state%2Cname&collection=epel8-playground.
-- Petr
On Thu, Sep 26, 2019 at 1:26 AM Petr Pisar ppisar@redhat.com wrote:
On Wed, Sep 25, 2019 at 11:16:57AM -0700, Troy Dawson wrote:
On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson tdawson@redhat.com wrote:
On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
Thinking about this I just realized "Bad Idea" Why? Because streams is always going to be changing. It will be almost impossible to know what buildroot a -playground package was built with. Also, the playground packages get built, whenever they get built. There is not set schedule. So a stream update could affect package D, but package D doesn't get built for 6 month, so we have no idea whether the stream affects Package D or not.
We have https://koschei.fedoraproject.org/?order_by=state%2Cname&collection=epel8-playground.
Very true. But if that is the case, why mess with -playground. Why not just do koschei builds using -stream. If we change the buildroot for -playground, it makes it harder for people to do real-world testing / using of the -playground repo on normal RHEL8/CentOS8.
Troy
On Wed, Sep 25, 2019 at 11:40:19AM -0400, Stephen Gallagher wrote:
On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi kevin@scrye.com wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
It would make playground less usefull for testing new radical changes against the current stable point release, but on the other hand, the centos stream will become the next stable point release, so it would allow people to test against that and get changes ready that they could then push in after the next stable point release landed?
What do folks think? Bad idea, good idea?
I think that makes good sense; it will provide a guarantee of early notice when an upcoming RHEL release might introduce a problematic change (intentionally or otherwise) and provides Red Hat with feedback and an opportunity to fix it before RHEL releases. It will also make our minor release merge windows easier, since we should not get any major surprises hitting only at Beta or GA.
As mentioned downstream, if we want to know if epel builds ok/breaks by changes in the stream we might instead setup a koschei instance pointing to centos stream? Since as Tony indicated we don't mass rebuild or know when something would break there.
If we decide *not* to do this, I think we need to at least have a policy of updating the buildroot for EPEL8-playground to include the RHEL minor release beta tree as a lesser version of the same process as above.
So, question: when say RHEL8.1beta comes out. Is the Centos 8 stream updating that? (ie, has all beta changes and continues from there?). I think we need to be very careful with beta's. If we can get security updates via centos 8 stream then great, but if not, that makes a known pool of insecure software. :(
kevin
On Sat, Oct 05, 2019 at 11:58:31AM -0700, Kevin Fenzi wrote:
So, question: when say RHEL8.1beta comes out. Is the Centos 8 stream updating that? (ie, has all beta changes and continues from there?). I think we need to be very careful with beta's. If we can get security updates via centos 8 stream then great, but if not, that makes a known pool of insecure software. :(
As I understand it, CentOS Stream will get security updates (because no one wants a big pool of insecure software, and it's not good for users), but that the significant, expensive work that the Red Hat security team and Red Hat developers do to develop fixes should be available to paying customers first. That seems reasonable to me. Also, of course, many such fixes have embargo dates and _can't_ be made public early. The mechanisms for doing this aren't actually built yet.
On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
This is something we're talking about at the CentOS Stream kickoff meeting. As EPEL exists today against RHEL and CentOS Linux rebuild, there's a lag time problem when there are surprising RHEL updates -- usually fixed in a few days but sometimes weeks. With CentOS Stream, hopefully there will be no surprises, but the gap between CentOS Stream and RHEL will be always there.
I think if we changed EPEL Playground to build against CentOS Stream, we'd just move the bifurcation problem rather than solving it. I kind of think we need _both_ epel8 and epel8-playground built against both RHEL and CentOS Stream. But I'd love to hear better ideas.
On Thu, Oct 3, 2019 at 7:05 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
This is something we're talking about at the CentOS Stream kickoff meeting. As EPEL exists today against RHEL and CentOS Linux rebuild, there's a lag time problem when there are surprising RHEL updates -- usually fixed in a few days but sometimes weeks. With CentOS Stream, hopefully there will be no surprises, but the gap between CentOS Stream and RHEL will be always there.
I think if we changed EPEL Playground to build against CentOS Stream, we'd just move the bifurcation problem rather than solving it. I kind of think we need _both_ epel8 and epel8-playground built against both RHEL and CentOS Stream. But I'd love to hear better ideas.
In my opnion, bad idea. We should be using koschei [1] for that. Two reasons it's a bad idea. 1 - Since Stream is be definition, changing, you will not easily know what an EPEL package is built against. 2 - EPEL and EPEL-playground packages are not built regularly. They usually tend to sit for long periods of time without any rebuild. So "building against Stream" may, or may not affect some packages, because they only get built every year or so.
Troy
[1] - https://koschei.fedoraproject.org/?order_by=state%2Cname&collection=epel...
On Thu, Oct 03, 2019 at 07:37:09AM -0700, Troy Dawson wrote:
In my opnion, bad idea. We should be using koschei [1] for that. Two reasons it's a bad idea. 1 - Since Stream is be definition, changing, you will not easily know what an EPEL package is built against.
Well, it's changing, but the net sum of changes over a six month period is exactly equal to the net sum of changes from one RHEL minor release to the next.
On Thu, Oct 3, 2019 at 10:05 AM Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 24, 2019 at 02:54:26PM -0700, Kevin Fenzi wrote:
After the announcement today of centos-stream, I wonder if it would make sense to move epel8-playground to build against that instead of the latest rhel8 release?
This is something we're talking about at the CentOS Stream kickoff meeting. As EPEL exists today against RHEL and CentOS Linux rebuild, there's a lag time problem when there are surprising RHEL updates -- usually fixed in a few days but sometimes weeks. With CentOS Stream, hopefully there will be no surprises, but the gap between CentOS Stream and RHEL will be always there.
I think if we changed EPEL Playground to build against CentOS Stream, we'd just move the bifurcation problem rather than solving it. I kind of think we need _both_ epel8 and epel8-playground built against both RHEL and CentOS Stream. But I'd love to hear better ideas.
I'd suggest a middle-ground: we normally build against the latest RHEL 8 minor release. Once the RHEL 8.x+1 *beta* is released, we change epel8-playground to build against CentOS stream until the GA release. We can also potentially run a mass-rebuild at this time to help identify issues early.
On Fri, Oct 04, 2019 at 11:00:35AM -0400, Stephen Gallagher wrote:
I'd suggest a middle-ground: we normally build against the latest RHEL 8 minor release. Once the RHEL 8.x+1 *beta* is released, we change epel8-playground to build against CentOS stream until the GA release. We can also potentially run a mass-rebuild at this time to help identify issues early.
I don't think 8.x+1 betas are going to always be a thing if CentOS Stream is successful. Also, I'm not sure this helps at all except splitting what's broken in time between RHEL and CentOS Stream.
epel-devel@lists.fedoraproject.org