On Wed, Sep 25, 2019 at 11:13 AM Troy Dawson <tdawson(a)redhat.com> wrote:
On Wed, Sep 25, 2019 at 8:41 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>
> On Tue, Sep 24, 2019 at 6:13 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Tue, Sep 24, 2019 at 5:54 PM Kevin Fenzi <kevin(a)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