Hi Robert, On Fri, Jun 24, 2011 at 03:16:03PM +0200, Robert Millan wrote: > With Squeeze release, the concept of a "technology preview" release > was introduced. Does the update policy for changes that only affect > a "technology preview" release (kfreebsd-i386 or kfreebsd-amd64) > differ from the standard update policy for a stable release? > > In particular, I'm wondering: > > - Due to its "technology preview" status, Debian GNU/kFreeBSD was > released with bugs and limitations in functionality that would be > considered Release-Critical on a stable release. In general (without > precluding the usual case-by-case analisys), should these bugs > be considered candidates for fixing in squeeze? yes, however… > - In some cases, the limitations in functionality mean a particular > FreeBSD utility (freebsd-utils) is either crippled (disabled code) or missing. > Or perhaps it was disabled due to missing FreeBSD libraries (in freebsd-libs) > or kFreeBSD headers (kfreebsd-kernel-headers). This means that > fixing a problem that is considered release-critical could imply dragging > in a lot more changes than is usual for a bug of this severity. Taking > this into account, should the criteria for non-intrussiveness of changes > be relaxed in this context? This is all fine if you're touching packages that build on kfreebsd only or concern kfreebsd only (like the kfreebsd packages on !kfreebsd architectures). If you apply a second pair of eyes within the porters that would be appreciated, however. If you need to touch packages that are also available on Linux we need to ahere to the normal review procedure and criteria. Kind regards Philipp Kern
Attachment:
signature.asc
Description: Digital signature