On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote: > > On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: > > > > On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > > > On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi <kevin@xxxxxxxxx> 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 _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
