freebsd stable - Nov 2019 - 12.1-RELEASE schedule update

On Sat, Nov 02, 2019 at 02:12:50PM +0000, Sergey A. Osokin
wrote:
> On Fri, Nov 01, 2019 at 02:52:50PM +0000, Glen Barber wrote:
> > On Fri, Nov 01, 2019 at 01:44:18PM +0000, Sergey A. Osokin wrote:
> > > At the moment we have graphics/drm-fbsd12.0-kmod port for 12.0.
> > > I hope in most cases it's enough for RELENG_12 branch,
however
> > > just to avoid a potential confusion I see the following options
> > > we can do:
> > > 
> > > - create a new port for 12.1 only
> > > - rename the existing port to drm-fbsd12-kmod
> > > - rename the existing port to drm-fbsd12.1-kmod (in case of 12.0
EoL)
> > 
> > What about using the meta-port and keying off of OSVERSION? 
(Personally
> > I have no real preference either way, nor with any of the solutions
you
> > propose above.)
> 
> Actually we have one, graphics/drm-kmod, and it depends on the following
one:
> 
> .elif ${OSVERSION} >= 1200058 && ${OSVERSION} < 1300000
> RUN_DEPENDS=    ${KMODDIR}/drm.ko:graphics/drm-fbsd12.0-kmod
> ...
> 
> So, in case we don't expect an API/ABI changes in 12.x branch we can
> just rename it to drm-fbsd12-kmod, or create a specific version of
> the port for 12.1 - drm-fbsd12.1-kmod and update the meta-port as well.
> 
We should never expect this type of ABI/KBI breakage along a stable
branch.  (That is our definition of "stable", technically, but
sometimes
there are unexpected breakages that occasionally go undetected.)
> > > Also, since this is repeatable thing for every upcoming release
> > > we can add this point to the check list and release scheduling.
> > 
> > Yes, good idea.  Just let us know how you want to proceed, and we can
> > add a note to the documentation.
> 
> I mean I believe we should that (create a new port, update the meta-port,
> etc.) in advance, in the beginning of the first phase of release cycle.
> 
This seems like a reasonable approach.

Glen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20191102/f4eee27a/attachment.sig>

On Sat, Nov 2, 2019 at 10:20 AM Glen Barber <gjb at freebsd.org> wrote:
> On Sat, Nov 02, 2019 at 02:12:50PM +0000, Sergey A. Osokin wrote:
> > On Fri, Nov 01, 2019 at 02:52:50PM +0000, Glen Barber wrote:
> > > On Fri, Nov 01, 2019 at 01:44:18PM +0000, Sergey A. Osokin wrote:
> > > > At the moment we have graphics/drm-fbsd12.0-kmod port for
12.0.
> > > > I hope in most cases it's enough for RELENG_12 branch,
however
> > > > just to avoid a potential confusion I see the following
options
> > > > we can do:
> > > >
> > > > - create a new port for 12.1 only
> > > > - rename the existing port to drm-fbsd12-kmod
> > > > - rename the existing port to drm-fbsd12.1-kmod (in case of
12.0 EoL)
> > >
> > > What about using the meta-port and keying off of OSVERSION?
> (Personally
> > > I have no real preference either way, nor with any of the
solutions you
> > > propose above.)
> >
> > Actually we have one, graphics/drm-kmod, and it depends on the
following
> one:
> >
> > .elif ${OSVERSION} >= 1200058 && ${OSVERSION} < 1300000
> > RUN_DEPENDS=    ${KMODDIR}/drm.ko:graphics/drm-fbsd12.0-kmod
> > ...
> >
> > So, in case we don't expect an API/ABI changes in 12.x branch we
can
> > just rename it to drm-fbsd12-kmod, or create a specific version of
> > the port for 12.1 - drm-fbsd12.1-kmod and update the meta-port as
well.
> >
>
> We should never expect this type of ABI/KBI breakage along a stable
> branch.  (That is our definition of "stable", technically, but
sometimes
> there are unexpected breakages that occasionally go undetected.)
>
The KPIs that drm depends on are quite specific and weird and aren't part
of the set we guarantee (and we can't do what drm needs to do with only the
'safe' ones). It's not much different than virtual box which also
has this
issue frequently because it too falls into that category.
> > > Also, since this is repeatable thing for every upcoming release
> > > > we can add this point to the check list and release
scheduling.
> > >
> > > Yes, good idea.  Just let us know how you want to proceed, and we
can
> > > add a note to the documentation.
> >
> > I mean I believe we should that (create a new port, update the
meta-port,
> > etc.) in advance, in the beginning of the first phase of release
cycle.
> >
>
> This seems like a reasonable approach.
>
How do we get packages from the new port into the release so that users
don't install the 12.0 port by mistake?

Warner