Re: Plan B for kfreebsd
Petr Salinger wrote:
> >Jonathan Wiltshire wrote:
> >>[...] though we do hope that the
> >>porters will be able to make a simultaneous unofficial release.
>
> It is unclear, what we have to duplicate. Do we stay in testing ?
I'd like to know this as soon as possible as it affects our planning.
Thanks.
If we don't stay in testing, we'd at least want to archive off the
last-built kfreebsd packages before they are deleted...
> Will be there a repository copy in time of official stable release ?
A snapshot would be the basis of any unofficial stable release. To
support it as best we can, we might like to update it (either in-situ,
or in a separate repository) with stable and security updates applied.
Maybe just for the core kfreebsd packages we maintain, but ideally the
whole archive depending on resources.
The same snapshot could also be cloned as the basis of an unofficial
testing release; if we could update it with packages from the official
Debian sid (trying to mirror what Britney is doing) what we'd have is
a kind of rolling release. We could also hold packages back at older
versions if they'd introduce portability issues.
> In the old days, we used to have "unreleased" suite on debian-ports,
> it augmented sid whenever we needed a different version of a package.
I'd like to avoid that in sid - so that it still works properly using
only official packages.
But certainly for unofficial releases, a supplemental repository would
be great for us. We can bypass usual freeze policy to fix bugs we think
are important, which may not have got an unblock. We can apply kfreebsd
patches to some packages, such as in the Xorg Intel graphics driver to
make it work better out-of-the-box for users. We can even overrule
maintainers' decisions; perhaps make openjdk-7 our default JRE, change
APT config to not install recommends, override default shell or MTA ;)
So - while I disagree with the release team's decision - being an
unofficial release doesn't have to be a bad thing for us. It actually
gives us freedom to make improvements as we see fit. And it could be a
lot of fun.
Regards,
--
Steven Chamberlain
steven@pyro.eu.org
Reply to: